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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
