[TLS] Benjamin Kaduk's practice ballot (Yes) on draft-ietf-tls-tls13-26: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

[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