Re: [TLS] PR#634: Registry for TLS protocol version ID

[Martin Thomson]

On 13 October 2016 at 12:07, Eric Rescorla  wrote:
> I assume you would prefer hex, i.e., 0x0303?

Yeah, that would be nice: it's recognizably the same as the old one that way.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#634: Registry for TLS protocol version ID

[Eric Rescorla]

On Wed, Oct 12, 2016 at 5:55 PM, Martin Thomson 
wrote:

> On 13 October 2016 at 10:00, Eric Rescorla  wrote:
> > I would prefer we not merge this PR.
>
> I concur, though I would prefer if we stopped using the strange { 3, 3
> } notation for versions, it's not useful and it implies a significance
> to the separation that just doesn't exist*.
>

I assume you would prefer hex, i.e., 0x0303?


[*] One caveat: you will likely be very sad if you try to change that
> first octet in a ClientHello.
>

Indeed.

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#634: Registry for TLS protocol version ID

[Martin Thomson]

On 13 October 2016 at 11:59, Dave Garrett  wrote:
> One added feature we get with this registry definition is a range of 
> codepoints for private experimental use. Formal definition might not be 
> strictly needed here, though it shouldn't hurt.

The same can be achieved by saying "future versions of TLS will not
use version numbers higher than 0x3fff; values with the top bit set
are reserved for legacy versions of DTLS; values with the two bits set
to 01 are reserved for experimentation".  We don't need IANA to look
after that.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#634: Registry for TLS protocol version ID

[Dave Garrett]

On Wednesday, October 12, 2016 07:00:34 pm Eric Rescorla wrote:
> This PR involves two changes:
> 
> 1. Attaching the term "ID" to version and defining new enum code points.
> 2. Creating a registry
> 
> The first of these seems obfuscatory and unhelpful. The second just seems
> unnecessary. Other specifications other than new versions of TLS won't be
> adding new code points, so I don't see how a registry helps.
> 
> I would prefer we not merge this PR.

One added feature we get with this registry definition is a range of codepoints 
for private experimental use. Formal definition might not be strictly needed 
here, though it shouldn't hurt.

My reasoning for the explicit use of "ID" is that it would be more clear to use 
the term "version ID" to refer to the arbitrary codepoints (e.g. 0x0304) and 
simply "version number" to refer to the more descriptive "TLS 1.3". Both do end 
up on-the-wire; the former in the version fields and the later in context 
strings, which is one of the reasons why I think being more explicit here may 
be a good idea.

The registry was first suggested by Daniel Kahn Gillmor in prior mailing list 
discussion around rebranding to TLS 2.0 (which we're treating as a separate 
issue, at the moment). I think it makes sense and I would prefer it be merged, 
but I don't ascribe very high importance here.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#634: Registry for TLS protocol version ID

[Martin Thomson]

On 13 October 2016 at 10:00, Eric Rescorla  wrote:
> I would prefer we not merge this PR.

I concur, though I would prefer if we stopped using the strange { 3, 3
} notation for versions, it's not useful and it implies a significance
to the separation that just doesn't exist*.

[*] One caveat: you will likely be very sad if you try to change that
first octet in a ClientHello.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Early code-point assignment request for draft-davidben-tls-grease-01

[Eric Rescorla]

I am fine with this.

-Ekr


On Wed, Oct 12, 2016 at 4:34 PM, Joseph Salowey  wrote:

> We have received a request for early code-point assignment of values for
> draft-davidben-tls-grease-01.  Please respond to this list of you have
> concerns about these assignments by October 28, 2016.
>
> Thanks,
> J
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Early code-point assignment request for draft-davidben-tls-grease-01

[Joseph Salowey]

We have received a request for early code-point assignment of values for
draft-davidben-tls-grease-01.  Please respond to this list of you have
concerns about these assignments by October 28, 2016.

Thanks,
J
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#634: Registry for TLS protocol version ID

[Eric Rescorla]

On Wed, Oct 12, 2016 at 3:26 PM, Sean Turner  wrote:

> Al,
>
> David Garrett has generated PR#634 (https://github.com/tlswg/
> tls13-spec/pull/634) to "explicitly [rename] the protocol version fields
> as IDs and defines a registry for all values, as they're really just
> arbitrary codepoints at this point.”  Note that there are no bits on the
> wire changes as result of this PR, but it does establish more process; if
> we’re publishing a new TLS version there’s already be lots of process this
> won’t be the straw that breaks the camel’s back.  We’d like to get a sense
> as to whether this PR should be merged - please provide any comments on
> merging this PR by Friday (10/14).
>
>
This PR involves two changes:

1. Attaching the term "ID" to version and defining new enum code points.
2. Creating a registry

The first of these seems obfuscatory and unhelpful. The second just seems
unnecessary. Other specifications other than new versions of TLS won't be
adding new code points, so I don't see how a registry helps.

I would prefer we not merge this PR.

-Ekr

J
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#634: Registry for TLS protocol version ID

[Salz, Rich]

> David Garrett has generated PR#634 (https://github.com/tlswg/tls13-
> spec/pull/634)

+1


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] PR #672: Finished Stuffing/PSK Binder

[Sean Turner]

All,

We’re looking to land PR#672 (aka Finished Stuffing/PSK Binder):
https://github.com/tlswg/tls13-spec/pull/672

It looks there’s been some discussion, but that the issues have been largely 
resolved.  Please send any comments you have by Friday (10/14) so that we can 
address them.  Barring that we’ll instruct ekr to land the PR then.

J
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] PR#634: Registry for TLS protocol version ID

[Sean Turner]

Al,

David Garrett has generated PR#634 
(https://github.com/tlswg/tls13-spec/pull/634) to "explicitly [rename] the 
protocol version fields as IDs and defines a registry for all values, as 
they're really just arbitrary codepoints at this point.”  Note that there are 
no bits on the wire changes as result of this PR, but it does establish more 
process; if we’re publishing a new TLS version there’s already be lots of 
process this won’t be the straw that breaks the camel’s back.  We’d like to get 
a sense as to whether this PR should be merged - please provide any comments on 
merging this PR by Friday (10/14).

J
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ALPN with 0-RTT Data

[David Benjamin]

On Wed, Oct 12, 2016 at 5:07 PM Kyle Nekritz  wrote:

>
> Reordering the ALPN offer has a couple advantages:
>
> * It explicitly defines the protocol that the 0-RTT data is using on that
> connection. Without this, both the client and the server must independently
> store the ALPN in use
> (of course the server can put it in the ticket). While this should work if
> implemented properly, there is nothing in the protocol that enforces they
> match before the server accepts the data. If the client ALPN offer does
> happen to change, it’s even possible
> for the selected ALPN to be one that the client didn’t even offer.
>

The client shouldn't offer 0-RTT on a session which predicts an ALPN that
it doesn't accept. This is consistent with the client not wanting to offer
session that uses a cipher it doesn't support. That is illegal already.

(Note clients already must have code for checking if an ALPN is acceptable
because that's what happens when a server responds. The nice thing about
the session-remembering algorithm is it involves no new codepaths apart
from a simple equality check. Clients offer parameters and confirm
acceptability of a single one, servers select given an offer.)


> * If the client knows out-of-band (or learns over the application
> protocol) that the server supports multiple protocols, it will not be able
> to use its current connection to
> start up a 0-RTT connection over the new protocol.
>

Why wouldn't it have negotiated that protocol over ALPN originally? One
should not need 0-RTT to unlock ALPN protocols.


> * I think realistically for many clients the protocol used to send 0-RTT
> data will end up being the only protocol that can be used on that
> connection, even if 0-RTT is rejected.
> Rejected 0-RTT data can’t be resent 1-RTT if a different application
> protocol is used, and it’s difficult API-wise to tell the higher layer
> “Your http/2 early data failed, but you can send http/1.1 requests if you
> want”. Thus it makes sense for these clients
> to advertise the 0-RTT data’s application protocol as the most preferred.
>

ALPN protocol switching (or any other connection property) on 0-RTT rejects
is always something a client must account for. I think your proposal has
the same problem. Perhaps the server had to turn h2 off for some reason.
You cannot assume the server's configuration remains unchanged. It is an
excellent prediction, but it is only a prediction.

A 0-RTT reject for a client ultimately must look like a retry. Everything
you ever wrote on the socket was discarded. It also must be bubbled up
sufficiently high that all connection properties are allowed to change.
This is pretty much fundamental to the whole idea of predicting
server-selected parameters. (If TLS were server-offer/client-select like
QUIC it would be a bit more obvious what's going on, but it's still the
same deal.)

For instance, here's an implementation strategy for socket-pooling clients
(i.e. browsers): you tell the HTTP layer to try again completely from the
top, meanwhile taking the socket and returning it to the socket pool as a
1-RTT-capable socket. The retry will grab that socket and use it. (Or maybe
some other request else will. That sounds weird, but it's no different from
what socket pools already do. A 0-RTT reject means the socket is reset.)


> I’m not sure how this makes protocol transitions awkward. I’d still expect
> clients to choose the application protocol that was previously negotiated,
> so preferring h3 wouldn’t
> cause all h2 0-RTT to go away.
>

They either go away or you pin on h2 when you should have gone to h3.
Suppose I prefer h3 > h2 and I talk to an h2 server. Per your proposal, if
I attempt to 0-RTT with that session, my choices are:

1. Keep my order h3 > h2. That means 0-RTT is conditioned on the server
picking h3 and I cannot 0-RTT.
2. Swap the order h2 > h3. That means 0-RTT works, but if the server then
gets upgraded to support h3, my order is false and the server continues to
pick h2. Since the server is going to continually issue me new tickets,
I'll never get the order switched back unless I go long periods without
talking to it.

With the session-remembering interpretation, once the server's preferences
change, you 0-RTT miss once. (Because your prediction is wrong... that's
unavoidable. The server's configuration changed.) But after that, all your
new tickets are at h3 and the steady state is 0-RTT-capable again.

David


>
>
> Kyle
>
>
>
> *From:* Eric Rescorla [mailto:e...@rtfm.com]
>
>
> *Sent:* Wednesday, October 12, 2016 4:03 PM
>
> *To:* David Benjamin 
>
> *Cc:* Kyle Nekritz ; tls@ietf.org
>
> *Subject:* Re: [TLS] ALPN with 0-RTT Data
>
>
>
>
>
>
>
>
>
>
> On Wed, Oct 12, 2016 at 1:01 PM, David Benjamin 
> wrote:
>
>
>
>
>
> My interpretation was:
>
>
>
>
>
>
>
> 1. Client and server remember the previous selected ALPN protocol in the
> session.
>
>
>
>
>
>
>
> 2. The 

Re: [TLS] ALPN with 0-RTT Data

[Kyle Nekritz]

Reordering the ALPN offer has a couple advantages:
* It explicitly defines the protocol that the 0-RTT data is using on that 
connection. Without this, both the client and the server must independently 
store the ALPN in use (of course the server can put it in the ticket). While 
this should work if implemented properly, there is nothing in the protocol that 
enforces they match before the server accepts the data. If the client ALPN 
offer does happen to change, it’s even possible for the selected ALPN to be one 
that the client didn’t even offer.
* If the client knows out-of-band (or learns over the application protocol) 
that the server supports multiple protocols, it will not be able to use its 
current connection to start up a 0-RTT connection over the new protocol.
* I think realistically for many clients the protocol used to send 0-RTT data 
will end up being the only protocol that can be used on that connection, even 
if 0-RTT is rejected. Rejected 0-RTT data can’t be resent 1-RTT if a different 
application protocol is used, and it’s difficult API-wise to tell the higher 
layer “Your http/2 early data failed, but you can send http/1.1 requests if you 
want”. Thus it makes sense for these clients to advertise the 0-RTT data’s 
application protocol as the most preferred.

I’m not sure how this makes protocol transitions awkward. I’d still expect 
clients to choose the application protocol that was previously negotiated, so 
preferring h3 wouldn’t cause all h2 0-RTT to go away.

Kyle

From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: Wednesday, October 12, 2016 4:03 PM
To: David Benjamin 
Cc: Kyle Nekritz ; tls@ietf.org
Subject: Re: [TLS] ALPN with 0-RTT Data



On Wed, Oct 12, 2016 at 1:01 PM, David Benjamin 
> wrote:
My interpretation was:

1. Client and server remember the previous selected ALPN protocol in the 
session.

2. The client may offer whatever ALPN protocols it likes. It does not need to 
match the previous offer list, though it presumably will unless you've got a 
persistent session cache or so.

3. The client assumes that session's ALPN protocol was selected for purposes of 
minting 0-RTT data.

4. The server must decline 0-RTT if it choses a different ALPN protocol. This 
can be implemented by just doing ALPN negotiation as normal and declining 0-RTT 
if the result does not match. (If client and server prefs have not changed, 
0-RTT will work. If prefs have changed, 0-RTT will miss but future sessions 
will start being 0-RTT-able. I think this is probably the sanest behavior.)

5. The client performs the usual checks on the selected ALPN protocol (must be 
one of the advertised ones). In addition, it enforces that, if 0-RTT was 
accepted, the protocol must match the session one.

This matches the behavior I intended in the spec (and the one NSS implements).

-Ekr


Pinning on the most preferred one causes awkward transitions when the most 
preferred ALPN protocol is not the same as the most commonly deployed one. If 
we ever define, say, h3, we want that one in front of h2 presumably, but we 
wouldn't want to lose 0-RTT against all the h2 servers out there.

I don't think we should be reorder preferences based on the sessions we are 
offering. That makes it much harder to reason about the behavior of preference 
lists.

David

On Wed, Oct 12, 2016 at 3:49 PM Kyle Nekritz 
> wrote:
Currently the draft specifies that the ALPN must be "the same" as in the 
connection that established the PSK used with 0-RTT, and that the server must 
check that the selected ALPN matches what was previously used. I find this 
unclear if

1) the client should select and offer one (and only one) application protocol

2) the client can offer multiple protocols, but use the most preferred one 
offered for 0-RTT data

3) the client must send the exact same ALPN extension as in the previous 
connection, but must use the ALPN previously selected by the server (even if it 
was not the client's first offer).



To clarify this we can instead

* allow the client to offer whatever ALPN extension it wants

* define that the 0-RTT data uses the client's most preferred application 
protocol offer (and the server must pick this ALPN if it accepts 0-RTT), 
similar to using the first PSK offer if multiple are offered

* recommend that the client uses the same application protocol that was used on 
the previous connection.



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



Kyle



___

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Application layer interactions and API guidance

[Eric Rescorla]

On Wed, Oct 12, 2016 at 12:55 PM, Kyle Rose  wrote:

> On Wed, Oct 12, 2016 at 2:03 PM, Ilari Liusvaara  > wrote:
>
>> > There's my confusion. I misinterpreted both the Zero-RTT diagram and the
>> > table of handshake contexts under "Authentication Messages",
>> specifically
>> > "ClientHello ... later of EncryptedExtensions/CertificateRequest". I'm
>> > guessing I should be looking at the 0-RTT row only? I.e., if 0-RTT is
>> > accepted, is the second Finished message from the client ("{Finished}")
>> the
>> > same message encrypted differently (using the handshake traffic secret)?
>>
>> No, there is no difference in ClientFinished in case of 0-RTT accept or
>> reject (other than the contents of the CH and EE hashed in).
>>
>
> Still confused. :-)
>
> In the message flow for 0-RTT, there are two Finished messages sent from
> client to server. One is sent right after CH, and is protected by the
> client_early_traffic_secret: (Finished). The other is sent after the server
> sends its Finished, and this is protected by the handshake_traffic_secret:
> {Finished}.
>
> In the table under "Authentication Messages", there are four rows, one for
> each Mode: 0-RTT, 1-RTT (Server), 1-RTT (Client), and Post-Handshake.
>
> Which handshake context is used for the (Finished) message and which is
> used for the {Finished} message?
>
> The thing that protects the 0-RTT data from substitution is the record
>> protection MACs that are made using key derived from the PSK secret. So
>> if the PSK secret is unknown, the key for 0-RTT can't be derived, and
>> as consequence, 0-RTT data can't be altered (there's end-of-data marker
>> too, preventing truncation).
>>
>
> Altered is one thing, and I agree that is prevented; I'm talking about
> substitution.
>
>
>> And basically, ServerFinished MAC covers everything up to that point,
>> and ClientFinished MAC covers the entiere handshake (0-RTT data not
>> included).
>>
>
> So client Finished doesn't protect 0-RTT data, but...
>
>
>> You can't swap out 0-RTT data (without PSK keys). One can only create
>> new connection attempts (that fail!) with the same 0-RTT data (and the
>> same ClientHello) before or after the real connection (if any, it
>> could be supressed, in which case you would get only failed handshakes
>> with 0-RTT data).
>>
>
> This is exactly what I'm trying to understand. What specifically prevents
> this swapping? I.e., what ties the 0-RTT data sent on a particular
> connection to the rest of that connection, such that replacing that 0-RTT
> data with 0-RTT data from a previous successful connection will cause a
> failure?
>

The 0-RTT traffic key incorporates the ClientHello.Random which is tied
into the full handshake.

-Ekr


>
> Kyle
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Application layer interactions and API guidance

[Kyle Rose]

On Wed, Oct 12, 2016 at 2:03 PM, Ilari Liusvaara 
wrote:

> > There's my confusion. I misinterpreted both the Zero-RTT diagram and the
> > table of handshake contexts under "Authentication Messages", specifically
> > "ClientHello ... later of EncryptedExtensions/CertificateRequest". I'm
> > guessing I should be looking at the 0-RTT row only? I.e., if 0-RTT is
> > accepted, is the second Finished message from the client ("{Finished}")
> the
> > same message encrypted differently (using the handshake traffic secret)?
>
> No, there is no difference in ClientFinished in case of 0-RTT accept or
> reject (other than the contents of the CH and EE hashed in).
>

Still confused. :-)

In the message flow for 0-RTT, there are two Finished messages sent from
client to server. One is sent right after CH, and is protected by the
client_early_traffic_secret: (Finished). The other is sent after the server
sends its Finished, and this is protected by the handshake_traffic_secret:
{Finished}.

In the table under "Authentication Messages", there are four rows, one for
each Mode: 0-RTT, 1-RTT (Server), 1-RTT (Client), and Post-Handshake.

Which handshake context is used for the (Finished) message and which is
used for the {Finished} message?

The thing that protects the 0-RTT data from substitution is the record
> protection MACs that are made using key derived from the PSK secret. So
> if the PSK secret is unknown, the key for 0-RTT can't be derived, and
> as consequence, 0-RTT data can't be altered (there's end-of-data marker
> too, preventing truncation).
>

Altered is one thing, and I agree that is prevented; I'm talking about
substitution.


> And basically, ServerFinished MAC covers everything up to that point,
> and ClientFinished MAC covers the entiere handshake (0-RTT data not
> included).
>

So client Finished doesn't protect 0-RTT data, but...


> You can't swap out 0-RTT data (without PSK keys). One can only create
> new connection attempts (that fail!) with the same 0-RTT data (and the
> same ClientHello) before or after the real connection (if any, it
> could be supressed, in which case you would get only failed handshakes
> with 0-RTT data).
>

This is exactly what I'm trying to understand. What specifically prevents
this swapping? I.e., what ties the 0-RTT data sent on a particular
connection to the rest of that connection, such that replacing that 0-RTT
data with 0-RTT data from a previous successful connection will cause a
failure?

Kyle
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] ALPN with 0-RTT Data

[Kyle Nekritz]

Currently the draft specifies that the ALPN must be "the same" as in the 
connection that established the PSK used with 0-RTT, and that the server must 
check that the selected ALPN matches what was previously used. I find this 
unclear if
1) the client should select and offer one (and only one) application protocol
2) the client can offer multiple protocols, but use the most preferred one 
offered for 0-RTT data
3) the client must send the exact same ALPN extension as in the previous 
connection, but must use the ALPN previously selected by the server (even if it 
was not the client's first offer).

To clarify this we can instead
* allow the client to offer whatever ALPN extension it wants
* define that the 0-RTT data uses the client's most preferred application 
protocol offer (and the server must pick this ALPN if it accepts 0-RTT), 
similar to using the first PSK offer if multiple are offered
* recommend that the client uses the same application protocol that was used on 
the previous connection.

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

Kyle

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Application layer interactions and API guidance

[Ilari Liusvaara]

On Wed, Oct 12, 2016 at 01:51:25PM -0400, Kyle Rose wrote:
> On Wed, Oct 12, 2016 at 1:02 PM, Ilari Liusvaara 
> wrote:
> 
> > > By this point in the connection, there is proof that early_data has not
> > > been replayed. The application doesn't necessarily know this when the
> > early
> > > data is first delivered, but it can find out later, which may be all that
> > > some applications want. Clearly not all, as you point out:
> >
> > This is actually only useful if the application can cancel out effects
> > of 0-RTT if handshake fails... Which tends to be fraught with peril to
> > implement.
> >
> 
> Absolutely, but it doesn't seem like it would be any more perilous than the
> danger of accepting 0-RTT data in the first place: at worst you process the
> same replayed data, and at best you process less replayed data. (Unless
> there's a perverse incentive problem created by providing a half-measure.)

If all 0-RTT data is idempotent (including after replay delay!), sure.

However, if it isn't idempotent, you could get issues...
 
> > The 0-RTT data is not part of ClientHello. It is sent in streaming
> > manner (with handshake blocking if it hans't been completely sent by
> > the time ServerFinished is received.
> >
> > ClientFinished does _not_ MAC 0-RTT data, even in case of successful
> > transport.
> >
> 
> There's my confusion. I misinterpreted both the Zero-RTT diagram and the
> table of handshake contexts under "Authentication Messages", specifically
> "ClientHello ... later of EncryptedExtensions/CertificateRequest". I'm
> guessing I should be looking at the 0-RTT row only? I.e., if 0-RTT is
> accepted, is the second Finished message from the client ("{Finished}") the
> same message encrypted differently (using the handshake traffic secret)?

No, there is no difference in ClientFinished in case of 0-RTT accept or
reject (other than the contents of the CH and EE hashed in).
 
> Is there a succinct explanation for the design choices around what is and
> is not included in the handshake context? Being spread out over a year and
> a half of mailing list messages makes it hard to track. :-) I'm concerned
> that an on-path adversary that can slice-and-dice connections along MAC
> context lines will be able to create mischief, so I'd like to be able to
> convince myself that this isn't the case.

The thing that protects the 0-RTT data from substitution is the record
protection MACs that are made using key derived from the PSK secret. So
if the PSK secret is unknown, the key for 0-RTT can't be derived, and
as consequence, 0-RTT data can't be altered (there's end-of-data marker
too, preventing truncation).

And basically, ServerFinished MAC covers everything up to that point,
and ClientFinished MAC covers the entiere handshake (0-RTT data not
included).

> And also, receiving 1-RTT data does not imply that the 0-RTT data
> > itself was not replayed (just that any replay it is of didn't
> > complete, assuming PSK keys are secret).
> >
> 
> Yeah, I get that now. It seems like a missed opportunity to detect mischief
> after the fact, and could make for some interesting vulnerabilities for
> stateful protocols. E.g., if your early data is "cd /tmp" and your 1-RTT
> data is "rm -rf *", but the adversary is able to swap out the early data
> for a replayed "cd ~". That one is probably too obvious of an example to
> happen in real life, but imagine some developer who maintains his or her
> own tlstunnel hearing about 0-RTT and implementing early data for arbitrary
> applications using that tunnel wrapper because "reduced latency!": if early
> data were later authenticated, it would limit the scope of vulnerability to
> only those things that could fit in that first flight. But because it can't
> catch every possible replay-based attack, maybe such a measure would
> provide only a false sense of security. Sigh. I have no desire to re-ignite
> arguments from a year ago.
 
You can't swap out 0-RTT data (without PSK keys). One can only create
new connection attempts (that fail!) with the same 0-RTT data (and the
same ClientHello) before or after the real connection (if any, it
could be supressed, in which case you would get only failed handshakes
with 0-RTT data).


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Application layer interactions and API guidance

[Kyle Rose]

On Wed, Oct 12, 2016 at 1:02 PM, Ilari Liusvaara 
wrote:

> > By this point in the connection, there is proof that early_data has not
> > been replayed. The application doesn't necessarily know this when the
> early
> > data is first delivered, but it can find out later, which may be all that
> > some applications want. Clearly not all, as you point out:
>
> This is actually only useful if the application can cancel out effects
> of 0-RTT if handshake fails... Which tends to be fraught with peril to
> implement.
>

Absolutely, but it doesn't seem like it would be any more perilous than the
danger of accepting 0-RTT data in the first place: at worst you process the
same replayed data, and at best you process less replayed data. (Unless
there's a perverse incentive problem created by providing a half-measure.)


> The 0-RTT data is not part of ClientHello. It is sent in streaming
> manner (with handshake blocking if it hans't been completely sent by
> the time ServerFinished is received.
>
> ClientFinished does _not_ MAC 0-RTT data, even in case of successful
> transport.
>

There's my confusion. I misinterpreted both the Zero-RTT diagram and the
table of handshake contexts under "Authentication Messages", specifically
"ClientHello ... later of EncryptedExtensions/CertificateRequest". I'm
guessing I should be looking at the 0-RTT row only? I.e., if 0-RTT is
accepted, is the second Finished message from the client ("{Finished}") the
same message encrypted differently (using the handshake traffic secret)?

Is there a succinct explanation for the design choices around what is and
is not included in the handshake context? Being spread out over a year and
a half of mailing list messages makes it hard to track. :-) I'm concerned
that an on-path adversary that can slice-and-dice connections along MAC
context lines will be able to create mischief, so I'd like to be able to
convince myself that this isn't the case.

And also, receiving 1-RTT data does not imply that the 0-RTT data
> itself was not replayed (just that any replay it is of didn't
> complete, assuming PSK keys are secret).
>

Yeah, I get that now. It seems like a missed opportunity to detect mischief
after the fact, and could make for some interesting vulnerabilities for
stateful protocols. E.g., if your early data is "cd /tmp" and your 1-RTT
data is "rm -rf *", but the adversary is able to swap out the early data
for a replayed "cd ~". That one is probably too obvious of an example to
happen in real life, but imagine some developer who maintains his or her
own tlstunnel hearing about 0-RTT and implementing early data for arbitrary
applications using that tunnel wrapper because "reduced latency!": if early
data were later authenticated, it would limit the scope of vulnerability to
only those things that could fit in that first flight. But because it can't
catch every possible replay-based attack, maybe such a measure would
provide only a false sense of security. Sigh. I have no desire to re-ignite
arguments from a year ago.

Kyle
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Application layer interactions and API guidance

[Ilari Liusvaara]

On Wed, Oct 12, 2016 at 11:54:59AM -0400, Kyle Rose wrote:
> On Wed, Oct 12, 2016 at 4:11 AM, Ilari Liusvaara 
> wrote:
> 
> Ok, I see where you're going with this. I'm not sure whether I would put
> the ALP filtering logic in the API or do something more like:
> 
> early_data = get_early_data()
> is_early_data_good = 
> start_server_handshake(reject_early_data = !is_early_data_good)
> 
> This allows the server to decide whether or not to reject early data on any
> basis, not just ALP. But maybe a shortcut is good for the common case.

You need ALP if multiple are supported, since some applications might
support 0-RTT and some not.

Also, TLS 1.3 0-RTT assumes that 0-RTT transport is all-or-none.
 
> The reason for waiting for application to ACK the 0-RTT error is that
> > the thing is MT-safe, so one has to prepare for races..
> >
> 
> I'm frankly skeptical of the utility of (most) thread safety at the socket
> level. (Safety against crashes, yes; safety against arbitrary interleaving
> of stream data, no.) IMO, semantic guarantees around multiplexing belong in
> a higher layer. Otherwise, the API must impose additional constraints
> (e.g., max write size) that apply across the board, even to applications
> that will never write from multiple threads, and must require the stack
> provide additional guarantees (e.g., all-or-none writes) that the developer
> has to know about.

That was actually mostly artifact of the programming language (easiest
to make things that aren't thread-locked fully thread-safe, even if
there is an intermediate step).
 
> Given how much TLS libraries try to look like Berkeley sockets to
> applications, you'll probably see fewer usage errors if that multiplexing
> logic is implemented at the application layer with an upward-facing
> interface that either looks nothing like sockets or that presents distinct
> logical sockets for distinct streams, intended for use by one thread at a
> time, multiplexed over the same connection.

Well, this lib looks nothing like Berkeley sockets. :-)
 
> > However, receiving any 1-RTT data after 0-RTT data does not imply that
> > the 0-RTT data was not replayed!
> >
> 
> I think I may have been imprecise. By "received" I mean "received by the
> application", i.e., "delivered by the stack". By the time the stack
> delivers one byte of 1-RTT data to the application, we know:
> 
> (1) Client {Finished} has been received by the server
> (2) which authenticates ClientHello
> (3) which incorporates early_data
> (4) Client {Finished} is protected by client_handshake_traffic_secret
> (5) which incorporates ServerHello
> (6) which incorporates the server random
> (7) which means that secret is fresh (i.e., not subject to replay)
>
> By this point in the connection, there is proof that early_data has not
> been replayed. The application doesn't necessarily know this when the early
> data is first delivered, but it can find out later, which may be all that
> some applications want. Clearly not all, as you point out:

This is actually only useful if the application can cancel out effects
of 0-RTT if handshake fails... Which tends to be fraught with peril to
implement.

Because the transport delay from client starting sending CH to server
first receiving first byte past some point is the same if the data
before the point is sent as 0-RTT or 1-RTT!

And the dominant component in transport delay tends to be round-trip
delay.

> > Do we want to support the case in which 0-RTT failure means the client can
> > > send entirely different data? If so, then the above isn't general enough,
> > > but the client API could offer an option to say "don't resend this data
> > if
> > > 0-RTT fails" with some flag set on this condition or (for event systems)
> > a
> > > callback registered to do something more interesting.
> >
> > There's the case where ALP mismatches (and unfortunately, due to how
> > ALPN and 0-RTT interact, mismatches can happen in cases other than
> > just that 0-RTT is fundamentially impossible).
> >
> > In that case, the data is obviously different. Then there are also
> > things like the planned 0-RTT tokbind, where the data sent on 0-RTT
> > failure is different from the original data.
> >
> 
> Agreed that this is a perfect example.
> 
> Since the early_data has to be received by the stack and be authenticated
> as a single chunk as part of the ClientHello, an API that returns it as a
> monolithic blob (like get_early_data, as above) solves the problem of
> associating requests/tokens to channel bindings. If some middleware wants
> to offer a stream interface to this buffer because that's the idiom for the
> particular language, that probably makes sense, but I suspect the low-level
> interface for a C implementation will be something more like "Here's a
> pointer and a length; go nuts."

The 0-RTT data is not part of ClientHello. It is sent in streaming
manner (with handshake blocking if it hans't been completely sent by
the 

Re: [TLS] Finished stuffing/PSK Binders

[Benjamin Kaduk]

On 10/12/2016 09:27 AM, Ilari Liusvaara wrote:
> On Wed, Oct 12, 2016 at 09:43:05PM +1100, Martin Thomson wrote:
>> On 12 October 2016 at 19:50, Ilari Liusvaara  
>> wrote:
>>
>> Maybe we should require text for every extension that can appear in
>> the HRR: what to do if the extension is in the HRR, and what to do if
>> it isn't.
> Or have every extension be "no change" if not present, and do the
> specified thing to CH if prsent and known, abort if present and
> unknown.

This is an instance of the "require text for every extension" case,
though I think either would work.

> That would waste a bit of space with extensions signaling support
> for some rewrites if the server doesn't use those but retries the
> handshake.
>

I'm having trouble parsing this.  The idea is that the client would
waste some space in the new CH because the server doesn't have a way to
indicate that the client only needs to send a subset of what it sent the
first time around?

-Ben
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Application layer interactions and API guidance

[Kyle Rose]

On Wed, Oct 12, 2016 at 4:11 AM, Ilari Liusvaara 
wrote:

> For when 0-RTT has become boring enough for me to implement, I would
> think the server-side interface I put in would be something like the
> following:
>
> - ServerSession::getReplayable0RttReader(alp_list) -> ZRttReader
> - ZRttReader::getAlpn() -> String
> - ZRttReader::dataAvailable() -> size
> - ZRttReader implements Read
>
> If there is no replayable 0RTT reader given when ClientHello is
> received, or if the ALP of the 0-RTT does not match any in alp_list,
> the 0-RTT is rejected. Otherwise it is accepted and the data stream is
> received via the ZRttReader. Then regular 1-RTT data will be returned by
> the usual Read interface of ServerSession.
>

Ok, I see where you're going with this. I'm not sure whether I would put
the ALP filtering logic in the API or do something more like:

early_data = get_early_data()
is_early_data_good = 
start_server_handshake(reject_early_data = !is_early_data_good)

This allows the server to decide whether or not to reject early data on any
basis, not just ALP. But maybe a shortcut is good for the common case.

> On the client side, one option is for the early data to be specified prior
> > to or alongside handshake initiation, with some indication by the stack
> of
> > whether it was written or not. (I suggest all-or-none.) This precludes
> > question on the part of the client as to which data might have been sent
> > 0-RTT and which must have been sent 1-RTT.
>
> The interface I envision has client write all the 0-RTT data and
> explicitly signal the end of data, with a callback if server rejects,
> so the application can abort the flight early (the stack just black-
> holes the data after error).
>

Agreed on that, with s/a callback/some client application signaling
appropriate to the language or development model involved/.

The reason for waiting for application to ACK the 0-RTT error is that
> the thing is MT-safe, so one has to prepare for races..
>

I'm frankly skeptical of the utility of (most) thread safety at the socket
level. (Safety against crashes, yes; safety against arbitrary interleaving
of stream data, no.) IMO, semantic guarantees around multiplexing belong in
a higher layer. Otherwise, the API must impose additional constraints
(e.g., max write size) that apply across the board, even to applications
that will never write from multiple threads, and must require the stack
provide additional guarantees (e.g., all-or-none writes) that the developer
has to know about.

Given how much TLS libraries try to look like Berkeley sockets to
applications, you'll probably see fewer usage errors if that multiplexing
logic is implemented at the application layer with an upward-facing
interface that either looks nothing like sockets or that presents distinct
logical sockets for distinct streams, intended for use by one thread at a
time, multiplexed over the same connection.

> Another nice thing is that at the moment you receive a single byte from

> > read() you know a priori that every byte of early data you processed was
> > authentic.
>
> Well, one always knows that for any received data, one who sent it
> possesses the PSK secret and it can't be tampered with without the
> PSK secret.
>

Absolutely. But is it an authentic part of *this* connection? That's what
the client {Finished} tells you, later.


> However, receiving any 1-RTT data after 0-RTT data does not imply that
> the 0-RTT data was not replayed!
>

I think I may have been imprecise. By "received" I mean "received by the
application", i.e., "delivered by the stack". By the time the stack
delivers one byte of 1-RTT data to the application, we know:

(1) Client {Finished} has been received by the server
(2) which authenticates ClientHello
(3) which incorporates early_data
(4) Client {Finished} is protected by client_handshake_traffic_secret
(5) which incorporates ServerHello
(6) which incorporates the server random
(7) which means that secret is fresh (i.e., not subject to replay)

By this point in the connection, there is proof that early_data has not
been replayed. The application doesn't necessarily know this when the early
data is first delivered, but it can find out later, which may be all that
some applications want. Clearly not all, as you point out:

> Do we want to support the case in which 0-RTT failure means the client can
> > send entirely different data? If so, then the above isn't general enough,
> > but the client API could offer an option to say "don't resend this data
> if
> > 0-RTT fails" with some flag set on this condition or (for event systems)
> a
> > callback registered to do something more interesting.
>
> There's the case where ALP mismatches (and unfortunately, due to how
> ALPN and 0-RTT interact, mismatches can happen in cases other than
> just that 0-RTT is fundamentially impossible).
>
> In that case, the data is obviously different. Then there are also
> things like the planned 0-RTT 

Re: [TLS] Finished stuffing/PSK Binders

[Ilari Liusvaara]

On Wed, Oct 12, 2016 at 10:13:57AM -0500, Benjamin Kaduk wrote:
> On 10/12/2016 09:27 AM, Ilari Liusvaara wrote:
> > On Wed, Oct 12, 2016 at 09:43:05PM +1100, Martin Thomson wrote:
> 
> > That would waste a bit of space with extensions signaling support
> > for some rewrites if the server doesn't use those but retries the
> > handshake.
> >
> 
> I'm having trouble parsing this.  The idea is that the client would
> waste some space in the new CH because the server doesn't have a way to
> indicate that the client only needs to send a subset of what it sent the
> first time around?

Well, depends on the extension...

Actually, not a major issue, given that there is usually a great amount
of bloat in the second CH (just to make it look like CH, instead of
just transporting what is needed).


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[David Benjamin]

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 
wrote:

I agre with Ilari. Currently, the way to reject a request is more than

just saying "no, thanks.".



On 10/12/2016 10:17 AM, Ilari Liusvaara wrote:

> On Wed, Oct 12, 2016 at 03:10:54AM -0400, Daniel Kahn Gillmor wrote:

>>

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

>

> 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

>



___

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Finished stuffing/PSK Binders

[Ilari Liusvaara]

On Wed, Oct 12, 2016 at 09:43:05PM +1100, Martin Thomson wrote:
> On 12 October 2016 at 19:50, Ilari Liusvaara  wrote:
> > I also noticed another edge case: What is to prevent server from
> > omitting key share group (emitting a cookie, so the restart is
> > not spurious), presumably causing the client to blank its key_share
> > and then proceed to accept DH versus client's previously sent share?
> 
> How about: If key_share isn't in the HRR, the client should replay
> it's old key_share verbatim.  Though I agree that the text should say
> as much.

Yeah, would work.

> Maybe we should require text for every extension that can appear in
> the HRR: what to do if the extension is in the HRR, and what to do if
> it isn't.

Or have every extension be "no change" if not present, and do the
specified thing to CH if prsent and known, abort if present and
unknown.

That would waste a bit of space with extensions signaling support
for some rewrites if the server doesn't use those but retries the
handshake.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Finished stuffing/PSK Binders

[Martin Thomson]

On 12 October 2016 at 19:50, Ilari Liusvaara  wrote:
> I also noticed another edge case: What is to prevent server from
> omitting key share group (emitting a cookie, so the restart is
> not spurious), presumably causing the client to blank its key_share
> and then proceed to accept DH versus client's previously sent share?

How about: If key_share isn't in the HRR, the client should replay
it's old key_share verbatim.  Though I agree that the text should say
as much.

Maybe we should require text for every extension that can appear in
the HRR: what to do if the extension is in the HRR, and what to do if
it isn't.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Finished stuffing/PSK Binders

[Ilari Liusvaara]

On Tue, Oct 11, 2016 at 07:48:05PM -0700, Eric Rescorla wrote:
> On Tue, Oct 11, 2016 at 5:16 PM, Martin Thomson 
> wrote:
> 
> > On 12 October 2016 at 00:51, Eric Rescorla  wrote:
> > > See:
> > > https://github.com/tlswg/tls13-spec/pull/678
> >
> > I'm convinced that this is the right change.  Reconstruction was
> > always going to be brittle.  I will note that I don't think that the
> > change gets the error codes right though.  I explained why on the PR.
> >
> Thanks, I'll look at this. I'll be merging this change (modulo your
> comments) Friday unless there is significant objection.

Well, if reject with in-list group is spurious or not depends on if
there is some hello-altering extension other than key share group
(it isn't if any other extension alters CH).


I also noticed another edge case: What is to prevent server from
omitting key share group (emitting a cookie, so the restart is
not spurious), presumably causing the client to blank its key_share
and then proceed to accept DH versus client's previously sent share?

(That kind of thing really plays hell if client has explicit list
of keypairs it considers active for connection).


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Wed, Oct 12, 2016 at 03:10:54AM -0400, Daniel Kahn Gillmor wrote:
> 
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Application layer interactions and API guidance

[Ilari Liusvaara]

On Tue, Oct 11, 2016 at 09:41:55PM -0400, Kyle Rose wrote:
> >
> > The 0-RTT API in NSS allows a server to detect this transition.  The
> > problem that I think David was referring to is that the specific
> > instant of the transition is lost when the multiple layers of stack
> > that sit on top of TLS get involved.
> >
> 
> To David's second paragraph, if we eventually authenticate the early data
> as strongly as 1-RTT data, then there is no problem with long requests.
> I.e., if the client starts a long PUT request that doesn't finish until
> after the handshake is done, then the connection could be broken by the
> server stack mid-request if it is able to figure out that the early data
> was replayed. It appears this will be the case because the handshake
> context for 0-RTT includes the ClientHello, which includes the early data,
> so the client {Finished} will cover it. (Not clear on the value of 0-RTT to
> long PUT requests, but you provide a more likely example below.)

I have actually seen one service where partially received PUT requests
had "side effects". Fortunately, not a replay problem in that case,
since application would reject replays anyway.

> Since the authentication status of early data may vary over the course of
> the connection from "unknown/possibly replayed" to either "replayed" or
> "authentic", maybe we should classify it by its status at the time we go to
> use it. Which suggests the following terrible API for the server:
> 
> read(max) will return either a string of fully-authenticated data up to max
> bytes, or EAGAIN if none is available (with possibly some side-band
> mechanism for indicating that data of unknown authenticity is available)
> 
> read_sketchy(max) will return possibly-sketchy data up to max bytes, or 0
> if there is no more such data (at which point the caller should switch to
> regular read), or EAGAIN if the entire ClientHello hasn't yet been received.

For when 0-RTT has become boring enough for me to implement, I would
think the server-side interface I put in would be something like the
following:

- ServerSession::getReplayable0RttReader(alp_list) -> ZRttReader
- ZRttReader::getAlpn() -> String
- ZRttReader::dataAvailable() -> size
- ZRttReader implements Read

If there is no replayable 0RTT reader given when ClientHello is
received, or if the ALP of the 0-RTT does not match any in alp_list,
the 0-RTT is rejected. Otherwise it is accepted and the data stream is
received via the ZRttReader. Then regular 1-RTT data will be returned by
the usual Read interface of ServerSession.

> If the server doesn't care about early data, or waits long enough for the
> handshake to complete, all data will have been elevated to authentic or the
> connection broken, depending on what happened with client {Finished}.

In the interface above, not caring about 0-RTT gets 0-RTT rejected. And
waiting just causes the connection to freeze up.
 
> On the client side, one option is for the early data to be specified prior
> to or alongside handshake initiation, with some indication by the stack of
> whether it was written or not. (I suggest all-or-none.) This precludes
> question on the part of the client as to which data might have been sent
> 0-RTT and which must have been sent 1-RTT.

The interface I envision has client write all the 0-RTT data and
explicitly signal the end of data, with a callback if server rejects,
so the application can abort the flight early (the stack just black-
holes the data after error).

And of course some critical thingy in which normally blocks 0-RTT
sending has name suggestive of replayability.

The reason for waiting for application to ACK the 0-RTT error is that
the thing is MT-safe, so one has to prepare for races..
 
> Another nice thing is that at the moment you receive a single byte from
> read() you know a priori that every byte of early data you processed was
> authentic.

Well, one always knows that for any received data, one who sent it
possesses the PSK secret and it can't be tampered with without the
PSK secret.

However, receiving any 1-RTT data after 0-RTT data does not imply that
the 0-RTT data was not replayed!
 
> Do we want to support the case in which 0-RTT failure means the client can
> send entirely different data? If so, then the above isn't general enough,
> but the client API could offer an option to say "don't resend this data if
> 0-RTT fails" with some flag set on this condition or (for event systems) a
> callback registered to do something more interesting.

There's the case where ALP mismatches (and unfortunately, due to how
ALPN and 0-RTT interact, mismatches can happen in cases other than
just that 0-RTT is fundamentially impossible).

In that case, the data is obviously different. Then there are also
things like the planned 0-RTT tokbind, where the data sent on 0-RTT
failure is different from the original data.

> The above API also doesn't support the case in which the server wants to
> treat 0-RTT data entirely 

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

[Daniel Kahn Gillmor]

On Tue 2016-10-11 13:26:02 -0400, Nick Sullivan wrote:
> 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.

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


signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls