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

[Eric Rescorla <[e-mail]>]

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

> On 07/11/2017 03:50 PM, Eric Rescorla wrote:
>
>
>
> On Tue, Jul 11, 2017 at 1:39 PM, Benjamin Kaduk <[e-mail]>
> 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
>> 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.
>

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


>
>
>
>
>
> 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://tlswg.github.io/draft-ietf-tls-iana-registry-
> updates/#orphaned-registries
> <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.
>>
>
> Suggestions welcome for where this would be better....
>
>
> I'll see if I have time to think about it some more.
>
> -Ben
>