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

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Sat, 12 Nov 2016 15:56:53 +0900
Message-ID: <CABkgnnV3m-_PO1CKYxy=jYaBY0f72LdSqXxkdNdma1d6AM0MEQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 12 November 2016 at 15:30, Eric Rescorla <ekr@rtfm.com> wrote:
> 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.

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


These seem sensible.  I'll do what I can to sort them out when I get some time.
Received on Saturday, 12 November 2016 06:57:26 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 12 November 2016 06:57:29 UTC