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 On Thu, Nov 19, 2015 at 7:10 AM, Eric Rescorla <e...@rtfm.com> wrote: > > > On Thu, Nov 19, 2015 at 7:03 AM, Martin Rex <m...@sap.com> wrote: > >> 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" >> >> >> I'm slightly confused. >> >> 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. > > > rfc5289 is only informational (i.e. _not_ standards track) and describes >> 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 > > >> >> >> >> -Martin >> > > > _______________________________________________ > 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
