On 07/03/2017 10:53 PM, Sean Turner wrote: > 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. >
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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
