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

David Benjamin <> Wed, 26 September 2018 22:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACBCF130DE4 for <>; Wed, 26 Sep 2018 15:00:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.706
X-Spam-Status: No, score=-9.706 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d4pjdYaz54XL for <>; Wed, 26 Sep 2018 15:00:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::843]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 197F5130DDE for <>; Wed, 26 Sep 2018 15:00:49 -0700 (PDT)
Received: by with SMTP id e9-v6so625126qtp.7 for <>; Wed, 26 Sep 2018 15:00:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vg0iScLyR2A9g5SWw09Lr7muTjFCgdTwDEOKrRCxS90=; b=gf+cbvld55kzBDtxn9ODM4lUrjNUhrh5GSvlO2f7vJ7+Q5FYw01vvhSkI2o5iAi8gb +vqdNRRxMeLEOnVNTXcRMuyNDitNFjLojL4GyIuL7EsPQer1yHYe9EHBV1C5K5iJTbOz 1Eb832EqEn4egq7WrcL7xoN5fbE7IZQR4wUng=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vg0iScLyR2A9g5SWw09Lr7muTjFCgdTwDEOKrRCxS90=; b=c1ccLC+rJnuSIzVYKa26xjZQqi0GOSJ0XlfT0YkdRZD3WBZruVdGa4/YfJE6JNk9nI 0D1OiCzsmsGTeRU1T8oBj9eXaNoMPkptB7pbwDKhM8Lu3Zsrzpp8QkRTjy9f9GSLM0aH 6AO75SF4fAyrLrosmyWG0mAZBXrJQMt6h2udzC76ZCifRq/Addv/R0hXH7vH0nGKO4Va EXgXD+4haycDOYjDKWRyBp95Z7/Y84puxnrMQciK+YgZMf7Pfl5iOwnswR9odXTaS8y8 UT4Ue1EO/6KDw3oLx4oLlSjFQpbVzkSA7e+y4vqtJ6yfX4iNA7OjU/U2fS5CW+MSHxyV QV8Q==
X-Gm-Message-State: ABuFfoiXPCvU089epDz7k+478CZhapYW4vI8xNOgcsL4yhOfPsBHfsVg ML8cc3g2u1y+jlSkfzjNSKFgzSO/cCcVJiUUIXj9KwA=
X-Google-Smtp-Source: ACcGV62TpxS1evwLwlqsMsqXZ6klM+G2U1x27y/xLNTt549PqRW88S/Rh7sx6IdVc8aweVa+c71L3Td5C2ywdTgRNQU=
X-Received: by 2002:ac8:3ac3:: with SMTP id x61-v6mr6261805qte.85.1537999247881; Wed, 26 Sep 2018 15:00:47 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Wed, 26 Sep 2018 17:00:36 -0500
Message-ID: <>
To: Russ Housley <>
Content-Type: multipart/alternative; boundary="000000000000d6538e0576cd5a53"
Archived-At: <>
Subject: Re: [TLS] I-D Action: draft-housley-tls-tls13-cert-with-extern-psk-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Sep 2018 22:00:53 -0000

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

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

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

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


On Wed, Sep 26, 2018 at 3:10 PM Russ Housley <> 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:
> >
> >
> > There are also htmlized versions available at:
> >
> >
> >
> > A diff from the previous version is available at:
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at
> >
> > Internet-Drafts are also available by anonymous FTP at:
> >
> _______________________________________________
> TLS mailing list