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

[Eric Rescorla <[e-mail]>]

> 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.


> 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 <[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.
>
>
>