Re: [TLS] I-D Action: draft-housley-tls-tls13-cert-with-extern-psk-02.txt

[David Benjamin <[e-mail]>]

The resumption flow in this draft looks odd to me. While the handshake flow
is the same, the use cases differ between which identity should be in play
and when to use it. Separate extensions and documents may be better. (I
suppose saying the semantics change completely between resumption and
external PSK is also an option, but that seems weird?)

First, identities:

In the external PSK use case, my read is you intend for the certificate to
still be the server identity? It seems external PSK is just meant as extra
input to the key schedule and not authentication since it may be shared
amongst a group. (I'll note that, if your concern is we've lost all our
asymmetric crypto, trusting the CertificateVerify for authentication is a
little fuzzy. Is the scenario that the group is trusted not to attack each
other?)

The use case for resumption is very different. The one I'm familiar with is
to avoid a resumption/0-RTT cliff when the client considers the
CertificateVerify expired. As before, It needs to be clearly defined which
identity is in use. This is particularly complicated with 0-RTT, where only
the PSK is available for early data, and swapping identities is
problematic. (HTTP/2 cross-name pooling gets especially messy.)

This conflicts with the external PSK case which wants the certificate
identity. The document addresses this in 3.3, by requiring the two to be
identical, but this breaks much of the use case. It's rather common for
servers to rotate certificates without dropping their session cache, to
avoid a resumption cliff. (This assumes the protocol, e.g., HTTPS, does not
care exactly which certificate is used, just that they are valid for a
name.) This proposal leaves a gap in that scenario and means such servers
must add extra state to sessions and conditionally disable 0-RTT in some
cases.

Such servers could fall back to 1-RTT resumption, which could use the
certificate and ignore the PSK, but this mechanism is not very useful
without 0-RTT. The benefit of 1-RTT resumption is bandwidth and CPU from
not sending the certificate. But 1-RTT resumption/certs sends the
certificate anyway. You may as well just do a full handshake.


Second, when to use it:

In the external PSK case, I gather the goal is to use the external PSK all
the time? It carries no auth, so expiry is fuzzy. If you support it, you
enable it.

The resumption use case involves the client expiring the CertificateVerify
signature. This is purely client policy which the server doesn't know a
priori. Long before the signature is expired, the server shouldn't use
tls_cert_with_psk because it's a bandwidth+CPU waste. After the signature
has expired is too late. The client wouldn't be willing to encrypt early
data at that point. (The client would also need to account for servers that
don't support this draft.) tls_cert_with_psk should be used before but near
expiry.

The advertisement then wants extra meaning: I offered you a PSK identity
(with some early data if you accept it) that I will accept instead of your
certificate, but it is nearing expiry. Renewals will be rejected soon. So,
in addition to using the PSK, consider re-asserting ownership of your
certificate, to keep renewals useful.


These two together suggest a slightly different design for in the
resumption case.
1. If the client's session is, say, 75% of the way through the
CertificateVerify life adds the extension. Otherwise, it omits it.
2. The server can acknowledge this extension to do PSK+Certs. Probably with
0-RTT as it's largely pointless otherwise.
3. The connection is authenticated with the PSK as before.
4. But any tickets issued off the connection authenticated with the
certificate, which may be different.


Finally, on a more minor note:

   TLS 1.3 does not permit the server to send a CertificateRequest
   message when a PSK is being used.  This restriction is removed when
   the "tls_cert_with_psk" extension is negotiated, allowing the
   certificate-based authentication for both the client and the server.
   If certificate-based client authentication is desired, this is
   accomplished by the client sending the Certificate and
   CertificateVerify messages as described in Sections 4.4.2 and 4.4.3
   of [RFC8446].

This restriction should be retained with 0-RTT, otherwise things become
really strange with the connection's client identity changing partway
through.

David

On Wed, Sep 26, 2018 at 3:10 PM Russ Housley <[e-mail]> wrote:

> I believe that this version resolves all of the issues that were raised
> during the Montreal meeting and the mail list.
>
> The biggest change: This version allows external PSKs and resumption PSKs
> to be used withe certificates.
>
> Russ
>
>
>
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Transport Layer Security WG of the IETF.
> >
> >        Title           : TLS 1.3 Extension for Certificate-based
> Authentication with an External Pre-Shared Key
> >        Author          : Russ Housley
> >       Filename        :
> draft-housley-tls-tls13-cert-with-extern-psk-02.txt
> >       Pages           : 11
> >       Date            : 2018-09-26
> >
> > Abstract:
> >   This document specifies a TLS 1.3 extension that allows a server to
> >   authenticate with a certificate while also providing a pre-shared key
> >   (PSK) as an input to the key schedule.
> >
> >
> > The IETF datatracker status page for this draft is:
> >
> https://datatracker.ietf.org/doc/draft-housley-tls-tls13-cert-with-extern-psk/
> >
> > There are also htmlized versions available at:
> >
> https://tools.ietf.org/html/draft-housley-tls-tls13-cert-with-extern-psk-02
> >
> https://datatracker.ietf.org/doc/html/draft-housley-tls-tls13-cert-with-extern-psk-02
> >
> > A diff from the previous version is available at:
> >
> https://www.ietf.org/rfcdiff?url2=draft-housley-tls-tls13-cert-with-extern-psk-02
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>