Inline <tp> ----- Original Message ----- From: Ralph Holz ralph.h...@gmail.com Sent: 27/04/2020 12:25:43
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. <tp> I expect that you are familiar with draft-camwinget-tls-ns-impact which looks at operational security with TLS 1.2 and identifies what is difficult or impossible to do with TLS 1.3. One might infer from this I-D that TLS 1.3 offers less security than TLS 1.2:-) One requirement that was raised in the later stages of the work on TLS 1.3 related to audit, and was raised, I think, by representatives of the finance industry; the WG rejected the requirement. Since then, I have seen suggestions on the TLS and other lists, and in the press, about the development of alternative protocols to meet the requirements that TLS 1.3 does not. Hence my reference to fragmentation. (I think the I-D covers that under offline analysis). Although the I-D focusses on Operational Security, I think that much of what it says is applicable more generally. The I-D that we are being asked to adopt lacks any detail about what the bis might change i.e. we are being asked to approve a blank slate which might end up saying how great TLS 1.3 is and how we should move to it as soon as possible; to which the I-D I mention offers an alternative viewpoint. --- New Outlook Express and Windows Live Mail replacement - get it here: https://www.oeclassic.com/ Tom Petch 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 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
