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

[David Benjamin <[e-mail]>]

On Wed, Jul 6, 2016 at 2:11 PM Yoav Nir <[e-mail]> wrote:

> 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?
>

I'm also curious which post-handshake messages are the problem. If we were
to rename "post-handshake handshake messages" to "post-handshake bonus
messages" with a distinct bonus_message record type, where would there
still be an issue? (Alerts and application data share keys and this seems
to have been fine.)

For post-handshake client auth, is
draft-bishop-httpbis-http2-additional-certs-01 still the plan for HTTP/2?
It seems to me that, whatever we do for the HTTP/1.1 + TLS 1.3 case, we
need to solve certificate auth hosted in application data anyway. So we
don't gain anything overall for HTTP if these messages share fate with
handshake vs. application data. And, as you note, this is where the
information disclosure is particularly bad.

The KeyUpdate messages themselves seem so inconsequential that I likewise
can't imagine key separation is particularly important. But I don't
understand the proof-related concerns, so perhaps I'm confused.

NewSessionTicket I am willing to buy should share fate with the handshake
and not application data. Though it still doesn't seem worth the complexity
tradeoff to me. (With the caveat I, again, don't actually understand the
proof-related concerns.)

David