[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: [TLS] AD Review, WAS: Re: WGLC for draft-ietf-tls-iana-registry-updates-03.txt
From: Kathleen Moriarty <kathleen.moriarty.ietf () gmail ! com>
Date: 2018-01-31 17:43:08
Message-ID: CAHbuEH4XVMaqUn7uLsGvw=54L8PkSZLfx3qUA3Gzw3TX8rr8pw () mail ! gmail ! com
[Download RAW message or body]
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/
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.
Section 9 doesn't state either that the specification is publicly
available or a standards track document is required.
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."
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic