Subject: [TLS] Alexey Melnikov's No Objection on draft-ietf-tls-iana-registry-updates-04: (with COMMENT)

From: Alexey Melnikov <[email-masked]>
Date: Tue, 03 Apr 2018 09:56:16 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-iana-registry-updates-04: 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-iana-registry-updates/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support the idea behind this document. I have a few minor issues which I
would like to discuss before recommending its approval:

1) In several places:

"IESG action is REQUIRED for a Yes->No transition."

Firstly, this should be "IESG Approval", not "IESG action" (according to RFC
8126).

Secondly, are you saying that this is the ONLY way to transition from Yes to
No? Surely, Standards Action should also be allowed in case there is no rush?
Besides IESG is likely to prefer a document explaining the transition anyway.

2) In Section 15:

15.  TLS Certificate Types

   Experience has shown that the IETF Consensus registry policy for TLS
   Certificate Types is too strict.  Based on WG consensus, the decision
   was taken to change registration policy to Specification Required
   [RFC8126] while reserving a small part of the code space for
   experimental and private use.  Therefore, IANA [SHALL add/has added]
   a "Recommended" column to the registry.  X.509 and Raw Public Key are
   "Yes".  All others are "No".  In order to register an extension with
   the value "Yes", a Standards Track document [RFC8126] is REQUIRED.

The above sentence.

   Future Certificate Types MUST define the value of this column.  A
   Standards Track document [RFC8126] is REQUIRED to register an entry
   with the value "Yes".

And this is just repeating the above sentence in a different way.

   IESG action is REQUIRED for a Yes->No
   transition.

3) In Section 17:

   Despite the fact that the HashAlgorithm and SignatureAlgorithm
   registries are orphaned, it is still import to warn implementers of

import --> important

   pre-TLS1.3 implementations about the dangers of blinding implementing

blinding --> blindly

   cryptographic algorithms.

And later in the same section:

   WARNING:  Cryptographic algorithms and parameters will be broken or
      weakened over time.  Blindly implementing cipher suites listed

cipher suites --> hash functions/signatures?

      here is not advised.  Implementers and users need to check that
      the cryptographic algorithms listed continue to provide the
      expected level of security.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 3 Apr 2018 16:50:24 -0500

I will trim the purely editorial stuff, as the authors should be
able to handle that (and have already started, since the cipher
suite/hash+signature algorithm thing was already noted).

> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/

Sure, let's use the right term.

> Besides IESG is likely to prefer a document explaining the transition anyway.

Is IESG Approval mutaully exclusive with Standards-Action?
My reading of 8126's:

   New assignments may be approved by the IESG.  Although there is no
   requirement that the request be documented in an RFC, the IESG has
   the discretion to request documents or other supporting materials on
   a case-by-case basis.

is that a standards-track document could include an "IESG
Considerations" section that requests the IESG to effect the
transition.

That is to say, while I have no objection to your proposed (idea
for) text, I also am not sure that it is qualitatively different
from the current text.

-Benjamin

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 04 Apr 2018 18:48:26 +0100

Hi Benjamin,

> Considerations" section that requests the IESG to effect the

I suppose this can work, but typically "IESG Approval" is used for exception cases, where here it is always used. I think "IETF Consensus or IESG Approval" is more natural way of phrasing the intent.

> for) text, I also am not sure that it is qualitatively different

Best Regards,
Alexey

---

From: Sean Turner <[email-masked]>
Date: Wed, 4 Apr 2018 16:04:45 -0500

> On Apr 4, 2018, at 12:48, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Benjamin,
> 

Yep my bad - fixing this.

> I suppose this can work, but typically "IESG Approval" is used for exception cases, where here it is always used. I think "IETF Consensus or IESG Approval" is more natural way of phrasing the inten…

We wanted a bar that implied some adult supervision hence the IESG Approval :). I’d prefer to leave it at the lower because technically IETF Consensus also includes IESG Approval right?  I mean if somebody gets their draft through the process doesn’t it end with IESG approval?

>> for) text, I also am not sure that it is qualitatively different

Here’s a link to the PR:
https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/70

spt