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

[Martin Thomson <[e-mail]>]

On 14 April 2017 at 22:51, Eric Rescorla <[e-mail]> wrote:
>    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.

I think that James covered this.

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

> 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

Done.

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

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.

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

I added a couple.

>    Distributing non-padding data is recommended to avoid
>    leaking size information.
>
> 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.