Re: New Version Notification for draft-thomson-http-encryption-00.txt

Thanks for the thorough review John.  I have made a number of changes,
most of which (I hope) improve the document in the right direction.

You can review my changes here if you like:
https://github.com/martinthomson/http-encryption/pull/3

Most of your comments were pretty straightforward; I'll only respond
to those that I think we need to discuss.

On 21 June 2015 at 01:13, John Mattsson <john.mattsson@ericsson.com> wrote:
> - Sec 2: “A receiver MUST fail to decrypt if the remainder is 16 octets or less in size”
> Should likely be “is 1 octets or less”?

16 octets or less is correct.  A valid ciphertext will always include
at least one padding byte and a 16-byte authentication tag.  I've
expanded the context here.

> - Sec 2: According to “The nonce used for each record is a 96-bit value containing the index of the current record”, there is no “fixed” part of the nonce. Setting the length of the fixed portion of the nonce to zero lowers the theoretical security level against various dictionary attacks. I would recommend using the salt to populate a “fixed value” of some length (maybe 4,6, or 8 bytes). A 12-byte counter is not needed anyway.

I'm actually not that concerned about the dictionary attack, but belt
and braces has only occasionally turned out to be an awful idea.

This is the direction TLS 1.3 has adopted.  And I had planned to copy
that construction if it ever came about.  The plan there is to
separately derive a value and XOR that with the record sequence
number.  That gives you a 12-byte counter, if you want it (my
implementation only goes to 48-bit lengths and I don't see much need
for that much even).

(Reminder for me to talk to some folks about breaking this.  Better
now than later though.)

> - Sec 2: “A sequence of full-sized records can be” -> “A full sequence of records can be”

The point was that they were full-sized.

> - Sec 2: As far as I can see the construction with no AAD is safe, the nonce is implicitly integrity protected as the decryption fails if the nonce is changed.

That was my analysis as well :)  I just wanted more eyes on before I
removed the note.


Note that this intentionally follows the structure of the AEAD use in
TLS, which includes the sequence number and the TLS version in the
AAD.  The things that need to be covered by the integrity check are
therefore:
 * the sequence number (covered by the nonce, as you say)
 * the fact that this is this specific version of the
content-encoding, and not some transplant from some other context
(covered via the content-encryption key, by way of the inclusion of a
very specific label in HKDF)

> - Sec 4: The Encryption-Key Header must clearly mandate use of https with a high enough security. I suggest something like:
> “The Encryption-Key Header MUST only be used with https fulfilling at least the requirements in [RFC7540] Section 9.2”

I'm less sure about this, given the DH usage.  Maybe just for explicit
keys.  Even there, I'm concerned that this is necessary, but not
sufficient for real security.  I'm a little concerned that a
stipulation of that form will be taken to imply that HTTPS is enough.

> - Sec 4.1 “Other key determination parameters can be ignored if the "key" parameter is present.”, doesn’t this needs to be more strict. If there are not ignored, what happens then? What is associated with keyid? Should it even be allowed to send several conflicting parameters?
>
> - Sec 5.3: Why is the content-length in example 1234 and not 1216? Wouldn’t 1216 be the maximum content-length for aesgcm128 with rs=1200?

1216 would be the size of a single record and thus would be invalid.
1234 is at least valid, but honestly, only by accident.

> - It would be good if the draft separated the general mechanism and the specific aesgcm128 content-coding a little bit more. Is for example Section 3.2 specific for aesgcm128 or is it general? Mandating a 16-octet salt seems limiting in the general case.

The lack of generality is entirely intentional, which I'm sure will
offend instincts that have been drilled into many of us.

As for the specific limit on salt, the goal is to ensure uniqueness.
16 octets is sufficient for that purpose.

Received on Tuesday, 23 June 2015 21:15:29 UTC