Hi, I am not sure which key requirement you are referring to, or why TLS 1.3 should not see widespread use. In fact, TLS 1.3 is getting much more traction already than TLS 1.2 ever had in a comparable amount of time: https://arxiv.org/abs/1907.12762. I am not sure why you speak of a fragmentation of protocols here - if anything, we are seeing consolidation.
It seems weird to leave a BCP in a state that is not referring to the BP, which is definitely TLS 1.3 - due to the many additions made. TLS 1.3 also brings changes that are important for applications - 0-RTT, for example, has no replay protection, and should only be used with idempotent requests. While that is spelled out in the RFC, it's not where our audience would look (or we would not need BCPs). It's also worthwhile to deprecate < TLS 1.2, and discuss under which circumstances TLS 1.3 is preferable to TLS 1.2 (that's more a business question). Add to that a discussion of PSK. Plus a few new extensions, some defined in separate RFCs (eSNI for example). I am, of course, both an author on the old (and new) BCP, and also an author of the study I cite - but I think there's enough to warrant the -bis. Ralph On Mon, 27 Apr 2020 at 19:03, tom petch <daedu...@btconnect.com> wrote: > What is the point of rfc7525bis? Why do we need it? > > It seems to me that RFC7525 is a good set of recommendations and little > has changed, in practical terms, since it was produced, although > cryptanalysts can find weaknesses therein > > --- > New Outlook Express and Windows Live Mail replacement - get it here: > https://www.oeclassic.com/ > > . > > The one change I am aware of is that the TLS WG has produced TLS 1.3 - I > follow the TLS WG mailing list - but so what? TLS 1.3 failed to meet one > key requirement and I am unclear whether or not TLS 1.3 will gain > widespread use in the Internet, with HTTP, SMTP and such like. I see TLS > 1.2 as being adequate for most purposes for some time to come so my concern > is that rfc5575bis will simply be an endorsement of the work of the TLS WG > - 1.3 is great, ditch everything else - leading to further fragmentation of > the protocols. > > So, I am against adoption until it is clear that the I-D will endorse TLS > 1.2 as adequate for most purposes. After all, the TLS WG has yet to > propose an I-D 'TLS 1.2 - Die, Die, Die' > > Tom Petch > > > ----- Original Message ----- > From: Valery Smyslov <val...@smyslov.net> > To: <uta@ietf.org> > Cc: 'Yaron Sheffer' <yaronf.i...@gmail.com>, <uta-cha...@ietf.org>, > 'Ralph Holz' <ralph.h...@gmail.com>, 'Peter Saint-Andre' < > stpe...@mozilla.com> > Sent: 26/04/2020 10:35:30 > Subject: [Uta] Adoption call for draft-sheffer-uta-rfc7525bis-00 > > ________________________________________________________________________________ > > Hi, > > during the last virtual interim meeting the draft > draft-sheffer-uta-bcp195bis-00 was presented and the authors asked for its > adoption. > The general feeling in the room was in favor of the adoption, however > the authors were asked to rename it to *-rfc7525-bis. > The authors have renamed the draft and asked the chairs for its adoption. > Since our responsible AD thinks agrees that this work is within the charter > of the WG, the chairs are issuing a formal call for adoption > to confirm the results we had at the meeting. > > This message starts a two weeks call for adoption of the > draft-sheffer-uta-rfc7525bis-00 draft. > The call will end up 10 May 2020. Please send your opinions to the list > before this date. > > Please if possible include any reasons supporting your opinion. If you > support this adoption, > please indicate whether you are ready to review this draft if it becomes a > WG document. > > Regards, > Leif & Valery. > > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta >
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
