Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

David Benjamin <> Sat, 08 October 2016 16:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 048C6129466 for <>; Sat, 8 Oct 2016 09:51:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.695
X-Spam-Status: No, score=-5.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] 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 ztU9Jzs2nyTv for <>; Sat, 8 Oct 2016 09:51:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 76E75129426 for <>; Sat, 8 Oct 2016 09:51:30 -0700 (PDT)
Received: by with SMTP id q192so74898045iod.0 for <>; Sat, 08 Oct 2016 09:51:29 -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=mhdVlkfkrnffe7cdhlyML9Y2WQa7JEnUBvRv7ubiIkA=; b=nVIUYDEt5OoYatKcLD5R4oyo/AfqDy45tuN5nUzUa8lVk7NEkMdflZPWV5YNkMBdRf mQnlmVondZjMVkUhlFtr5I4dsg2Vvh09QgDGfGa8z23Uq4M5HQqewapKedHgAtR3UH4J 2Kx6xfBthixaJ/GQa81NoJ5/YhAiwt2Mg2Jz8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mhdVlkfkrnffe7cdhlyML9Y2WQa7JEnUBvRv7ubiIkA=; b=mEBll0E2LVZetQM2js9/uHpR3ZEr5y+RAmeDiwTn92AXk3GqkHBZkDKdSINY7jviUL MEp0tTrU4tIts3bncgsDcjhDQ8n0/tU6gLsiB/CtziuiqfbjLjXmMhewVsNZxAAq4Aon k35PormG8fgNF+39zsPHAvZJFP7eKJKdQlR57Vgf+kqGGoiP6hsBjT+lsgLOCKbKY31r qJNQVBMqDiLLp50GnU7AoJPoavRPYQWyma5USeUGRq+SOM6MDvms5eb5/VSYQb38ZnEg t29CcMILkfn6WRzIEHGJ/F5drN3gcyBn1q5sE9c8o2An8bKFd1I/iFvmRktOJ0f/S3YY JGmQ==
X-Gm-Message-State: AA6/9Rk6FMbB9Ukz3rtfqEPJSQhcdPRSZbivVSHPiqYhzzeu0SksY3IwHbmuylNRSBJ00YXswLtmJYCnFcpO6/PS
X-Received: by with SMTP id 62mr24273698ioo.142.1475945489165; Sat, 08 Oct 2016 09:51:29 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Sat, 08 Oct 2016 16:51:17 +0000
Message-ID: <>
To: Nick Sullivan <>, Ilari Liusvaara <>
Content-Type: multipart/alternative; boundary="001a113fd05a97763a053e5d569b"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)
X-Mailman-Version: 2.1.17
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: Sat, 08 Oct 2016 16:51:33 -0000

Right, but making it an extension does not really capture the complexities
of post-handshake auth. What's needed is mostly spec text, not wire
changes. The text should say something to the effect of unexpected
CertificateRequests are always fatal to the connection. By default, all
CertificateRequests are unexpected. An application protocol may define this
otherwise in certain contexts with certain semantics. For instance, a spec
for reactive client auth over HTTP/1.1 might say a CertificateRequest just
before a response is legal (but not in the middle of one). HTTP/2 would not
say such a thing, so it would forbid all CertificateRequests implicitly
(just like it currently forbids renego, though that sadly had to be done

Unless the application protocol needs some help with the negotiation,
there's no need to add a separate negotiable boolean at the TLS layer. We
assume both sides know what application protocol they're using, just like
we assume both sides know they're speaking TLS.


On Sat, Oct 8, 2016 at 12:32 PM Nick Sullivan <>

I'm not proposing any new post-handshake authentication mechanisms or
anything relating to HTTP/2 renegotiation in this change. I'm simply making
support for the existing post-handshake messages optional.

With this change, if the client does not opt in, unexpected
CertificateRequests are fatal to the connection. Same with unexpected
KeyUpdates and SessionTickets. This will hopefully reduce the complexity of
TLS 1.3 implementations that don't need these features.


On Sat, Oct 8, 2016 at 8:06 AM David Benjamin <> wrote:

On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara <>

On Sat, Oct 08, 2016 at 01:03:21AM +0000, Nick Sullivan wrote:

> There has been a lot of discussion lately about post-handshake messages

> that do not contain application data and how to handle them. This PR is an

> attempt to make the story more explicit by adding a new post_handshake

> extension to TLS 1.3.


> Supporting all types of post-handshake messages can require extra

> complexity and logic, even when the features that these messages enable

> not needed. Some types of connections/implementations don't need to

> key updates (some unidirectional connections), session tickets (pure PSK

> implementations) and post-handshake client auth (most browsers). These are

> all currently SHOULDs in the spec and they don't need to be.

Post-handshake authentication is the only one of these that is genuinely

annoying. This is because you can't even reject it without a MAC, that

additionally continues the handshake hash.

KeyUpdate is rather simple, and NST can just be ignored (leading to some

waste in bandwidth).

Yeah, after the fix to how KeyUpdate is acked, I don't think we'd have
problems with either of the way, while post-handshake auth is indeed

Furthermore, the post-handshake authentication mechanism doesn't look to

be featureful enough for kind of post-handshake auth e.g. HTTP/2 wants,

And there are serious questions about how it should interact with


An extension also doesn't really capture things if we intend for, say, this
to be used for legacy protocols like HTTP/1.1 (where we don't have as rich
a framing layer) but not HTTP/2 (where we do and can use it as a substrate
for all this silliness). I was anticipating that, if this ends up being
used in the HTTP world like renego is, it would be like our renego stuff:
off by default, forbidden in HTTP/2, and with all interleave forbidden.

Further, what useful thing could a server even do with this extension?
Decline to do post-handshake auth doesn't work. Either the application
protocol doesn't use post-handshake auth (please pick this one) or it does.
One doesn't need to send a client_writes_first extension in HTTP/1.1.

Post-handshake auth another knob on the TLS <-> application protocol
boundary. This means each application protocol must specify for itself what
post-handshake auth means: what to do with the context field, when it may
be received, what it does to application flow, etc. Then the spec must be
clear that if the application protocol does not opt in, CertificateRequest
is forbidden. A CertificateRequest at an unexpected point (say, half-way
through a HTTP/1.1 body) is also forbidden. Also make it clear this is for
legacy protocols and new ones do not use it.

This is analogous to how HTTP/2 forbids renego at the spec level. (TLS 1.2
got the "defaults" for renego wrong.) No one ever wrote down the exact
rules for the client-auth/renego hack in HTTP/1.1, but whatever spec does
this for post-handshake auth should do the same for renego.

It is a lot of spec work for such a tiny-seeming feature, but this is
consistent with how messy the feature actually is.