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

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 <ekr@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 <ietf@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