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.po...@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:e...@rtfm.com] > *Sent:* Tuesday, November 17, 2015 10:47 AM > *To:* Andrei Popov <andrei.po...@microsoft.com> > *Cc:* Russ Housley <hous...@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.po...@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-boun...@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 <jsalo...@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-boun...@ietf.org > on behalf of s...@sn3rd.com> wrote: > > >On Nov 17, 2015, at 16:40, Eric Rescorla <e...@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> > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
