On Wed, Mar 7, 2018 at 10:32 AM, Mirja Kuehlewind (IETF) < i...@kuehlewind.net> wrote:
> > > 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. > > RFC5077 and RFC6961 (maybe extension is not the wrong term for the first > one) > OK. I'm not really sure of a better way to handle this. > > > 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. > > Which others do you have? > Once you have negotiated a new version you can change the messages in any way you please, just as you always could have. > > 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? > > You could implicitly make assumptions depending on which extension are > present or you can add one field to the pre_shared_key extension to > indicate the mode. I’m always careful is something says „if this think is > present, that must also be present“ as it can be an source of error that > could have been avoided. Yes, we considered this design, and rejected it because we wanted a way to indicate which kinds of PSKs the client would be willing to accept. > > > 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. > > If that is the only requirement, it would still be good to spell that out. > > Sure, I can add something. > > > > > 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. > > Hm, I think I would actually prefer to see things documented in RFCs > instead of just having some spec somewhere. Not sure if an RFC on the ISE > stream is that much more effort than writing a spec somewhere else but then > at least the IESG would get to see it for a conflict review.. Well, I can see how you would feel that way, but it was the consensus of the WG that that was not the right approach. > > 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. > > I just would have expected to see all these names in an acknowledgment > section and not in an contributor section. > > RFC7322 again says: > > "4.11. Contributors Section > > > > This optional section acknowledges those who have made significant > contributions to the document.“ > I think this is within WG and Editor discretion. -Ekr > > Mirja > > > > > > > -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
