Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

I'm with Valery here. IMHO the proposed mechanism makes little sense because (politics notwithstanding) it offers little gain in return of a significant (possibly unacceptable) burden to important use cases. 

Personally I'm firmly against it. 

<proper disclaimers>
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Valery Smyslov
Sent: Friday, December 4, 2015 07:57
To: Bryan Ford
Cc: [e-mail]
Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

 
As far as I understand your proposal makes impossible to use this trick, 
if we consider packets loss and reordering.

Actually, if I’m understanding correctly how you’re doing this per-datagram rekeying, I think it still should be compatible with the hash-table-based approach I proposed.  Assuming you’re using some key derivation function that takes a master key and sequence number as input and produces a per-datagram key, the receiver just needs to pre-compute the per-datagram keys for the sequence numbers within the current window, and encrypt the sequence numbers with those respective per-datagram keys, in order to populate its hash table.  I don’t think anything breaks at least.
I would say that the hash-table-based approach would work in theory.
In practice it either implies too much burden on the receiver or would fail
in some situations. Consider, for example, situation when the sender
skips large amount of sequence numbers (say 2^32) for some reason.
It would be difficult for receiver to build such a hash table.
 
Regards,
Valery Smyslov.