Re: [TLS] Asking for certificate authentication when doing 0-RTT

[Benjamin Kaduk <[e-mail]>]

On 05/24/2016 11:18 PM, Martin Thomson wrote:
> On 24 May 2016 at 19:06, Kyle Nekritz <[e-mail]> wrote:
>> What is the rationale for restricting a change in certificate? If the server has a new certificate that the client would accept with a full handshake, what threat is added by also accepting that certificate with a PSK handshake?
> This was a request from David Benjamin.  But then all the things you
> mention are why I think that it might have been a bad idea.  I think
> that the idea was to avoid unnecessary changes.  Changes that might
> regress the security decisions made originally.  It was the most
> conservative choice without thinking about the problem too much.
>
> However, if we model this as new connection + 0-RTT stuff, then I
> think that we are good.  Probably.  If anyone disagrees it would be
> good to hear that.
>


It seems like it's kind of messy either way -- if the cert changes, the
client has to check the chain of course, but it also ought to confirm
that it's still talking to "the same party" [0] that it was before, so
it is not sending data to someplace it didn't expect.  A scenario where
an attacker can break the 0-RTT crypto and swap in an
attacker-controlled certificate is admittedly a bit far-fetched (other
things would probably be broken, too), but what about a mis-configured
shared host that can accept the 0-RTT for the original site but then
mistakenly presents a cert for a different site that is hosted there
[and sends the data off to the wrong backend]?

If we prevent the cert from changing, then yes there's the added
complexity for deploying cert updates.

It's not even clear that doing a 0-RTT reject when the server wants to
change cert would fix everything, though it might help some.

-Ben


[0] Somehow I don't think there's a good way to express the "same party"
check that works everywhere.