Thanks for your review, Mirja. I will just add one comment inline from WG discussion and consensus.
On Wed, Mar 7, 2018 at 1:05 PM, Eric Rescorla <e...@rtfm.com> wrote: >> 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. > > Well: > https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html > says: > A document is obsolete when there is a newer version that replaces it. > > I believe that that's the relationship between TLS 1.3 and TLS 1.2. > > >> 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? > > Which extensions are you referring to. > > >> 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. > > It's true that we are deprecating the version mechanism, but that > does not mean that it is the only extension mechanism. > > > >> 2) Can you provide further explanation (potentially in the draft) why >> the Pre-Shared Key Exchange Modes are provided in an extra/separate >> extension? > > I'm sorry, I'm not following this. As opposed to what? > > >> 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? > > This is pretty explicitly outside the scope of TLS. It's just the job > of the underlying transport to simulate a reliable stream. I can add > some text that that's expected. > > >> 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"? > > The changes aren't in this document, but the WG feeling was that > both of those were creating bad incentives for people to publish > RFCs just to get a code point. The "Recommended" flag was intended > to address that need instead. The working group explicitly feels that a draft that is not published is adequate, falling into the specification required category where informal documentation is acceptable. Thanks, Kathleen > > >> 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. > > I don't think we have any IETF-wide standard here, but traditionally > we have adopted a pretty generous attitude towards acknowledgements > of this type. Given that electrons are basically free, I don't see a real > problem here. > > -Ekr > > > On Wed, Mar 7, 2018 at 8:38 AM, Mirja Kühlewind <i...@kuehlewind.net> wrote: >> >> 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 > -- Best regards, Kathleen _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
