Encrypted Content-Encoding for HTTP
draft-ietf-httpbis-encryption-encoding-09

Received changes through RFC Editor sync (created alias RFC 8188, changed abstract to 'This memo introduces a content coding for HTTP that allows message payloads to be encrypted.', changed pages to 16, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2017-06-23, changed IESG state to RFC Published)

[Ballot discuss]

  The "aes128gcm" content coding uses a fixed record size.  The final
  encoding consists of a header (see Section 2.1) and zero or more
  fixed size encrypted records; the final record can be smaller than
  the record size.

This restriction seems to be an artifact of your previous design which
used short records as an end marker.  With the new padding delimeter
structure (which I note is isomorphic to the TLS 1.3 structure), I'm
not seeing any reason to require that the records be fixed length (as
they are not in TLS). I didn't see any discussion of this point in the
thread where this structure was designed, so I'd like to get
confirmation that the WG considered this point and decided to continue
with the above restriction. I'll clear this discuss upon either such confirmation
or removal of the restriction.


UPDATE: James Manger points out that you need fixed record sizes
for random access and header-freeness, though not for security. I will
clear this.

[Ballot discuss]
  The "aes128gcm" content coding uses a fixed record size.  The final
  encoding consists of a header (see Section 2.1) and zero or more
  fixed size encrypted records; the final record can be smaller than
  the record size.

This restriction seems to be an artifact of your previous design which
used short records as an end marker.  With the new padding delimeter
structure (which I note is isomorphic to the TLS 1.3 structure), I'm
not seeing any reason to require that the records be fixed length (as
they are not in TLS). I didn't see any discussion of this point in the
thread where this structure was designed, so I'd like to get
confirmation that the WG considered this point and decided to continue
with the above restriction. I'll clear this discuss upon either such confirmation
or removal of the restriction.

[Ballot comment]

S 2.1.
You should say what idlen is. The QUIC notation here isn't defined :)

S 2.2/2.3.
Can you make clearer that the strings don't have their own null
termination. I.e, that what is fed into the CEK generation function
is  .... 32  38  67  63  6d 00 01
not .... 32  38  67  63  6d 00 00 01


S 4.6.
 
  This mechanism only offers encryption of content; it does not perform
  authentication or authorization, which still needs to be performed
  (e.g., by HTTP authentication [RFC7235]).

This text is kind of confusing, because the mechanism does provide
data origin authentication. I think you mean that if the server is
just going to process this as an opaque and stuff it somewhere, then
it needs extra authentication? This seems like a layering issue.


S 4.7.
Some citations to some of the various padding traffic analysis papers
might be useful.

  Distributing non-padding data is recommended to avoid
  leaking size information.

I think you mean "distributing this across the records".

[Ballot comment]
From Pete's Gen-ART review:

Nits/editorial comments: Looks fine from a non-security-expert's perspective. It is my duty to ask about keyid in section 2.1:

      A "keyid" parameter SHOULD be a UTF-8
      [RFC3629] encoded string, particularly where the identifier might
      need to appear in a textual form.

I presume that simply means "might need to be rendered" and does not include "might need to be typed in by someone", correct? The former is easy; the latter probably requires a bit more text.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-httpbis-encryption-encoding-08.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the HTTP Content Coding Registry located in the Hypertext Transfer Protocol (HTTP) Parameters registry located at:

https://www.iana.org/assignments/http-parameters/

a single, new entry is to be added as follows:

Name: aes128gcm
Description: AES-GCM encryption with a 128-bit content encryption key
Reference: [ RFC-to-be ]
Notes:

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: httpbis-chairs@ietf.org, draft-ietf-httpbis-encryption-encoding@ietf.org, Mark Nottingham , mnot@mnot.net, ietf-http-wg@w3.org, alexey.melnikov@isode.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Encrypted Content-Encoding for HTTP) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document:
- 'Encrypted Content-Encoding for HTTP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-04-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo introduces a content coding for HTTP that allows message
  payloads to be encrypted.

Note to Readers

  Discussion of this draft takes place on the HTTP working group
  mailing list (ietf-http-wg@w3.org), which is archived at
  https://lists.w3.org/Archives/Public/ietf-http-wg/ .

  Working Group information can be found at http://httpwg.github.io/ ;
  source code and issues list for this draft can be found at
  https://github.com/httpwg/http-extensions/labels/encryption .




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-encryption-encoding/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-encryption-encoding/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2777/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc5869: HMAC-based Extract-and-Expand Key Derivation Function (HKDF) (Informational - IETF stream)
Note that some of these references may already be listed in the acceptable Downref Registry.

# Shepherd Writeup for draft-ietf-httpbis-encryption-encoding

## 1. Summary

Mark Nottingham is the document shepherd; Alexey Melnikov is the responsible Area Director.

This memo introduces a content-coding for HTTP that allows message payloads to
be encrypted.

The intended status is Proposed Standard.

## 2. Review and Consensus

This document has been discussed for some time in the Working Group, going through several
revisions and reviews. The editor is primarily responsible for the design, but reviews by a number
of other people have shaped its design over time.

The most immediate use case comes from the WEBPUSH WG.

A list of implementations can be found at:
  https://github.com/httpwg/wiki/wiki/EncryptedContentEncoding
Note that some need to be updated to reflect the latest draft.

## 3. Intellectual Property

Martin has confirmed that, to his direct, personal knowledge, all IPR related to this document has
already been disclosed, in conformance with BCPs 78 and 79.

One IPR disclosure has been made for this document; see .
The Working Group was informed of this (see
), but no changes to the draft
resulted.

## 4. Other Points

This document has a downward reference to RFC5869, which is already in the DOWNREF Registry.