Hi Joe, it might be interesting to note that in the context of the DTLS 1.3 discussion with Ilari it appears that the epoch exposes handshake messages (vs. application data) since you need a way to find out what key was used to encrypt the message (and msgs may get re-ordered or lost).
So, I claim that even if you manage to go for option 1 in TLS 1.3 you will most likely have a kind of option 2 in DTLS 1.3 (unless you get rid of the epoch value, which is of course possible). This does not really answer your question but I don't have a strong opinion between #1 and #2. Separately encrypting the content type sounds feels a bit too radical to me. Ciao Hannes On 07/06/2016 07:39 PM, Joseph Salowey wrote: > We are the unenviable position of calling consensus between three > choices [0]: > > - Option 1 - use the same key for both handshake and applications messages. > - Option 2 - restore a public content type and different keys. > - Option 3 - separately encrypting the content type. > > At this point the consensus is rough. > > The first option we would broadly characterize as supported by the > implementers because they can’t see the harm in using the same key but > opposed by the cryptographers because it makes the proofs harder making > mistakes easier to miss. > > The second option as supported by researchers/cryptographers because it > cleanly separates the keys used but opposed by the implementers because > it’s unnecessarily complex. In general, privacy advocates do not > support this option either. > > The third was not really discussed at all and it’s not clear what is the > impact to security proofs or implementations. > > As we see it the privacy concerns are somewhat of a moving target, > however not encrypting the content type seems worse for privacy than > encrypting it. > > We are looking to eliminate option 2 and choose 1 or 3. If you are in > favor of option 2 then we need to know if option 1 meets your needs, if > option 3 is better than option 1, or if you feel that the only viable > option is option 2. > > J&S > > [0] https://mailarchive.ietf.org/arch/msg/tls/UwIHOwGzxfOGiewI8lRreqBuiNA > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
