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

From: Nick Sullivan <[email-masked]>
Date: Sat, 08 Oct 2016 01:03:21 +0000

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.

In order to simplify the logic around dealing with post-handshake messages,
this proposal makes support for each of these modes explicit via a new
handshake extension. This change also makes the path to introducing other
types of post-handshake messages in future drafts more explicit.

PR:
https://github.com/tlswg/tls13-spec/pull/676

Nick

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 8 Oct 2016 12:02:57 +0300

> 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).

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.

-Ilari

---

From: David Benjamin <[email-masked]>
Date: Sat, 08 Oct 2016 15:06:28 +0000

On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara <[email-masked]>
wrote:

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.

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

---

From: Nick Sullivan <[email-masked]>
Date: Sat, 08 Oct 2016 16:32:32 +0000

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 <[email-masked]> wrote:

> 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.
>

---

From: David Benjamin <[email-masked]>
Date: Sat, 08 Oct 2016 16:51:17 +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
explicitly).

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.

David

On Sat, Oct 8, 2016 at 12:32 PM Nick Sullivan <[email-masked]>
wrote:

Nick

waste in bandwidth).

applications.

David

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 8 Oct 2016 19:53:00 +0300

> TLS 1.3 implementations that don't need these features.

I really don't think making KeyUpdate optional is a good idea.

SessionTicket: Just don't send it / ignore it on reception.

What makes CertificateRequest really annoying is that one can't just
simply dismiss or NAK it. There are two messages involved, one
involving a MAC.

And furthermore, one must be quite careful in use of post-handshake
auth to not get subtle security issues.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 8 Oct 2016 09:54:47 -0700

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"

-Ekr

On Sat, Oct 8, 2016 at 9:32 AM, Nick Sullivan <[email-masked]>
wrote:

>> 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
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Nick Sullivan <[email-masked]>
Date: Sat, 08 Oct 2016 20:02:52 +0000

I agree that "I don't like NST or KU" is not a very useful thing to add to
the spec. I added them as part of a general move towards clarity and
conservatism about which types of post-handshake messages are permissible
in TLS 1.3. Right now the spec is ambiguous about what each side of the
connection is supposed to do when it receives an unexpected or unknown
post-handshake message. This change hopefully makes it crystal clear: any
post-handshake message that wasn't agreed upon by both parties should be
fatal.

David suggested that the behavior with respect to post-handshake messages
should be negotiated at the application layer. This also seems reasonable,
but I worry about how this policy would be communicated from the
application layer to the TLS stack. Would the application layer be alerted
of incoming CertificateRequests and either terminate the connection or
reply with an empty certificate and finished message? If we want to support
"2018" post-handshake messages, will we just end up re-inventing this
post_handshake extension in a later draft to advertise support? Different
post-handshake messages have different uses, so I see how this more
case-by-case application-dependent policy could be more expressive than
what I proposed, but I worry we may end up with something more complex than
necessary.

In any case, post-handshake authentication as currently described is
problematic. I'd be open to seeing a text change along the lines of what
David proposed instead of the wire change I'm proposing as long as it
includes some guidance around how it should interact with policies from the
application layer.

On Sat, Oct 8, 2016 at 9:55 AM Eric Rescorla <[email-masked]> wrote:

> Consider the case of NST. Presently, a client which doesn't want
> resumption can just ignore NST,
> 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
> On Sat, Oct 8, 2016 at 9:32 AM, Nick Sullivan <[email-masked]
> > wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 10 Oct 2016 22:30:07 -0500

With respect to communicating policy from the application layer to the
TLS stack, what's wrong with David's "CertificateRequest is disallowed
by default, and the application must make a library call to enable it
for a given connection/context" proposal?  It seems fairly
straightforward in terms of API surface, to me.

You mostly mentioned this already, but this list of known message types
is another protocol surface that would need to be GREASEd.

So, on the balance, I think I'm starting to lean against this specific
proposal and more towards the text changes that David wants.

-Ben

On 10/08/2016 03:02 PM, Nick Sullivan wrote:
> I agree that "I don't like NST or KU" is not a very useful thing to
> add to the spec. I added them as part of a general move towards
> clarity and conservatism about which types of post-handshake messages
> are permissible in TLS 1.3. Right now the spec is ambiguous about what
> each side of the connection is supposed to do when it receives an
> unexpected or unknown post-handshake message. This change hopefully
> makes it crystal clear: any post-handshake message that wasn't agreed
> upon by both parties should be fatal.
>
> David suggested that the behavior with respect to post-handshake
> messages should be negotiated at the application layer. This also
> seems reasonable, but I worry about how this policy would be
> communicated from the application layer to the TLS stack. Would the
> application layer be alerted of incoming CertificateRequests and
> either terminate the connection or reply with an empty certificate and
> finished message? If we want to support "2018" post-handshake
> messages, will we just end up re-inventing this post_handshake
> extension in a later draft to advertise support? Different
> case-by-case application-dependent policy could be more expressive
> than what I proposed, but I worry we may end up with something more
> complex than necessary.
>
> problematic. I'd be open to seeing a text change along the lines of
> what David proposed instead of the wire change I'm proposing as long
> as it includes some guidance around how it should interact with
> policies from the application layer.
>
>
>
> On Sat, Oct 8, 2016 at 9:55 AM Eric Rescorla <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I could go either way on this. It seems like this pushes
>     complexity from the client to the server. 
>
>     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
>     On Sat, Oct 8, 2016 at 9:32 AM, Nick Sullivan
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>         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.
>
>         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
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>                 > not needed. Some types of
>                 connections/implementations don't need to support
>
>             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.
>              
>
>
>             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
>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=4JAV0BkSLZSEEXJ9R5Q05mVpYdsy9VXbdJ8bSwOSLFM&s=UaYcBI3XziRGVy1WUuEI3hHeHMVXitoDfwb65g7xmkQ&e=>
>
>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Oct 2016 17:29:14 +1100

> proposal and more towards the text changes that David wants.

Yes, I would rather not take NST or KU out of the mandatory set of 1.3
features.  I'm happy to have post-handshake authentication require
opt-in though.

---

From: Tom Ritter <[email-masked]>
Date: Tue, 11 Oct 2016 08:28:38 -0500

On 8 October 2016 at 11:54, Eric Rescorla <[email-masked]> wrote:
> I could go either way on this. It seems like this pushes complexity from the
> client to the server.
>

I'm concerned about the information this exposes on the wire. We've
added Record Content Type protection, so things like post-handshake
client auth can't be detected on the wire (modulo behavior/length
attacks, for which we can attempt protection with padding.)

But now we're going to say in the client's plaintext "Yea, I might
want post-handsake client auth".  And it seems like the percentage of
clients who will say that will be few and far between... leading to
more fingerprinting and a step back from where we were.

-tom

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Oct 2016 18:37:08 +0200

Hi Nick,

given my discussion with Martin in this thread
https://www.ietf.org/mail-archive/web/tls/current/msg21481.html I like
your idea of making the post-handshake messages optional since it allows
me to develop a TLS 1.3 client that is smaller in code size.

Ciao
Hannes

On 10/08/2016 03:03 AM, Nick Sullivan wrote:
> 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.
> 
> 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.
> 
> In order to simplify the logic around dealing with post-handshake
> messages, this proposal makes support for each of these modes explicit
> via a new handshake extension. This change also makes the path to
> introducing other types of post-handshake messages in future drafts more
> explicit.
> 
> PR:

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Oct 2016 10:21:50 -0700

I think it would be simpler (and deal with most cases) to only allow this
for specific application
profiles (we would then allow it in HTTP/H2, perhaps with some small -bis
RFC).

Here is a PR for this:
https://github.com/tlswg/tls13-spec/pull/680

Andrei, would this cause you any problem? My impression was that this use
case was only
about HTTP/H2.

Thanks,
-Ekr

---

From: Nick Sullivan <[email-masked]>
Date: Tue, 11 Oct 2016 17:26:02 +0000

The major thing that this proposal achieves is that it makes post-handshake
auth an optional part of the implementation. Instead of this, I would also
be in favor of a simpler change that modifies the text to say that
post-handshake CertificateRequest messages are fatal by default and only
permitted if the application permits their use in a given context (say if
the application is HTTP 1.1, only directly after requests).

Embedded implementations may choose to simply fail on unexpected
CertificateRequests, and that way not have to implement any code around
post-handshake finished messages or updating the transcript when one
arrives.

This default wording should also apply to other types of post-handshake
messages, though NST and KU could be exceptions that should always be
supported and non-fatal.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 11 Oct 2016 18:08:33 +0000

+ Mike who has additional concerns with this.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Tuesday, October 11, 2016 10:22 AM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

I think it would be simpler (and deal with most cases) to only allow this for specific application
profiles (we would then allow it in HTTP/H2, perhaps with some small -bis RFC).

Here is a PR for this:

Andrei, would this cause you any problem? My impression was that this use case was only
about HTTP/H2.

Thanks,
-Ekr

On Tue, Oct 11, 2016 at 9:37 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi Nick,

Ciao
Hannes

On 10/08/2016 03:03 AM, Nick Sullivan wrote:
> [email-masked]<mailto:[email-masked]>

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

---

From: Mike Bishop <[email-masked]>
Date: Tue, 11 Oct 2016 18:21:07 +0000

There are a couple of scenarios we need to keep in mind:

1.       Existing HTTP/1.1 exchanges over upgraded TLS clients.  If we need a brief RFC that says post-handshake client auth is allowed for HTTP/1.1 over TLS 1.3, that’s fine.

2.       Client authentication in HTTP/2.  Slightly longer RFC for this (but possibly the same one) that says post-handshake client auth is allowed for HTTP/2, then describing how to use the context (and new HTTP/2 frames, if needed) to bind the PHA exchange to one or more streams.

3.       Secondary server authentication in HTTP/2.  This approach still doesn’t give a clean way to do this, unless we use exporters and roll our own.  That has proven to be a little hazardous to everyone’s peace of mind, but remains something we can refine in the future.

What concerns me more, though, is the prospect that a lot of TLS implementations would simply omit support.  Obviously, it’s not used in most HTTP sessions, and you may be an implementation whose niche doesn’t require supporting it – but since the application profile allows it, you still need to know how to decline if asked.  If it’s allowed in HTTP, which I assume is a supported workload for most implementations, then it’s allowed in your application profile and therefore prohibiting it by default doesn’t seem like it buys you much.  Having a simple way to disclaim support, either at connection time or upon receiving a challenge, seems like it provides more simplicity for the implementations that want to omit it.

From: Andrei Popov
Sent: Tuesday, October 11, 2016 11:09 AM
To: Eric Rescorla <[email-masked]>; Hannes Tschofenig <[email-masked]>; Mike Bishop <[email-masked]>
Cc: [email-masked]
Subject: RE: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Tuesday, October 11, 2016 10:22 AM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

Here is a PR for this:

Thanks,
-Ekr

Ciao
Hannes

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 12 Oct 2016 03:10:54 -0400

> messages, though NST and KU could be exceptions that should always be

I don't see the advantage of putting this on the wire during the intial
handshake.

In the HTTP case, either (a) the requested resource wants a new
authentication or (b) it does not.  If it does not want new
authentication (b), no CertificateRequest message will be forthcoming.
If it does want new authentication, then either (a.1) it requires it
(meaning the HTTP request will fail if the client can't offer a good
cert), or (a.2) it just hopes to send a different response based on some
new authentication. in (a.1), the request will simply fail when the
client can't send a client cert.  So the the client needs to know how to
at least reject it gracefully.  This is the case even when the client
fully implements client auth anyway, since it might not have a client
cert available.

I don't think it's too much to ask that implementations be able to
reject a post-handshake CertificateRequest gracefully, even if they have
no intention of ever implementing a proper Client Certificate response.

Changes to the wire format here only seems to give a small advantage to
the server in one corner case for HTTP (a.2, when the client has no
implementation of post-handshake client certs): the server can
confidently send the certRequest, knowing that the client will know how
to deal with it.  But now clients will also need to decide whether they
should indicate "i do post-handshake client auth" even if they have no
likely client certs available at the time of session establishment, and
to keep track of how they signaled over the lifetime of the session (how
does this interact with session resumption?).  I don't think that's a
complexity win overall.

If we make it clear that TLS 1.3 clients MUST at least know how to
gracefully reject a post-handshake Certificate Request, i think that
leaves the ecosystem as a whole with less complexity, and reduces the
fiddliness of the wire format.

           --dkg

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 12 Oct 2016 11:17:24 +0300

> no intention of ever implementing a proper Client Certificate response.

Unfortunately, currently it is too much:

One can't just send a message saying "NAK CertficiateRequest X", since
that message is followed by Finished message, that is quite annoying
to compute (even requires forkable hash, when nothing else requires
that, and if one is to be able to freeze connection, requires very
exotic features from hash implementation.

-Ilari

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Oct 2016 10:36:01 +0200

I agre with Ilari. Currently, the way to reject a request is more than
just saying "no, thanks.".

---

From: David Benjamin <[email-masked]>
Date: Wed, 12 Oct 2016 14:56:16 +0000

Even without the Finished computation, rejecting a CertificateRequest would
hit the same unboundedness problem the previous generation of KeyUpdate had.

Our implementation currently treats all post-handshake CertificateRequests
as a fatal error. I think the only context where we'd conceivably change
this is if we need to support HTTP/1.1 + TLS 1.3 + reactive client-auth,
which means it would be under the same constraints the old renego hack was
under. (Forbidden by default, forbidden in HTTP/2, all application
interleave forbidden to prevent unboundedness, and only handled if exactly
between HTTP/1.1 request and response.)

This entire feature is a legacy hack to retain support for some legacy
mechanisms by HTTP/1.1 and others. We need to have some story here, but it
should not burden the protocol any more than is absolutely necessary. I
think EKR's PR is the simplest option here.

David

On Wed, Oct 12, 2016 at 4:36 AM Hannes Tschofenig <[email-masked]>
wrote:

TLS mailing list

[email-masked]