W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: Comments on draft-ietf-httpbis-encryption-encoding-04

From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 11 Nov 2016 23:41:20 -0800
Message-ID: <CABcZeBOuBL05tsAEMGF+y3cPEYzypyh8m80drMsmDtHkkMtPzA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Fri, Nov 11, 2016 at 10:56 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 12 November 2016 at 15:30, Eric Rescorla <ekr@rtfm.com> wrote:
> > SUBSTANTIVE
> > S 2.1.
> >   The "rs" or record size parameter contains an unsigned 32-bit
> >   integer in network byte order that describes the record size in
> >   octets.  Note that it is therefore impossible to exceed the
> >   2^36-31 limit on plaintext input to AEAD_AES_128_GCM.  Values
> >   smaller than 3 are invalid.
> >
> > I don't believe that this is correct, because the limit is on the
> > total number of bytes with the same key, not on the total number
> > of bytes with one nonce.
>
> This is just P_MAX from RFC 5116.
>
> > S 2.2.
> >    Why are you using the terminal 0x00 here? I don't see anywhere
> >    else you HMAC on cek_info without it.
>
> I like null-terminating my context strings.
>

I think you should require that generally then.



>
> > S 3.
> > This whole Crypto-Key thing seems like a menace. As has been noted,
> > it's a terrible idea to provide Crypto-Key and encrypted data
> > for the same key in the same HTTP message, but that's the only
> > thing you see to support:
> >
> >    The value or values provided in the Crypto-Key header field is valid
> >    only for the current HTTP message unless additional information
> >    indicates a greater scope.
> >
> > Do we have a concrete use case for Crypto-Key? If not, I would remove
> > it. If so, I would consider writing a different spec.
>
> Maybe we can discuss this in the meeting, I don't have any objection
> to this.  I like deleting code.
>
> > EDITORIAL
>
> These seem sensible.  I'll do what I can to sort them out when I get some
> time.
>
Received on Saturday, 12 November 2016 07:42:33 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 12 November 2016 07:42:35 UTC