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

[Yoav Nir <[e-mail]>]

Hi, Joe

> On 6 Jul 2016, at 8:39 PM, Joseph Salowey <[e-mail]> 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.

I will re-iterate my opposition to option 2. Some occurrences on non-application data records within a TLS session are initiated by user action or application state. Best example is when the user sees a login page and clicks the button that says “Log in with certificates…” causing (in TLS 1.2) a HelloRequest to be send and a renegotiation with client certificates, or (in TLS 1.3) a CertificateRequest to be sent followed by the client sending a certificate. This is not some theoretical weakness. This is real information disclosure. With TLS 1.2 you can look at the Wireshark screen, point to the handshake record in the middle of the TCP flow and know that this is where the user pressed the button.

Of options 1 and 3, I can see that #3 is theoretically better, but the design seems too baroque to me. I hope it can be done without adding a whole new block operation to each record, and I prefer the simplicity of #1, but I’m not really opposed to #3. IIRC there were some cryptographers who were concerned about #1. We haven’t heard from them that #3 solves their issue, have we?

Yoav