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

[Eric Rescorla <[e-mail]>]

On Wed, Mar 7, 2018 at 10:32 AM, Mirja Kuehlewind (IETF) <
[e-mail]> 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 <[e-mail]>
> 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.
> >
> >
> >
>
>