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

From: Martin Thomson <[email-masked]>
Date: Wed, 18 May 2016 10:10:29 -0400

I just posted this:

https://datatracker.ietf.org/doc/draft-thomson-tls-0rtt-and-certs/

It's fairly self explanatory.  The idea is to create a way to signal
that the client wants the server to re-authenticate itself, even if it
successful in using a pre-shared key.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 20 May 2016 22:41:15 +0300

> successful in using a pre-shared key.

- How is the capability signaled? New flag bits in session ticket
  for these ciphersuites?
- This mechanism has session ticket lifetime limited by the certificate
  lifetime, right?

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Fri, 20 May 2016 16:43:20 -0400

> - How is the capability signaled? New flag bits in session ticket

Yes, I realized it yesterday that I had neglected to define the bit
that this needs.  Of course a client could decide to do this
unilaterally.

> - This mechanism has session ticket lifetime limited by the certificate

There is a session ticket, which has a lifetime.  The certificate has
to be constant, so if that expires, then you can't connect.  So yes,
both limits would seem to apply.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 20 May 2016 23:58:23 +0300

> both limits would seem to apply.

Also, the effective lifetime of the cert can be good bit shorter than
the nominal one (e.g. 90 day cert renewed at 60 days). And most
software doesn't support overlapping certs...

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 May 2016 14:00:22 -0700

> - How is the capability signaled? New flag bits in session ticket

I just uploaded -01 that corrects this oversight.

I have raised https://github.com/martinthomson/tls-0rtt-and-certs/issues/1
which tracks whether certificates might change.

---

From: Kyle Nekritz <[email-masked]>
Date: Wed, 25 May 2016 02:06:51 +0000

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?

Requiring the certificate to remain the same will make rollout of a new certificate more challenging (even with longer-lived certificates), particularly on distributed servers where the update is not immediate fleet-wide. It will also add noise to metrics when rolling out a new certificate when ideally you want everything relatively constant (to be confident the new certificate is working properly).

Kyle

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Tuesday, May 24, 2016 5:00 PM
To: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Asking for certificate authentication when doing 0-RTT

On 20 May 2016 at 12:41, Ilari Liusvaara <[email-masked]> wrote:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf
>> .org_doc_draft-2Dthomson-2Dtls-2D0rtt-2Dand-2Dcerts_&d=CwICAg&c=5VD0R
>> TtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=cJNWhprXjoJ1zN66VdIpTtqs
>> s54Z2N5U0l61Yj7RL_I&s=hd6AtOpOp_1ULpSo_TRrpuxmTwQKZrjr6oz0Tm0hASs&e=
>>
>> that the client wants the server to re-authenticate itself, even if 
>> it successful in using a pre-shared key.
>

_______________________________________________
TLS mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=cJNWhprXjoJ1zN66VdIpTtqss54Z2N5U0l61Yj7RL_I&s=2divOhlUGndixU6HSAFfmzyMt_Ufkc58GwbPbrg19GM&e=

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 May 2016 21:18:27 -0700

> 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 ce…

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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 25 May 2016 10:47:17 -0500

> think that we are good.  Probably.  If anyone disagrees it would be

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.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 May 2016 14:55:04 -0700

I think that there are four levels of continuity that make sense here :

1. None. Anthony can change.
2. Server name. I.e. SNI stays constant.
3. Public key (and SNI) stays constant.
4. The certificate stays the same.

The use case of short-lived certs is served by 2. 3 might also work. I
think that 4 is too restrictive, as we have established. 1 just doesn't
seem plausible, since the psk_identity will be cached against a name in
almost every case I can imagine.
On 26 May 2016 01:47, "Benjamin Kaduk" <[email-masked]> wrote:

On 05/24/2016 11:18 PM, Martin Thomson 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?

-Ben