Subject: Eric Rescorla's Discuss on draft-ietf-httpbis-encryption-encoding-08: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Fri, 14 Apr 2017 05:51:41 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-httpbis-encryption-encoding-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-encryption-encoding/

----------------------------------------------------------------------
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.

----------------------------------------------------------------------
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".

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Apr 2017 17:16:49 +1000

> for random access and header-freeness, though not for security. I will

I think that James covered this.

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

Oops, thanks for picking that up (the QUIC notation doesn't really
support this idea either.

> not .... 32  38  67  63  6d 00 00 01

Done.

> it needs extra authentication? This seems like a layering issue.

The example is a little strange.  I've made what I think is the minimal change:

```
This mechanism only offers data origin authentication; it does not perform
authentication or authorization of the message creator, which could still need
to be performed (e.g., by HTTP authentication {{?RFC7235}}).

This is especially relevant when a HTTP PUT request is accepted by a server
without decrypting the payload; if the request is unauthenticated, it becomes
possible for a third party to deny service and/or poison the store.

```

Does that seem better?

The layering issue exists already, but it's arguably beneficial.  An
HTTP endpoint might retain or remove content codings as they see fit
(or, in this case, are able).  For example, static JS or HTML files
are routinely stored on disk or in cache with gzip (or brotli)
encoding applied at servers and intermediaries, because that suits the
usage model best and per-request compression can be too slow.

> Some citations to some of the various padding traffic analysis papers

I added a couple.

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

Thanks.

I've updated the editor's copy, which should show at
http://httpwg.org/http-extensions/draft-ietf-httpbis-encryption-encoding.html
in a little while.  I will await instruction before I submit a -09
version.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Apr 2017 19:33:41 +1000

On 18 April 2017 at 18:36, Alexey Melnikov <[email-masked]> wrote:
> Please post a new version.

-09 is posted.  I hope that my edits will find favour.  If not, it is
easy enough to create a -10.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Apr 2017 07:40:10 -0400

LGTM