Re: [TLS] PR#345: IANA Considerations

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.

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Tuesday, November 17, 2015 11:01 AM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Russ Housley <housley@vigilsec.com>; IETF TLS <tls@ietf.org>
Subject: Re: [TLS] PR#345: IANA Considerations

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

-Ekr

On Tue, Nov 17, 2015 at 10:56 AM, Andrei Popov <Andrei.Popov@microsoft.com<mailto:Andrei.Popov@microsoft.com>> 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:ekr@rtfm.com<mailto:ekr@rtfm.com>]
Sent: Tuesday, November 17, 2015 10:47 AM
To: Andrei Popov <Andrei.Popov@microsoft.com<mailto:Andrei.Popov@microsoft.com>>
Cc: Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>; IETF TLS <tls@ietf.org<mailto:tls@ietf.org>>

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.

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 <Andrei.Popov@microsoft.com<mailto:Andrei.Popov@microsoft.com>> 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:tls-bounces@ietf.org<mailto:tls-bounces@ietf.org>] On Behalf Of Russ Housley
Sent: Tuesday, November 17, 2015 10:01 AM
To: IETF TLS <tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] PR#345: IANA Considerations

+1.  This seems like a reasonable way forward.

Russ

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

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 <jsalowey@tableau.com<mailto:jsalowey@tableau.com>> 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" <tls-bounces@ietf.org<mailto:tls-bounces@ietf.org> on behalf of sean@sn3rd.com<mailto:sean@sn3rd.com>> wrote:

>On Nov 17, 2015, at 16:40, Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote:
>>
>> > 1. The Cipher Suites "Recommended" column was populated based on
>> >     the Standards Track RFCs listed in the document (and I removed the
>> >     others).
>>
>> 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.
>
>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
>_______________________________________________
>TLS mailing list
>TLS@ietf.org<mailto:TLS@ietf.org>
>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
TLS@ietf.org<mailto:TLS@ietf.org>
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
TLS@ietf.org<mailto:TLS@ietf.org>
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>