On Wed, Jul 12, 2017 at 3:39 PM, Benjamin Kaduk <bka...@akamai.com> wrote:
> On 07/11/2017 03:50 PM, Eric Rescorla wrote: > > > > On Tue, Jul 11, 2017 at 1:39 PM, Benjamin Kaduk <bka...@akamai.com> > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
