Re: [TLS] AD Review, WAS: Re: WGLC for draft-ietf-tls-iana-registry-updates-03.txt

If anybody has any other views please let us know.

> On Jan 31, 2018, at 12:43, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
> 
> Thanks to the WG, chairs, and Stephen for your work on this draft and
> Ben  for the additional review comments.  The following nit and
> clarification points are in addition to Ben's suggested edits.  It
> looks long, but should result in no or very minor easy changes with
> text provided.
> 
> Section 9 -
> 
> Text nit:
>   Despite the following behavior being crazy, experience has shown that
>   some customers use the IANA registry as checklist against which to
>   measure an implementation's completeness and some implementers
>   blindly implement cipher suites.  Therefore, IANA [SHALL add/has
>   added] the following warning to the registry:
> Perhaps: s/crazy/unexpected and not advised/
> Or s/crazy/unexpected and NOT RECOMMENDED/

mt had the same reaction so put the following in the PR that addresses WGLC comments:

r/crazy/misguided

I wanted to avoid the 2119-language.

> Sections 8,10, 11, 13, and 15 all update the registration policy on an
> existing registry.  The rules for registration vary slightly and I'd
> like to confirm that this is what was intended:
> 
> Sections 8, 10, 11, 13
> Designated expert ensures the specification is publicly available.
> 
> Section 10, 13, 15
> Explicitly requires a standards track document.

s8 (TLS ExtensionType Values) we changed to spec required.

s10 (TLS Supported Groups) was changed to spec required by draft-ietf-tls-rfc4492bis.   draft-ietf-tls-rfc4492bis was really about moving EC cipher suites from informational track to stds track; that draft is sitting the RFC editor’s queue.  The blurb in this draft about stds track is just about how the initial values for the Recommended column got populated.

s11 (TLS ClientCertificateType Identifiers) we changed to spec required.

s13 (TLS Exporter Label Registry) we didn’t change the rules we just added a Recommended column.  The blurb in this draft about stds track is just about how the initial values for the Recommended column got populated.

s15 (TLS Certificate Types) we changed to spec required.

> Section 9 doesn't state either that the specification is publicly
> available or a standards track document is required.

s9 (TLS Cipher Suite Registry) was changed to spec required (and some for private use) and there’s a note at the end that section that adds:

   The designated expert [RFC8126] only ensures that
   the specification is publicly available.

> Next, I'd like to understand the WG's view on what "specification"
> suffices for registries that do not require a standards track
> document.  When you dig through 8126, we've had people on the IESG
> debate what is meant and people on the IESG change over time as do
> interpretations. Does this mean something as simple as an email to an
> IETF list that can be referenced and won't be deleted, a draft that is
> posted and never published, a standard in another standards body,
> etc.?  If you only intend it to mean the last 2, I think you're okay
> not elaborating further in the draft, but if an email is enough, I
> think you may need some text.  I'd use the phrase from 8126, section
> 4.6, "informal documentation, e.g. public IETF mailing list".
> 
> Relevant text from 8126:
> 
>   "The intention behind "permanent and readily available" is that a
>   document can reasonably be expected to be findable and retrievable
>   long after IANA assignment of the requested value.  Publication of an
>   RFC is an ideal means of achieving this requirement, but
>   Specification Required is intended to also cover the case of a
>   document published outside of the RFC path, including informal
>   documentation.”

The discussions I remember were about the latter two/three: a draft that is posted and never published or a standard in another standards body/industry consortium/university site/etc.

spt

> Best regards,
> Kathleen
> 
> On Wed, Jan 31, 2018 at 11:34 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
>> On the "better late than never" front, I've got some nits:
>> 
>> OLD:
>> 
>>       [...] A Standards Track document
>>      [RFC8126] is REQUIRED to register an extension with the value
>>      "Yes".
>> 
>> NEW:
>> 
>>      In order to register an extension with the value "Yes", a Standards
>> Track
>>      document [RFC8126] is REQUIRED.
>> 
>> Since not all standards-track documents must register such extensions/cipher
>> suites/etc.  (There are multiple occurrences of this text.)
>> 
>> 
>> Is the "Exporter Value" table in the document supposed to have a
>> "Recommended" column?
>> 
>> Let's also double-check that the "WARNING: Cryptographic algorithms[...]"
>> text does not always say "cipher suites listed here", even when talking
>> about (e.g.) HashAlgorithm and SignatureAlgorithm.
>> 
>> (Also, we can spell "SignatureAlgorithm" as not-"SignarureAlgorithm".)
>> 
>> Maybe capitalize "TBD" in "tbd but maybe tls-reg-review@ietf.org"?
>> 
>> 
>> OLD:
>> 
>>   Recommended algorithms regarded as secure for general use at the time
>>   of registration, however, cryptographic algorithms and parameters
>>   will be broken or weakened over time.
>> 
>> NEW:
>> 
>>   Recommended algorithms are regarded as secure for general use at the time
>>   of registration, however, cryptographic algorithms and parameters
>>   will be broken or weakened over time.
>> 
>> NOTES:
>> 
>> Add "are" to improve grammar.
>> 
>> 
>> -Ben
>> 
>> 
>> On 01/31/2018 08:35 AM, Sean Turner wrote:
>> 
>> I have one PR that address both the WGLC comments (from mt and ekr):
>> https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/57
>> 
>> If you’ve got other suggested changes let me know and I can submit another
>> PR and do the final merges before you initiate the IETFLC.
>> 
>> Cheers,
>> 
>> spt
>> 
>> On Jan 30, 2018, at 16:54, Kathleen Moriarty
>> <kathleen.moriarty.ietf@gmail.com> wrote:
>> 
>> Great, thank you very much, Stephen!  I'll get it rolling towards
>> publication with last call starting soon.  I'll do my review in the
>> next couple of days.
>> 
>> Best regards,
>> Kathleen
>> 
>> On Tue, Jan 30, 2018 at 4:42 PM, Stephen Farrell
>> <stephen.farrell@cs.tcd.ie> wrote:
>> 
>> Hi Kathleen,
>> 
>> The WGLC for this has expired.
>> 
>> There was only one explicit comment [1] saying to ship it.
>> The WG have chatted about this a bunch of times though so
>> FWIW I think it'd be fair to conclude there's pretty good
>> consensus for this.
>> 
>> Cheers,
>> S.
>> 
>> [1] https://www.ietf.org/mail-archive/web/tls/current/msg25279.html
>> 
>> On 15/01/18 21:34, Stephen Farrell wrote:
>> 
>> Hiya,
>> 
>> Kathleen's a bit busy at the moment so asked that, as shepherd,
>> I kick off the WGLC for this one (as the two chairs are authors).
>> The idea is that I'll summarise the WGLC thread to her and she
>> can then decide if this is ready to move forward.
>> 
>> So this starts a 2-week WGLC, ending on January 29th.
>> 
>> Cheers,
>> Shepherdy Stephen.
>> 
>> On 03/01/18 13:57, internet-drafts@ietf.org wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Transport Layer Security WG of the IETF.
>> 
>>       Title           : IANA Registry Updates for TLS and DTLS
>>       Authors         : Joe Salowey
>>                         Sean Turner
>>    Filename        : draft-ietf-tls-iana-registry-updates-03.txt
>>    Pages           : 16
>>    Date            : 2018-01-03
>> 
>> Abstract:
>>  This document describes a number of changes to (D)TLS IANA registries
>>  that range from adding notes to the registry all the way to changing
>>  the registration policy.  These changes were mostly motivated by WG
>>  review of the (D)TLS-related registries undertaken as part of the
>>  TLS1.3 development process.  This document updates many (D)TLS RFCs
>>  (see updates header).
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-03
>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates-03
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-iana-registry-updates-03
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>> 
>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>> 
>> --
>> PGP key change time for me.
>> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
>> NewWithOld sigs in keyservers.
>> Sorry if that mucks something up;-)
>> 
>> 
>> --
>> 
>> Best regards,
>> Kathleen
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>> 
>> 
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen