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>
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]
> *Sent:* Tuesday, November 17, 2015 10:47 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
>
>
>
> 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>
> 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] *On Behalf Of *Russ Housley
> *Sent:* Tuesday, November 17, 2015 10:01 AM
> *To:* IETF TLS <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> 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
> on behalf of sean@sn3rd.com> wrote:
>
> >On Nov 17, 2015, at 16:40, Eric Rescorla <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
> >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
> 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
> 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>
>
>
>