Subject: [TLS] TLS Flags and IANA registration policy

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 23 Oct 2021 08:46:56 +0000

Hi all,

https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags gives guidance on registering values in the TLS Flags namespace.

One of the field is the "Recommended" field and it is described as follows:

"
o  Recommended, which is a Y/N value determined in the document defining the optional feature.
"

What does this mean? When do I use a "Y" and when a "N"? What is the implication of declaring it as a "N"?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 23 Oct 2021 12:15:59 +0300

On Sat, Oct 23, 2021 at 08:46:56AM +0000, Hannes Tschofenig wrote:
> Hi all,
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags gives
> guidance on registering values in the TLS Flags namespace.
> 

I would presume it is the same as for extensions, which is
described in registry note as:

"If an item is not marked as 'Recommended', it does not necessarily mean
that it is flawed; rather, it indicates that the item either has not
been through the IETF consensus process, has limited applicability, or
is intended only for specific use cases."

-Ilari

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 25 Oct 2021 17:13:07 +0000

Hi Ilari,

> "If an item is not marked as 'Recommended', it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases."

I think the flags draft should state that (if that's how it should be interpreted).

FWIW I looked through the current list of extensions and their Y/N assignment for "recommended". The assignment appears random. This is not surprising that extensions are, by their nature, related to specific use cases and therefore have a certain applicability only.

Ciao
Hannes

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 25 Oct 2021 21:18:00 +0300

On Mon, Oct 25, 2021 at 05:13:07PM +0000, Hannes Tschofenig wrote:
> Hi Ilari,
> 
> > "If an item is not marked as 'Recommended', it does not necessarily
> > mean that it is flawed; rather, it indicates that the item either
> > has not been through the IETF consensus process, has limited
> > applicability, or is intended only for specific use cases."
> 
> FWIW I looked through the current list of extensions and their Y/N
> assignment for "recommended". The assignment appears random. This is
> not surprising that extensions are, by their nature, related to
> specific use cases and therefore have a certain applicability only.

Yeah, the assignments are pretty strange, here are some recommended
ones I think are odd:

- trusted_ca_keys: Wasn't that supposed to be deprecated?
- client_certificate_url: No replacment in TLS 1.3, security issues.
- user_mapping: No replacement in TLS 1.3, who uses this?
- ec_point_formats: No replacement in TLS 1.3, who uses this?
- heartbeat: The most infamous extension of them all.
- token_binding: No replacement in TLS 1.3.
- status_request_v2: Who uses this (at least TLS 1.3 has a replacement)?
- session_ticket: Nasty security issues (destroys forward secrecy of
  any connection it is used on).
- transparency_info: Similar to signed_certificate_timestamp, which is
  not recommended.

On the reverse side, not recommended extensions, there does not seem
to be any really strange ones (I presume some are due to procedural
matters, and will be changed to recommended later).

I dinged extensions for not working and not having replacment in TLS 1.3,
as one would think that all the common stuff would have replacements.

Then on stuff other than extensions, there are some other odd ones:

- ciphers TLS_DHE_RSA_WITH_*: Negotiation is flawed.
- ciphers TLS_DHE_PSK_WITH_*: Who uses this?
- exporter label "client finished": Actually reserved.
- exporter label "server finished": Actually reserved.
- exporter label "master secret": Actually reserved.
- exporter label "key expansion": Actually reserved.
- exporter labels: Why is there recommended column at all?

-Ilari

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 26 Oct 2021 13:18:35 +0000

The Recommended column is "was this done via IETF consensus."  Some of the values you think are odd are from pre-1.3, done by consensus, even if the protocol is now outdated by 1.3

If there are some 1.0 and 1.1 extensions that are not defined in 1.2, then that deprecation draft should suggest IANA changes.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Oct 2021 14:44:09 +0000

Rich, this makes more sense. Maybe the column should say "IETF Consensus"  (Y/N) instead of Recommended.

In any case, the draft should say what recommended means for the flags values.

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of Salz, Rich
Sent: Tuesday, October 26, 2021 3:19 PM
To: Ilari Liusvaara <[email-masked]>; IETF TLS <[email-masked]>
Subject: Re: [TLS] TLS Flags and IANA registration policy

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Ira McDonald <[email-masked]>
Date: Tue, 26 Oct 2021 11:26:16 -0400

Hi,

I agree that the "Recommended" column in the IANA registry (which is
frequently misunderstood)
should just be renamed to "IETF Consensus".  Obvious and self-explanatory.

Cheers,
- Ira

On Tue, Oct 26, 2021 at 10:45 AM Hannes Tschofenig <
[email-masked]> wrote:

> The Recommended column is "was this done via IETF consensus."  Some of the
> values you think are odd are from pre-1.3, done by consensus, even if the
> protocol is now outdated by 1.3
>
> If there are some 1.0 and 1.1 extensions that are not defined in 1.2, then
> that deprecation draft should suggest IANA changes.
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 29 Oct 2021 14:37:20 +0000

*   I agree that the "Recommended" column in the IANA registry (which is frequently misunderstood)

  *   should just be renamed to "IETF Consensus".  Obvious and self-explanatory.

The way to do that is to get an RFC out that makes that change.  It could be stand-alone, or part of another (like the 8446bis draft, https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/)  The first step might be to ask for five minutes at the next meeting and bring it up.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Oct 2021 11:46:38 -0700

I am actually not in favor of changing it to IETF Consensus. I think these
have different meanings.

I prefer: Recommended/Not Recommended/Discouraged

On Fri, Oct 29, 2021 at 7:37 AM Salz, Rich <rsalz=
[email-masked]> wrote:

>
>    - I agree that the "Recommended" column in the IANA registry (which is
>    - should just be renamed to "IETF Consensus".  Obvious and
>    self-explanatory.
>
>
>
> The way to do that is to get an RFC out that makes that change.  It could
> be stand-alone, or part of another (like the 8446bis draft,
> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/)  The first
> step might be to ask for five minutes at the next meeting and bring it up.
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 29 Oct 2021 19:13:39 +0000

*   I am actually not in favor of changing it to IETF Consensus. I think these have different meanings.

To be clear, I wasn’t expressing an opinion on whether or not to do this, I was just showing folks how to start the change process.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Oct 2021 12:17:53 -0700

Previous discussion is on this issue:
https://github.com/tlswg/tls13-spec/issues/1214

On Fri, Oct 29, 2021 at 12:13 PM Salz, Rich <[email-masked]> wrote:

>
>    - I am actually not in favor of changing it to IETF Consensus. I think
>    these have different meanings.
>
>
>
> To be clear, I wasn’t expressing an opinion on whether or not to do this,
> I was just showing folks how to start the change process.
>

---

From: Ira McDonald <[email-masked]>
Date: Fri, 29 Oct 2021 17:14:33 -0400

Hi Eric,

Thanks for the background.  I still sympathize with Hannes' point that
"Recommended" means "IETF Consensus".  I have to explain this
too often in the insular automotive industry.

But I certainly wouldn't write an RFC to change the title of a single
column in an IANA registry.  I've been one of the Designated Experts
for the IANA Internet Printing Protocol (IPP) registry for 20 years and
we rename IANA fields as needed by a direct request to our IANA
folks (after consensus in the IEEE-ISTO Printer Working Group IPP
WG - successor to IETF IPP WG in the 1990s).

Cheers,
- Ira

On Fri, Oct 29, 2021 at 3:18 PM Eric Rescorla <[email-masked]> wrote:

>>    - I am actually not in favor of changing it to IETF Consensus. I
>>    think these have different meanings.
>>
>>
>>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Oct 2021 14:16:59 -0700

Well, we certainly can change it in 8446-bis.

My put here would be: let's get consensus on the *semantics* we want for
the various categories without worrying about the names (call them A, B, C,
etc.) and then we can name them after.

-Ekr

On Fri, Oct 29, 2021 at 2:14 PM Ira McDonald <[email-masked]>
wrote:

>>> To be clear, I wasn’t expressing an opinion on whether or not to do
>>> this, I was just showing folks how to start the change process.
>>>
>>

---

From: Ira McDonald <[email-masked]>
Date: Fri, 29 Oct 2021 19:00:58 -0400

Hi Eric,

I agree.  Let's get the semantics right.  You mentioned a 3-tuple w/
"Discouraged".
Should that be "Deprecated" (for clarity)?

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Oct 2021 16:19:09 -0700

> Should that be "Deprecated" (for clarity)?

The implied semantics are are:

Recommended: The IETF has consensus this is good  (e.g., AES)
Not Recommended: We're not expression an opinion on this, it's just being
registered , so caveat emptor (e.g., Brainpool).
Discouraged: The IETF thinks this is bad and you shouldn't use it (e.g.,
MD5)

But I think the point being that Deprecated might also be new stuff we
think is bad, not just old stuff.

-Ekr

---

From: Sean Turner <[email-masked]>
Date: Fri, 29 Oct 2021 22:47:44 -0400

I actually think we’re going to try to do this 8447bis:
https://github.com/tls-stuff/rfc8447bis
We need to get it adopted, but that’s on tap for this IETF (or should be).

spt

> On Oct 29, 2021, at 17:16, Eric Rescorla <[email-masked]> wrote:
> 
> My put here would be: let's get consensus on the *semantics* we want for the various categories without worrying about the names (call them A, B, C, etc.) and then we can name them after.
> 
> -Ekr
> 
> 
> On Fri, Oct 29, 2021 at 2:14 PM Ira McDonald <[email-masked]> wrote:
> Hi Eric,
> 
> Previous discussion is on this issue: https://github.com/tlswg/tls13-spec/issues/1214
> 
> 	• I am actually not in favor of changing it to IETF Consensus. I think these have different meanings.
>  
>

---

From: Achim Kraus <[email-masked]>
Date: Sun, 31 Oct 2021 09:28:43 +0100

Hi List,

a lot of things have already been written.

So I'm not sure, if my e-mail from September last year could be
considered as well.

https://mailarchive.ietf.org/arch/msg/tls/pY6JDDb_WxBfgGbYh15vCS7sQQQ/

It's about, when replacing a "Y" with "N", then put also the period of
the "Y" amended to the "N", e.g. "N (was Y 2010-2019)".

best regards
Achim Kraus