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

Eric Rescorla <> Sat, 08 October 2016 16:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40B6E129426 for <>; Sat, 8 Oct 2016 09:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7oW7ZRMBSBFy for <>; Sat, 8 Oct 2016 09:55:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD57B1295D2 for <>; Sat, 8 Oct 2016 09:55:28 -0700 (PDT)
Received: by with SMTP id w3so21804083ywg.1 for <>; Sat, 08 Oct 2016 09:55:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hMLn7zbLVjJzxrKYxe3EH7mXCNow2OHyRwjJXEzKln0=; b=Y1z79/mcfGxzPenMBYAGASeSJO/Vj++Noi5rCJ6Pu7ZaiP/eicsFDUghKovqSTv998 /e12kd9O7sW+Ny/rdFpUtMK3ueQAk0TstZlh8SeGRYysxnYD62GRLFGbEKCaLoM3z8/L 2MwKeMq2WZO0blEn4AxbwHRUuMZyKo3s6cmx18eiz3DpXHyJ7wWkgXxvvqHWPezYqsTz rTLA62XY/+CaGbJ+pfY4oMl02XQstqsk+Df+hQ+zsEpJMLEfa7+gIKhpOYyecs+Hd85c VYz5VPyDxAi1SNVF7RcbC7h1tNmVXmB775/tRN49bQTC1TGJjS6WPNI8PK2CF8v/zmkI n04A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hMLn7zbLVjJzxrKYxe3EH7mXCNow2OHyRwjJXEzKln0=; b=g3udVMKe4TRBRfru2v26px7pcAWVEPDM/1y7K3ysVZyburaOnqH9az5CnO7BP70wEE n3xa1ZfNJ2rrM7qFomelrM6GmE7K3APCnglUbPaxaZhI/ZT2qstqstqO4Ng9/hMoL4ni f7E2+7SX+3BNDEVEF59MQNXmssq563FpHGKyTcYtL3htnWNtXg7cpNzoFx/21dmj9qWK GN4+20Rc7CwyxCDET1mjwlMPluLxbG6L1vroRM2x+BLCXNBTImwEH7FCjadetkMjewuD 2E5RKZzfFu05f2XG7nM7+7kVanpRiqS9Kn5JHIwUb49Tdlm6uySHUoypw6dIB6XwPnJA zztA==
X-Gm-Message-State: AA6/9RmR9NXs5+CmMczouzc0XhGlXWA/yWNmPRsoM5AyC/4totAsSXoiUVDWHCkMUcgzn13DFqxWoktZsLkNFQ==
X-Received: by with SMTP id u197mr19399600ywc.146.1475945727947; Sat, 08 Oct 2016 09:55:27 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 8 Oct 2016 09:54:47 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Eric Rescorla <>
Date: Sat, 08 Oct 2016 09:54:47 -0700
Message-ID: <>
To: Nick Sullivan <>
Content-Type: multipart/alternative; boundary="94eb2c0b0f68d2a653053e5d64af"
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:55:31 -0000

I could go either way on this. It seems like this pushes complexity from
the client to the server.

Consider the case of NST. Presently, a client which doesn't want resumption
can just ignore NST,
but in your proposed change, the server needs to read this extension and
then conditionally send
NST, and the client still needs the logic to detect unexpected handshake
messages and abort
on them.

As I said, I could go either way, and I do think it's potentially useful to
be able to say "I won't do
post-handshake client auth" and even more useful to be able to say "I would
do post handshake
message X which will be invented in 2018" (but of course we can register an
extension for
that then), but less useful to say "I don't like NST or KU"


On Sat, Oct 8, 2016 at 9:32 AM, 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.
> Nick
> On Sat, Oct 8, 2016 at 8:06 AM David Benjamin <>
> wrote:
>> On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara <>
>> wrote:
>>> 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 are
>>> > not needed. Some types of connections/implementations don't need to
>>> support
>>> > 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
>> horrific.
>>> 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
>>> applications.
>> 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.
>> David
> _______________________________________________
> TLS mailing list