[incoming AD ramping up on draft review; please consider this as a Yes ballot with COMMENT]
I was a contributor for this work, so it is unsurprising that I support its publication. I have some editorial fixes that I sent separately as a pull request (https://github.com/tlswg/tls13-spec/pull/1166), but will note a few things that I did not see mentioned already. The HelloRetryRequest flow does not allow future extensions to change the behavior/contents of the second ClientHello (without Updating this document); it's unclear that there is a real need for this limitation. Section 4.1.4 notes that: Upon receipt of a HelloRetryRequest, the client MUST perform the checks specified in Section 4.1.3 and then process the extensions, starting with determining the version using "supported_versions". But I think the "checks specified" are no longer very clear (presumably they were more clear in a previous revision). The main checks that I see in Section 4.1.3 are to check for specific Random values that are signalling sentinels, but by the time we are processing as a HelloRetryRequest we already know exactly what the "Random" value is. I'm not sure whether this text should be removed or there are some other checks that I am failing to see. We recommend that for external PSKs, clients SHOULD send an obfuscated_ticket_age of zero, which allows observers to trivially determine that a given PSK identity corresponds to an external PSK. Is it necessary to leave this side channel open, instead letting the server look up an external PSK identity and ignore the obfuscated_ticket_age in that case? This document explicitly prohibits the use of the OpenPGP certificate type (RFC 6091) with TLS 1.3 but implicitly allows its use for previous versions of TLS. Preumably that means someone(TM) needs to remember to do a status change for RFC 6091 along with or before RFC 5246. -Benjamin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls