Re: [TLS] Wrapping up cached info

["Brian Smith" <[e-mail]>]

Stefan Santesson wrote:
> Could you explain why?
> What is the attack scenario?

Here are some issues I have come up with regarding this extension:

1. If the server went through the trouble of establishing a secure channel
before sending an information item, then doesn't that mean that the server
wants that information item to be kept confidential? If the client sends an
unencrypted hash of a confidential information item to the server, then it
creates an opportunity for known-plaintext attacks on that information item.
In particular, this would negatively affect any server that authenticates
the client and then renegotiates with its "real" certificate and/or other
handshake information.

2. Let's say you go to site A and cache site A's cert list. Then you send a
hash of that to site B. Then, site B can use that hash to recognize that the
user has previously been to site A. This if an information leak very similar
to the HTTP referrer header. For this reason, clients must be careful not to
send a hash of an information item to any site other than the one that sent
it to them. But this creates a problem, since the client hello happens
before authentication. This is worse than TLS session IDs and TLS session
tickets because both of the TLS session resumption mechanisms can be done in
such a way that it is impossible to map a session ID/ticket to the source
server.
 
3. Let's say that a server generates a unique trusted CA list record for
every new session. Then the client's hash of the trusted CA list will act
like a HTTP cookie, much like TLS session IDs and tickets. Clients will have
to ensure that they clear their cached info cache similarly to the way they
clear HTTP cookie caches and TLS session caches.

Regards,
Brian

> 
> On 10-05-23 11:40 PM, "Brian Smith" <[e-mail]> wrote:
> 
> > Stefan Santesson wrote:
> >> I will, provided that this seems acceptable still in a few days from
now,
> >> write up a new draft that captures the changes which then hopefully can
be
> >> ready for a WGLC.
> >
> > There's another issue still. If the server sends the client an
information
> > item X after the change cipher suite message, then the client must not
send
> > a hash of that information item in its client hello message on another
> > connection, until it has verified the identity of the server on that
second
> > connection. In other words, the client must ensure that it doesn't leak
> > information that would otherwise be confidential--including even
certificate
> > messages and client certificate cipher suite messages that were received
> > over an encrypted connection.
> >
> > Regards,
> > Brian
> >
>