Re: Secondary Certificates and 0-RTT

On Thu, Jul 12, 2018 at 12:35:24PM +0900, Kazuho Oku wrote:
> 2018-07-10 5:24 GMT+09:00 Ben Schwartz <bemasc@google.com>:
> > On Mon, Jul 9, 2018 at 4:11 PM Martin Thomson <martin.thomson@gmail.com>
> > wrote:
> >
> >> It might be possible to use 0-RTT to proactively probe for secondary
> >> certificates while retaining this restriction, but if you want this, I
> >> think that we need to discuss the reasons we opted not to allow those
> >> secondary certificates to transfer to a resumed connection.
> >
> >
> > Indeed.  I'm not clear on the whole history of that decision, but my
> > understanding is as follows:
> >
> > 1. At the end of the previous session, all certificates (primary and
> > secondary) are on equal footing.
> > 2. Under 0-RTT keys, nothing has changed to break this symmetry.
> > 3. After session resumption, the 1-RTT keys represent a new Diffie-Hellman
> > with the (new) primary certificate, so the 1-RTT keys are no longer tied to
> > the old secondary certificates.
> 
> I am not sure if that is correct.
> 
> When the session is resumed, the primary certificate is not sent.
> 
> 0-RTT key is derived from the previous handshake. 1-RTT key is derived
> from the previous handshake and the key exchange of the resumption.
> 
> So I would assume that Martin is correct; both 0-RTT and 1-RTT keys of
> a resumed session will be either valid or invalid for the secondary
> certificates that have been validated in the previous handshake.

Yes, I think it is not correct. All the certificates are not on equal
footing, because only the primary certificate has been incorporated, not
the secondary ones. And there is no new primary certificate if PSK is
used, because PSK can not be mixed with certificates (there is proposal
to allow it, but only with static PSKs).

And 0-RTT is very sensitive piece. It is much more difficult to analyze
than anything else in TLS 1.3. So a security issue that is not there for
just plain dynamic PSKs but is there for 0-RTT is not unthinkable for
me. I am certainly not able to make an analyisis of this.

The dynamic PSK keys also incorporate the primary client certificate,
but not the post-handshake ones. Which makes it unsafe to use dynamic
PSKs from connections that utilize post-handshake authentication, unless
the application protocol will not misbehave because of possbily
inconsistent connection states on both ends. Post-handshake
authentication also happens to be directly unsafe with some protocols,
even if resulting PSKs are not used.

There are two pieces in TLS 1.3 that actually scare me: One is 0-RTT
and the another is post-handshake authentication.

And HTTP/2 is one of the most sensitive protocols for various kinds of
security issues in underlying transport. Issues that are no problem
for most protcols can become nasty security problems in HTTP.




-Ilari

Received on Thursday, 12 July 2018 06:48:07 UTC