[TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-tls-tls13-26: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) I'm a bit uncertain if obsoleting is the right approach as many other
protocols usually do not obsolete older versions. However, I understand that
this has been the approach TLS has previously taken and is supported by the way
the document is written. Still, I find it especially confusing that also two
TLS1.2 extensions are deprecated which are not needed with TLS1.3 anymore but
still probably valid to be used with TLS1.2, right? I would recommend for this
version to at least already note in the abstract or very early in the intro
that it changes the versioning mechanism itself, and thereby basically declares
the TLS handshake as an invariant for all future versions and extensibility is
only provided using extensions anymore.

2) Can you provide further explanation (potentially in the draft) why the
Pre-Shared Key Exchange Modes are provided in an extra/separate extension?

3) I know previous versions of TLS didn't say that much either, but I find it a
bit wired that there are NO requirements for the underlaying transport in this
document. Previous version this at least said in the intro that a reliable
transport (like TCP) is assumed, but even this minimal information seems to
have gotten lost in this document. However, I would usually also expect to seen
some minimal text about connection handling, e.g. is it okay to transparently
try to reestablish the connection by the underlying transport protocol if it
broke for some reason? Or it is okay to use the same TCP connection to first
send other data and then start the TLS handshake?

4) Regarding the registration policies: I assume the intend of changing them is
to make it easier to specify and use new extensions/mechanism. However, I am
wondering why the policies have been changed to "Specification Required" and
not "IETF consensus" or RFC Required"?

5) I find it a bit strange that basically the whole working group is listed as
contributors. My understanding was that Contributors are people that have
contributed a "significant" amount of text, while everybody else who e.g.
brought ideas in during mailing list discussion would be acknowledged only.