Subject: [TLS] PR#345: IANA Considerations

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2015 15:16:50 -0800

PR: https://github.com/tlswg/tls13-spec/pull/345

Per discussion in Yokohama, I have rewritten the IANA considerations section
so that the 16-bit code spaces are "Specification Required" and they have
a "Recommended" column.

1. The Cipher Suites "Recommended" column was populated based on
    the Standards Track RFCs listed in the document (and I removed the
    others).

2. The Extensions "Recommended"column was populated by taking all
    the Standards Track RFCs and marking them "Yes" and marking
    others "No". I recognize that this probably marks a bunch of extensions
    which we actually don't love as "Yes" (and perhaps others as "No")
    and if people want to move some from one column to another, that
    seems like a great mailing list discussion which I will let the chairs
    drive.

Thanks,
-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2015 15:18:46 -0800

Double-checking, I see that some of the entries in the "TLS 1.3" column
for Extensions are wrong. Will be updating shortly.

---

From: Sean Turner <[email-masked]>
Date: Tue, 17 Nov 2015 15:58:10 +0200

> On Nov 17, 2015, at 01:18, Eric Rescorla <[email-masked]> wrote:
> 

Isn’t it just the MTI suites listed in s8.1?

Also, I added a comment in github requesting that we add a permanent note to the registry to alert folks looking there for the Recommended Yes/No marking.

IANA [SHALL add/has added] the following to the following to the TLS Cipher Suite Registry:

NOTE
      Cipher suites marked as "Yes" are the MTI TLS 1.3 cipher suites
      in the RFC 2119-sense (See Section 8.1 of [THISRFC]) and can be
      updated later. Algorithms marked as "No" are not; cipher suites
      marked "No" range from "good" to "bad" from a cryptographic
      standpoint.

Maybe we should also add that cipher suites marked “No” can later be marked as “Yes” later?

spt

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Nov 2015 06:40:00 -0800

> Isn’t it just the MTI suites listed in s8.1?

Maybe I need to go check the minutes, but I thought it was the
Standards Track ones, not the MTI ones that we agreed on.
The difference here is largely the FFDHE cipher suites and CCM.

Also, I added a comment in github requesting that we add a permanent note
> to the registry to alert folks looking there for the Recommended Yes/No
> marking.
>

Sure. PR or it didn't happen :)

-Ekr

---

From: Sean Turner <[email-masked]>
Date: Tue, 17 Nov 2015 16:41:48 +0200

> The difference here is largely the FFDHE cipher suites and CCM.

Fair enough we should double check.

> Sure. PR or it didn't happen :)

Ack :)

---

From: Sean Turner <[email-masked]>
Date: Tue, 17 Nov 2015 16:54:45 +0200

> The difference here is largely the FFDHE cipher suites and CCM.

From Jim’s notes in the etherpad:

AOB
SPT: Requests for additional ciphers from others.  Listing in A.4
	Suggest thinning it down to the SHOULD/MUST list only.
EKR: Need to encourage support for PSK variants
EKR: Looking at the difference between the "good" list and the "safe" list and the "no opinion" list
EKR: Sample case would be 448 - not a MUST/SHOULD but still think it is good.

spt

---

From: Joe Salowey <[email-masked]>
Date: Tue, 17 Nov 2015 16:46:07 +0000

I think the TLS 1.3 IANA considerations should just deal with setting up the recommended column and marking it for the cipher suites/extensions that are described in the 1.3 document.  Other cipher suites/extensions  can be marked as recommended through other documents.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Nov 2015 09:51:32 -0800

There are presently four categories of cipher suites vis-a-vis TLS 1.3.

1. MUST or SHOULD cipher suites.
2. Standards track cipher suites (or ones we are making ST, like
    the ECC ones).
3. Non standards track cipher suites
4. Cipher suites you can't use at all with TLS 1.3, like AES-CBC.

I think we're all agreed that category #1 should be marked recommended
and that #3 and #4 should not be. This leaves us with category #2, which
includes stuff like:

- FFDHE
- CCM

My proposal is that we:

- List all the Standards Track cipher suites that are compatible with TLS
1.3 in Appendix A.
- Mark all the cipher suites that are listed in Appendix A as "Recommended"

-Ekr

On Tue, Nov 17, 2015 at 8:46 AM, Joe Salowey <[email-masked]> wrote:

> I think the TLS 1.3 IANA considerations should just deal with setting up
> the recommended column and marking it for the cipher suites/extensions that
> are described in the 1.3 document.  Other cipher suites/extensions  can be
> marked as recommended through other documents.
>
>
>
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 17 Nov 2015 11:53:41 -0600

> I think the TLS 1.3 IANA considerations should just deal with setting up the recommended column and marking it for the cipher suites/extensions that are described in the 1.3 document.  Other cipher…

That would seem to leave a number of things in limbo until this
hypothetical other document or documents come out.  It seems more
responsible in some sense to make the registry be in a
coherent/consistent state from the time its structure is modified.

-Ben

---

From: Russ Housley <[email-masked]>
Date: Tue, 17 Nov 2015 13:01:14 -0500

+1.  This seems like a reasonable way forward.

Russ

On Nov 17, 2015, at 12:51 PM, Eric Rescorla wrote:

> - List all the Standards Track cipher suites that are compatible with TLS 1.3 in Appendix A.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 17 Nov 2015 18:36:40 +0000

What is the intended use of the "Recommended" list? I.e. how is an implementer supposed to think about this marker?

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Tuesday, November 17, 2015 10:01 AM
To: IETF TLS <[email-masked]>
Subject: Re: [TLS] PR#345: IANA Considerations

Russ

- FFDHE
- CCM

My proposal is that we:

-Ekr

On Tue, Nov 17, 2015 at 8:46 AM, Joe Salowey <[email-masked]<mailto:[email-masked]>> wrote:
I think the TLS 1.3 IANA considerations should just deal with setting up the recommended column and marking it for the cipher suites/extensions that are described in the 1.3 document.  Other cipher suites/extensions  can be marked as recommended through other documents.

On 11/17/15, 6:54 AM, "TLS on behalf of Sean Turner" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

>On Nov 17, 2015, at 16:40, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Isn't it just the MTI suites listed in s8.1?
>>
>From Jim's notes in the etherpad:
>
>AOB
>[email-masked]<mailto:[email-masked]>
>https://www.ietf.org/mailman/listinfo/tls<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c93b5f706db184f0ff21a08d2ef7928e3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=psX1xULe1yb%2ffQibjLpvVTgFaltnGiMcqeo8S1Y91qE%3d>

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c93b5f706db184f0ff21a08d2ef7928e3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=psX1xULe1yb%2ffQibjLpvVTgFaltnGiMcqeo8S1Y91qE%3d>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Nov 2015 10:47:07 -0800

Here is my understanding

- Recommended things are things which the IETF has reviewed and thinks are
good.
- Not recommended things are things which the IETF has not reviewed and may
be fine but may also be bad.

The intention is to break the binding between code point assignment and
endorsement.

-Ekr

On Tue, Nov 17, 2015 at 10:36 AM, Andrei Popov <[email-masked]>
wrote:

> What is the intended use of the “Recommended” list? I.e. how is an
> implementer supposed to think about this marker?
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Russ Housley
> *Sent:* Tuesday, November 17, 2015 10:01 AM
> *To:* IETF TLS <[email-masked]>
> *Subject:* Re: [TLS] PR#345: IANA Considerations
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c93b5f706db184f0ff21a08d2ef7928e3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=psX1xULe1yb%2ffQibjLpvVTgFaltnGiMcqeo8S1Y91qE%3d>
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c93b5f706db184f0ff21a08d2ef7928e3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=psX1xULe1yb%2ffQibjLpvVTgFaltnGiMcqeo8S1Y91qE%3d>
>
>
>

---

From: Andrei Popov <[email-masked]>
Date: Tue, 17 Nov 2015 18:56:33 +0000

This is a good intention. Can we then choose a stronger, more definitive term? E.g. “non-standard”, “vendor-specific”, “private”, “not IETF-reviewed” or something better.

I feel that “recommended” will change over time, and also that cipher suites and extensions “recommended” for TLS1.3 are different than those “recommended” for TLS 1.2.

On the other hand, something we mark “non-standard” or “vendor-specific” is generally unlikely to move to the “standard” category.

From: Eric Rescorla [mailto:[email-masked]]
Sent: Tuesday, November 17, 2015 10:47 AM
To: Andrei Popov <[email-masked]>
Cc: Russ Housley <[email-masked]>; IETF TLS <[email-masked]>
Subject: Re: [TLS] PR#345: IANA Considerations

Here is my understanding

- Recommended things are things which the IETF has reviewed and thinks are good.
- Not recommended things are things which the IETF has not reviewed and may be fine but may also be bad.

-Ekr

On Tue, Nov 17, 2015 at 10:36 AM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
What is the intended use of the “Recommended” list? I.e. how is an implementer supposed to think about this marker?

Cheers,

Andrei

From: TLS [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Russ Housley
Sent: Tuesday, November 17, 2015 10:01 AM
To: IETF TLS <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] PR#345: IANA Considerations

Russ

- FFDHE
- CCM

My proposal is that we:

-Ekr

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cad1ada64cabc48bab31408d2ef7f963f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KiElWscMZZYI9wG4qHzvXyncIJJlM3P37WhU6L2mNB8%3d>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Nov 2015 11:00:58 -0800

I would be fine with any name people want to use here :)

-Ekr

On Tue, Nov 17, 2015 at 10:56 AM, Andrei Popov <[email-masked]>
wrote:

> This is a good intention. Can we then choose a stronger, more definitive
> term? E.g. “non-standard”, “vendor-specific”, “private”, “not
> IETF-reviewed” or something better.
>
>
>
> I feel that “recommended” will change over time, and also that cipher
> suites and extensions “recommended” for TLS1.3 are different than those
> “recommended” for TLS 1.2.
>
>
>
> On the other hand, something we mark “non-standard” or “vendor-specific”
> is generally unlikely to move to the “standard” category.
>
>
>
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* Tuesday, November 17, 2015 10:47 AM
> *To:* Andrei Popov <[email-masked]>
> *Cc:* Russ Housley <[email-masked]>; IETF TLS <[email-masked]>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cad1ada64cabc48bab31408d2ef7f963f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=KiElWscMZZYI9wG4qHzvXyncIJJlM3P37WhU6L2mNB8%3d>
>
>
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 17 Nov 2015 19:06:52 +0000

> - Mark all the cipher suites that are listed in Appendix A as "Recommended"

Where does that leave ciphersuites that are "Recommended" for TLS
1.2, but TLS 1.3?  Or do none of the CBC block ciphers in TLS 1.2 qualify?

Suites like (please pardon the OpenSSL-specific naming):

    ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH  Au=ECDSA Enc=AES(256)  Mac=SHA384
    ECDHE-RSA-AES256-SHA384   TLSv1.2 Kx=ECDH  Au=RSA   Enc=AES(256)  Mac=SHA384
    DHE-RSA-AES256-SHA256     TLSv1.2 Kx=DH    Au=RSA   Enc=AES(256)  Mac=SHA256

    ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128)  Mac=SHA256
    ECDHE-RSA-AES128-SHA256   TLSv1.2 Kx=ECDH Au=RSA   Enc=AES(128)  Mac=SHA256
    DHE-RSA-AES128-SHA256     TLSv1.2 Kx=DH   Au=RSA   Enc=AES(128)  Mac=SHA256

I'd have thought these would still qualify as recommended (for TLS
1.2).  And then "not recommended" would cover more exotic/obsolete
codepoints.

-- 
	Viktor.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 17 Nov 2015 19:11:46 +0000

I personally favor the B-name you used at the meeting, but IANA might have a problem with it☺.

if the distinction is that certain code points are assigned to TLS features that are not IETF-reviewed or endorsed, for collision avoidance only, I think the marker name should specifically say so.

Sent: Tuesday, November 17, 2015 11:01 AM

-Ekr

On Tue, Nov 17, 2015 at 10:56 AM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
This is a good intention. Can we then choose a stronger, more definitive term? E.g. “non-standard”, “vendor-specific”, “private”, “not IETF-reviewed” or something better.

From: Eric Rescorla [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, November 17, 2015 10:47 AM
To: Andrei Popov <[email-masked]<mailto:[email-masked]>>
Cc: Russ Housley <[email-masked]<mailto:[email-masked]>>; IETF TLS <[email-masked]<mailto:[email-masked]>>

Here is my understanding

-Ekr

Cheers,

Andrei

Russ

- FFDHE
- CCM

My proposal is that we:

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 17 Nov 2015 21:14:00 +0200

> 1.2, but TLS 1.3?  Or do none of the CBC block ciphers in TLS 1.2 qualify?

None of block ciphers (nor stream ciphers) work in TLS 1.3 at all.

All current registered/proposed ciphersuites that work in TLS 1.3 are
*-GCM or *-POLY1305 ones (with DHE or ECDHE).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Nov 2015 11:14:32 -0800

> 1.2, but TLS 1.3?  Or do none of the CBC block ciphers in TLS 1.2 qualify?

Yes. The proposed intention was that for the same reasons we moved to
AEAD for 1.3, we would only Recommend AEAD for TLS 1.2. Note that
this is consistent with the guidance in both RFC 7525 (which recommends
AEAD) http://tools.ietf.org/html/rfc7525#section-4.2 and RFC 7540
which blacklists the non-AEAD cipher suites
(http://tools.ietf.org/html/rfc7540#appendix-A)

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 17 Nov 2015 19:17:05 +0000

> *-GCM or *-POLY1305 ones (with DHE or ECDHE).

I'm well aware of that, I'm just wondering whether the "Recommended"
column should cover recommendations for TLS 1.2 as well TLS 1.3?

That is, I thought it might distinguish between mainstream and
non-mainstream ciphers for multiple protocol versions.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 17 Nov 2015 21:29:26 +0000

I prefer to see two categories:  recommended and “no comment”
MUST or SHOULD are recommended and everything else is “no comment”
Having one pool, from which we can cherry-pick, as opposed to finer levels of gradation, seems simpler.  If and when we’re ready to move Goldilocks/448 to recommended, it will not matter that it’s in the same pile as 3DES-CBC.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 17 Nov 2015 23:30:25 -0500

> *-GCM or *-POLY1305 ones (with DHE or ECDHE).

DHE AES CCM is still in the list, even after the changes in the current proposal. ECDHE AES CCM is not as it's not standards track. There's an argument that it should be promoted alongside ECDHE AES GCM, however we're not really recommending CCM so that's probably not desired (and I don't know if it has had enough use to be considered recommended).

There will likely also be AES OCB, at some point.

> column should cover recommendations for TLS 1.2 as well TLS 1.3?

Yes. The following is in the backwards compatibility appendix in the current draft:

"If an implementation negotiates use of TLS 1.2, then negotiation of cipher suites also supported by TLS 1.3 SHOULD be preferred, if available."

At the end of the day, though, it's just a qualified "SHOULD". We're just talking recommendations. This isn't a diediedie RFC.

Dave

---

From: Hubert Kario <[email-masked]>
Date: Wed, 18 Nov 2015 17:02:05 +0100

On Monday 16 November 2015 15:16:50 Eric Rescorla wrote:
> Per discussion in Yokohama, I have rewritten the IANA considerations
> section so that the 16-bit code spaces are "Specification Required"
> and they have a "Recommended" column.
> 

>     others "No". I recognize that this probably marks a bunch of
> extensions which we actually don't love as "Yes" (and perhaps others
> as "No") and if people want to move some from one column to another,
> that seems like a great mailing list discussion which I will let the
> chairs drive.

why max_fragment_length [RFC6066] is not to be supported in TLSv1.3?

https://tools.ietf.org/html/draft-ietf-dice-profile-17#section-15 states 
that this is a MUST for IoT TLS profile

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Nov 2015 08:34:27 -0800

> why max_fragment_length [RFC6066] is not to be supported in TLSv1.3?

Pilot error. Send a PR or comment on the PR.. :)

-Ekr

---

From: [email-masked] (Martin Rex)
Date: Thu, 19 Nov 2015 16:03:12 +0100 (CET)

> - Mark all the cipher suites that are listed in Appendix A as "Recommended"

I'm slightly confused.

rfc5288 is standards track and describes AES-GCM with static RSA keyex.

rfc5289 is only informational (i.e. _not_ standards track) and describes
AES-GCM with ECDHE keyex.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Nov 2015 07:10:10 -0800

> rfc5288 is standards track and describes AES-GCM with static RSA keyex.

This isn't compatible with TLS 1.3 because TLS 1.3 removes static RSA.

> AES-GCM with ECDHE keyex.

We are re-labelling the AES-GCM ECDHE suites as standards track either in
this document or in RFC4492bis.

-Ekr

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 25 Nov 2015 11:05:37 -0800

It looks like we have rough consensus to accept this PR. We can still have
discussion on the naming of the categories.  We will also have to define
the IANA registration policy for changing the "recommended" bit.   I'll
open an issue for this,  I think changing the bit to recommended should
require IETF consensus.

Cheers,

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Nov 2015 15:18:03 -0800

Joe,

Can you clarify whether you believe consensus is to make the "Recommended"
list the list in the current PR or the MTI list. I can edit the document
either
way.

-Ekr

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 29 Nov 2015 20:08:11 -0800

I believe the consensus supports what is in the current PR.

Cheers,

Joe

On Thu, Nov 26, 2015 at 3:18 PM, Eric Rescorla <[email-masked]> wrote:

>> It looks like we have rough consensus to accept this PR. We can still
>> have discussion on the naming of the categories.  We will also have to
>> define the IANA registration policy for changing the "recommended" bit.
>> I'll open an issue for this,  I think changing the bit to recommended
>> should require IETF consensus.
>>
>> Cheers,
>>
>> Joe
>>
>>> We are re-labelling the AES-GCM ECDHE suites as standards track either
>>> in this document or in RFC4492bis.
>>>
>>> -Ekr
>>>
>>>
>>>>
>>>>
>>>>
>>>> -Martin
>>>>
>>>
>>>