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

From: Eric Rescorla <[email-masked]>
Date: Fri, 11 Nov 2016 22:30:02 -0800

Please find some comments on the most recent revision.

-Ekr

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.

S 2.2.
   Why are you using the terminal 0x00 here? I don't see anywhere
   else you HMAC on cek_info without it.

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.

EDITORIAL
S 2.
You should put the graf starting with "The record size" above the diagram
because the diagram rs.

  To prevent an attacker from truncating a stream, an encoder
  MUST append a record that contains only padding and is smaller than
  the full record size if the final record ends on a record boundary.

I would invert the logic here. I.e.,

  If the final record ends on a record boundary, the encoder MUST
  append a record that contains...

  Each record contains between 2 and 65537 octets of padding, inserted
  into a record before the enciphered content.

I think it's kind of a mistake to treat the padding length as part of the
padding.

  A consequence of this record structure is that range requests
  [RFC7233] and random access to encrypted payload bodies are possible
  at the granularity of the record size.  Partial records at the ends
  of a range cannot be decrypted.  Thus, it is best if range requests
  start and end on record boundaries.

This is sort of true, but it's not like you can randomly access the
underlying data because there might be padding and you don't know.

S 2.2.
   In order to allow the reuse of keying material for multiple different
   HTTP messages, a content encryption key is derived for each message.
   The content encryption key is derived from the decoded value of the
   "salt" parameter using the HMAC-based key derivation function (HKDF)
   described in [RFC5869] using the SHA-256 hash algorithm [FIPS180-4].

"decoded value" is weird here.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 12 Nov 2016 15:56:53 +0900

> total number of bytes with the same key, not on the total number

This is just P_MAX from RFC 5116.

>    else you HMAC on cek_info without it.

I like null-terminating my context strings.

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

---

From: Julian Reschke <[email-masked]>
Date: Sat, 12 Nov 2016 08:32:44 +0100

On 2016-11-12 07:56, Martin Thomson wrote:
> ...
> ...

One use case is over here: 
<https://greenbytes.de/tech/webdav/draft-reschke-http-oob-encoding-09.html#n-example-involving-an-encrypted-resource>

If "Cryto-Key" isn't defined in the base spec, any other spec that 
defines how to pass around the key information will have to define it 
itself. That doesn't sound like a good idea to me.

Best regards, Julian

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 11 Nov 2016 23:42:19 -0800

On Fri, Nov 11, 2016 at 11:32 PM, Julian Reschke <[email-masked]>
wrote:

> One use case is over here: <https://greenbytes.de/tech/we
> bdav/draft-reschke-http-oob-encoding-09.html#n-example-invol
> ving-an-encrypted-resource>
>
> If "Cryto-Key" isn't defined in the base spec, any other spec that defines
> how to pass around the key information will have to define it itself. That
> doesn't sound like a good idea to me.
>

But what's defined in the spec is only useful for the existing message. It
seems to me like this should be in a different spec...

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 11 Nov 2016 23:41:20 -0800

> I like null-terminating my context strings.

I think you should require that generally then.

---

From: Kari Hurtta <[email-masked]>
Date: Sat, 12 Nov 2016 10:18:58 +0200 (EET)

> itself. That doesn't sound like a good idea to me.

Looks like draft-ietf-httpbis-encryption-encoding needs informal reference
to draft-reschke-http-oob-encoding if Crypto-Key is on 
draft-ietf-httpbis-encryption-encoding.

|  ⋯           However, the Crypto-Key header field could be
|   used in one message to provision keys for other messages.

+    One way to do that is use Content-Encoding header field value, 
+    which moves actual payload to outside of that message where 
+    Crypto-Key header field is used (for example [draft-reschke-http-oob-encoding]).

If I understand correclty  Eric Rescorla suggest own specification:

	Crypto-Key header field for HTTP Encrypted Content-Encoding

Essentially moving

3.  Crypto-Key Header Field
https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-04#section-3

to that specification.

Then also there need something to be done with examples.

/ Kari Hurtta

---

From: Martin Thomson <[email-masked]>
Date: Sat, 12 Nov 2016 17:32:05 +0900

> Then also there need something to be done with examples.

The alternative is to find a different solution for that draft, like
moving the keys to the payload.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 12 Nov 2016 09:37:50 +0100

> moving the keys to the payload.

Yes, that's how it actually started.

The question remains whether a common mechanism is desirable/needed.

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Sat, 12 Nov 2016 17:42:57 +0900

> Yes, that's how it actually started.

:)

> The question remains whether a common mechanism is desirable/needed.

I'm on the fence, and that suggests that committing to doing a common
mechanism in this document is probably the wrong decision.  I don't
like building new mechanisms with such a low level of certainty about
need.