Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3

From: Russ Housley <[email-masked]>
Date: Thu, 2 Feb 2017 10:20:09 -0500

Proposed update to Section 4.1.1 of draft-ietf-tls-tls13-18

OLD:

  The server indicates its selected parameters in the ServerHello as
  follows:

  -  If PSK is being used then the server will send a "pre_shared_key"
     extension indicating the selected key.

  -  If PSK is not being used, then (EC)DHE and certificate-based
     authentication are always used.

  -  When (EC)DHE is in use, the server will also provide a "key_share"
     extension.

  -  When authenticating via a certificate (i.e., when a PSK is not in
     use), the server will send the Certificate (Section 4.4.1) and
     CertificateVerify (Section 4.4.2) messages.

NEW:

  The server indicates its selected parameters in the ServerHello as
  follows:

  -  If PSK is not being used, then (EC)DHE and certificate-based
     authentication are always used, and the server will:

     --  provide a "key_share" extension; and

     --  send the Certificate (Section 4.4.1) and CertificateVerify
         (Section 4.4.2) messages.

  -  If PSK (without DH or ECDH) is being used, then the server sends a
     "pre_shared_key" extension to indicate the selected key.

  -  If PSK and (EC)DH are being used together, then the server will:

     --  sends a "pre_shared_key" extension to indicate the selected
         key;

     --  provide a "key_share" extension; and

     --  send the Certificate (Section 4.4.1) and CertificateVerify
         (Section 4.4.2) messages.

END

Many thanks to Sean Turner for turning this into a PR for me:
https://github.com/tlswg/tls13-spec/pull/870

Thanks,
  Russ

---

From: David Benjamin <[email-masked]>
Date: Thu, 02 Feb 2017 16:24:43 +0000

I think this is much clearer, except for one bullet point below:

On Thu, Feb 2, 2017 at 10:22 AM Russ Housley <[email-masked]> wrote:

> [...]

This last bullet here contradicts what specification says elsewhere. From
4.4.1:

"""
The server MUST send a Certificate message whenever the agreed-upon key
exchange method uses certificates for authentication (this includes all key
exchange methods defined in this document except PSK). This message conveys
the endpoint’s certificate chain to the peer.
"""

(Otherwise we defeat the point of resumption and lose PSK-based identities.)

Like MT, I am interested in a mode with both (right now we have a ticket
renewal cliff because only the initial handshake does an online signature),
but we'll need to work out the exact semantics. Going from one identity to
two identities, especially when one is added partway through the stream
(consider 0-RTT) has a lot of sharp edges.

Since this can easily be added as an extension (and would need one anyway
for negotiation), I think it's better to do it as a later document, so we
don't delay what we've done already or rush in a combined mode without
considering all the details. The document would just say "when PSK and
fancy_new_extension are both negotiated, then the server will [...]".
Plenty of extensions have modified the handshake message flow.

David

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Feb 2017 06:45:49 -0800

I agree with David here. Specifically, I think.

- The base specification should continue to forbid certificates in
combination with PSK
- We should at some point contemplate an extension that allows the use of
certificates in combination with PSK
- The base spec should be factored in such a way as to make that extension
easy.

-Ekr

On Thu, Feb 2, 2017 at 8:24 AM, David Benjamin <[email-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>