Re: [TLS] judging consensus on keys used in handshake and data messages

[Hannes Tschofenig <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>