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
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls