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: tls@ietf.org 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
