Subject: [TLS] 2nd WGLC: draft-ietf-tls-tls13

From: Sean Turner <[email-masked]>
Date: Mon, 3 Jul 2017 23:53:53 -0400

All,

This is the 2nd working group last call (WGLC) announcement for draft-ietf-tls-tls13 to run through July 18th.  This time the WGLC is for version -21 (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/).  Note that this WGLC ends before the Wednesday TLS WG session @ IETF 99.

Also note that this WGLC is a targeted WGLC that only address changes introduced since the 1st WGLC on version -18, i.e., changes introduced in versions -19 through -21.  Note that the editor has kindly included a change log in s1.2 and the datatracker can also produce diffs (for some reason it’s not working for me right now).  In general, we are considering all other material to have WG consensus, so only critical issues should be raised about that material at this time.

Cheers,

spt

---

From: Martin Thomson <[email-masked]>
Date: Tue, 4 Jul 2017 15:21:50 +1000

I think that everything IETF is a little bit slow today, which I'm
sure has nothing at all to do with the draft submission deadline.

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-tls-tls13-18.txt&url2=https://tools.ietf.org/id/draft-ietf-tls-tls13-21.txt

I have reviewed the diff and found a few extremely minor nits that
I'll send in a PR.

On 4 July 2017 at 13:53, Sean Turner <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 11 Jul 2017 15:39:23 -0500

> Also note that this WGLC is a targeted WGLC that only address changes introduced since the 1st WGLC on version -18, i.e., changes introduced in versions -19 through -21.  Note that the editor has k…

Duly limiting myself to reviewing just the changes from -18 to -21, I do
still have some comments.

The main issue is one that I have raised previously but does not seem to
have been resolved by the group, namely, that I think we should have a
MUST-level requirement for some stronger anti-replay scheme than the
freshness checks of section 8.3.  I do not think that we need to mandate
specifically the single-use tickets of section 8.1 or the ClientHello
recording scheme of section 8.2, and can leave freedom for
implementations to choose alternate schemes, but do think that we will
be on the wrong side of the "we're building a security protocol"/"we're
building an easy-to-implement protocol" divide with the present
SHOULD-level indication.

Another question I also relates to 0-RTT, specifically with the
freshness checks and the case where the computed expected_arrival_time
is in outside "the window" by virtue of being in the future. (See the
Note: at the end of section 8.2.) (The case where the
expected_arrival_time is in the past can clearly be treated as "this is
a stale request" and the current text about aborting with
"illegal_parameter" or rejecting 0-RTT but accepting the PSK is
acceptable, even if it doesn't give guidance as to what might cause
someone to pick one behavior or the other.)  I am wondering whether we
should consider this to be a potential attack and abort the connection. 
I concede that there are likely to be cases where this
situation occurs incidentally, for clients with extremely fast-running
clocks, and potential timezone/suspend-resume weirdness.  But there is
also the potential for a client that deliberately lies about its ticket
age and intends to replay the wire messages when the age becomes in
window, or an attacker that records the messages and knows that the
client's clock is too fast, or other cases.  (A client that deliberately
does this could of course just send the same application data later as
well.)  If the time is only a few seconds out of the window, then
delaying a response until it is in the window and only then entering it
into the single-use cache might be reasonable, but if the time is very
far in the future, do we really want to try to succeed in that case?  Or
perhaps we should just make the time window for 0-RTT acceptance
half-infinite and not bother rejecting things that claim to be in the
future; that probably has some robustness arguments in its favor.

It looks like we no longer do anything to obsolete/reserve/similar the
HashAlgorithm and SignatureAlgorithm registries; was that just an
editorial mixup or an intended change?

We removed the API guidance for separate APIs for read/writing early
data versus regular data, which I believe had consensus.  But I thought
we were going to say something carefully worded about having an API to
determine whether the handshake has completed (or client Finished has
been validated, or ...), and it looks like this is buried at the end of
E.5(.0), with the string "API" not appearing.  It might be useful to
make this a little more prominent/discoverable, whether by subsection
heading or otherwise.

I also found some issues that I believe to be purely editorial, for
which I will submit a pull request.

I will probably try to make another full review pass over the entire
document (mostly looking for editorial things), but I have until the end
of IETF LC for that, right? ;)

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Jul 2017 13:50:48 -0700

On Tue, Jul 11, 2017 at 1:39 PM, Benjamin Kaduk <[email-masked]> wrote:
>
>
> Another question I also relates to 0-RTT, specifically with the freshness
> checks and the case where the computed expected_arrival_time is in outside
> "the window" by virtue of being in the future. (See the Note: at the end of
> section 8.2.) (The case where the expected_arrival_time is in the past can
> clearly be treated as "this is a stale request" and the current text about
> aborting with "illegal_parameter" or rejecting 0-RTT but accepting the PSK
> is acceptable, even if it doesn't give guidance as to what might cause
> should consider this to be a potential attack and abort the connection.  I
> concede that there are likely to be cases where this
> clocks, and potential timezone/suspend-resume weirdness.  But there is also
> the potential for a client that deliberately lies about its ticket age and
> intends to replay the wire messages when the age becomes in window, or an
> attacker that records the messages and knows that the client's clock is too
> fast, or other cases.  (A client that deliberately does this could of
> course just send the same application data later as well.)  If the time is
> only a few seconds out of the window, then delaying a response until it is
> in the window and only then entering it into the single-use cache might be
> reasonable, but if the time is very far in the future, do we really want to
> try to succeed in that case?
>

If the time is very far in the future, the text is supposed to tell you to
fall back
to 1-RTT...

> HashAlgorithm and SignatureAlgorithm registries; was that just an editorial
> mixup or an intended change?
>

https://tlswg.github.io/draft-ietf-tls-iana-registry-updates/#orphaned-registries

We removed the API guidance for separate APIs for read/writing early data
> versus regular data, which I believe had consensus.  But I thought we were
> going to say something carefully worded about having an API to determine
> whether the handshake has completed (or client Finished has been validated,
> or ...), and it looks like this is buried at the end of E.5(.0), with the
> string "API" not appearing.  It might be useful to make this a little more
> prominent/discoverable, whether by subsection heading or otherwise.
>

Suggestions welcome for where this would be better....

-Ekr

>
> I also found some issues that I believe to be purely editorial, for which
> I will submit a pull request.
>
> document (mostly looking for editorial things), but I have until the end of
> IETF LC for that, right? ;)
>
> -Ben
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 12 Jul 2017 17:39:11 -0500

On 07/11/2017 03:50 PM, Eric Rescorla wrote:
>
>
> On Tue, Jul 11, 2017 at 1:39 PM, Benjamin Kaduk <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     freshness checks and the case where the computed
>     expected_arrival_time is in outside "the window" by virtue of
>     being in the future. (See the Note: at the end of section 8.2.)
>     (The case where the expected_arrival_time is in the past can
>     clearly be treated as "this is a stale request" and the current
>     text about aborting with "illegal_parameter" or rejecting 0-RTT
>     but accepting the PSK is acceptable, even if it doesn't give
>     guidance as to what might cause someone to pick one behavior or
>     the other.)  I am wondering whether we should consider this to be
>     a potential attack and abort the connection.  I concede that there
>     are likely to be cases where this
>     situation occurs incidentally, for clients with extremely
>     fast-running clocks, and potential timezone/suspend-resume
>     weirdness.  But there is also the potential for a client that
>     deliberately lies about its ticket age and intends to replay the
>     wire messages when the age becomes in window, or an attacker that
>     records the messages and knows that the client's clock is too
>     fast, or other cases.  (A client that deliberately does this could
>     of course just send the same application data later as well.)  If
>     the time is only a few seconds out of the window, then delaying a
>     response until it is in the window and only then entering it into
>     the single-use cache might be reasonable, but if the time is very
>     far in the future, do we really want to try to succeed in that case?
>
>
> If the time is very far in the future, the text is supposed to tell
> you to fall back
> to 1-RTT...
>

I agree that that is what the text currently says.  I'm questioning
whether that's actually the behavior we want.

That is, in this case, the CH+0RTT data can be replayed by an observer
once enough time has elapsed that the expected_arrival_time is within
the window, similar to one of the reordering attacks mentioned
elsewhere.  We could add the CH to the strike register in this case,
which would bloat its storage somewhat and have entries that take longer
than the window to expire out.

I don't have a good sense for how often we expect postdated CHs to occur
and whether the ensuing breakage would be manageable, but I'm not sure
that we've thought very hard as a group about this question.

>
>
>     It looks like we no longer do anything to obsolete/reserve/similar
>     the HashAlgorithm and SignatureAlgorithm registries; was that just
>     an editorial mixup or an intended change?
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tlswg.github.io_draft-2Dietf-2Dtls-2Diana-2Dregistry-2Dupdates_-23orphaned-2Dregistries&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=BMArYHEvmklJ5o8KreHqXeVRBDLx5CLzLwErLvjyUWk&s=3RGXDDdDzmF81eYcffxZOyJWazAfg8Uk45evFm9yMo0&e=>
>

Oh right, I forgot about that -- thanks.

>
>     We removed the API guidance for separate APIs for read/writing
>     early data versus regular data, which I believe had consensus. 
>     But I thought we were going to say something carefully worded
>     about having an API to determine whether the handshake has
>     completed (or client Finished has been validated, or ...), and it
>     looks like this is buried at the end of E.5(.0), with the string
>     "API" not appearing.  It might be useful to make this a little
>     more prominent/discoverable, whether by subsection heading or
>     otherwise.
>
>

I'll see if I have time to think about it some more.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Jul 2017 06:07:52 -0700

On Wed, Jul 12, 2017 at 3:39 PM, Benjamin Kaduk <[email-masked]> wrote:

> once enough time has elapsed that the expected_arrival_time is within the
> window, similar to one of the reordering attacks mentioned elsewhere.  We
> could add the CH to the strike register in this case, which would bloat its
> storage somewhat and have entries that take longer than the window to
> expire out.
>
> and whether the ensuing breakage would be manageable, but I'm not sure that
> we've thought very hard as a group about this question.
>

I think post-dated are going to happen pretty often based on what I
understand from
Kyle and others. I wouldn't be comfortable with hard fail, especially given
that this
just seems like the dual of the other case. Adding the CH to the list seems
like
a problem because it might stay forever.

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 18 Jul 2017 13:10:54 -0500

On 07/18/2017 08:07 AM, Eric Rescorla wrote:
>
>
> On Wed, Jul 12, 2017 at 3:39 PM, Benjamin Kaduk <[email-masked]
>     That is, in this case, the CH+0RTT data can be replayed by an
>     observer once enough time has elapsed that the
>     expected_arrival_time is within the window, similar to one of the
>     reordering attacks mentioned elsewhere.  We could add the CH to
>     the strike register in this case, which would bloat its storage
>     somewhat and have entries that take longer than the window to
>     expire out.
>
>     I don't have a good sense for how often we expect postdated CHs to
>     occur and whether the ensuing breakage would be manageable, but
>     I'm not sure that we've thought very hard as a group about this
>     question.
>
>
> Kyle and others. I wouldn't be comfortable with hard fail, especially
> given that this
> just seems like the dual of the other case. Adding the CH to the list
> seems like

The "stay forever" part is awkward, yes.  It would be great if Kyle/etc.
could say a bit about why post-dated seems likely on the list, but I
guess for the purposes of WGLC we can consider this comment resolved.

-Ben

---

From: Kyle Nekritz <[email-masked]>
Date: Tue, 18 Jul 2017 19:05:25 +0000

Timestamps outside the expected window can happen due to variances in RTT, client clock skew, etc. (we see around .1% of clients outside of a 30s window for example). Not likely to happen on a given connection, but it certainly happens enough that you don’t want to abort the connection (rather than allowing 1-RTT) without reason. I’m not sure I understand the desire to abort these connections. What value does it provide? The timestamp mechanism does not provide protection against a malicious client that has possession of the PSK key.

If the server is 100% sure that a CH is replayed it is more reasonable to abort the connection, but I think it should be explicit to the client that that is the reason for the error (ie using a new alert type rather than illegal_parameter) so the client can know to retry without 0-RTT. I’m also slightly concerned that it allows a passive attacker to cause connection failures if it can front-run a copy of the CH to the server, and I still don’t think it is providing much value.

From: TLS [mailto:[email-masked]] On Behalf Of Benjamin Kaduk
Sent: Tuesday, July 18, 2017 2:11 PM
To: Eric Rescorla <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13

On Wed, Jul 12, 2017 at 3:39 PM, Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:

That is, in this case, the CH+0RTT data can be replayed by an observer once enough time has elapsed that the expected_arrival_time is within the window, similar to one of the reordering attacks mentioned elsewhere.  We could add the CH to the strike register in this case, which would bloat its storage somewhat and have entries that take longer than the window to expire out.

I don't have a good sense for how often we expect postdated CHs to occur and whether the ensuing breakage would be manageable, but I'm not sure that we've thought very hard as a group about this question.

I think post-dated are going to happen pretty often based on what I understand from
Kyle and others. I wouldn't be comfortable with hard fail, especially given that this
just seems like the dual of the other case. Adding the CH to the list seems like
a problem because it might stay forever.

The "stay forever" part is awkward, yes.  It would be great if Kyle/etc. could say a bit about why post-dated seems likely on the list, but I guess for the purposes of WGLC we can consider this comment resolved.

-Ben