Hi all, I don’t think that we should consider saying that TLS 1.2 (or a variant) is an okay and safe choice for the next 10+ years while this protocol will not receive post-quantum security updates (if we stick with “no PQ for TLS 1.2”). I realize that integrating PQC in a “LTS” deployment might not be feasible/stable enough at this moment, but I fear that putting out a “TLS-LTS” gives people “permission" to ossify on non-PQC (as it will not be backported) for a considerable amount of time longer.
For this reason, and the same reasons as stated by Eric, Nick and Watson, I am against adoption of this document (or at least in this form). There may be contents of this document that we might consider extracting Cheers, Thom > Op 6 nov 2024, om 06:45 heeft Eric Rescorla <e...@rtfm.com> het volgende > geschreven: > > I am against adoption. > > As Nick and Watson note, this is not just a profile of TLS 1.2 but is rather > a set of negotiated with a new extension code point, i.e., it's effectively a > new version of TLS with as yet only lightly analyzed security properties. We > already have a new version of TLS which has been heavily analyzed and widely > deployed, namely TLS 1.3. > > There's nothing stopping people deploying this if they want to and in fact > there is already a code point assigned. However, the TLS WG should not take > up this work. > > -Ekr > > On Tue, Nov 5, 2024 at 1:21 PM Arnaud Taddei > <arnaud.taddei=40broadcom....@dmarc.ietf.org > <mailto:40broadcom....@dmarc.ietf.org>> wrote: >> I do support the adoption of this draft. >> >> This draft is a very good product and the details and care that this draft >> exhibits is in itself a testimony of someone who has a real production >> experience, is realistic and pragmatic. >> >> There is a big difference between >> patching an endpoint to a variation of TLS1.2 which is meant to work in >> a ’TLS1.2 designed environment” >> Vs >> patching an endpoint to TLS1.3 in an environment that was ’TLS1.2 >> designed environment’ >> >> If the organisation that needs to manage a security risk is given a choice >> of >> 1) Patch to TLS-LTS >> 2) Patch to TLS1.3 >> >> Any risk manager is going to ask the qualification of the implications on >> both and the result will be that 1) will be far less intrusive and risky >> than 2) >> >> Moreover the bench-test platform that the solution needs to go through to >> prove its production readiness may not be able to support TLS1.3 at all. >> >> Not adopting this draft leaves only one choice to any customer with no >> guarantees that the patching to TLS1.3 will work in its TLS1.2 designed >> end-to-end environment at a manageable time, cost and ‘go to production’ or >> ‘go to market’ time, and risk. >> >> Worse, it could have unanticipated consequences like breaking compliancy to >> regulations, to safety and I can just imagine how it could move the risks >> from bits and bytes to blood and flesh. >> >> My 0.02 Swiss francs >> >> Arnaud Taddei >> Global Security Strategist | Enterprise Security Group >> >> mobile: +41 79 506 1129 >> Geneva, Switzerland >> arnaud.tad...@broadcom.com <mailto:arnaud.tad...@broadcom.com> | >> broadcom.com <http://broadcom.com/> >> >>> On 5 Nov 2024, at 19:48, Nick Harper <i...@nharper.org >>> <mailto:i...@nharper.org>> wrote: >>> >>> I understand the stated goal of this draft to be to provide a way for >>> hard-to-update endpoints to keep using TLS 1.2 in a secure way. The idea of >>> a document that describes how to safely deploy TLS 1.2 sounds like a good >>> idea, e.g. "use only these cipher suites, require EMS and RI, etc". This >>> draft is not that. >>> >>> This draft makes changes to the TLS handshake protocol, which undermines >>> the goal of supporting hard-to-update endpoints. The two changes made to >>> the protocol are also addressed by RFC 8446. If endpoints need to be >>> updated to support TLS-LTS, it would make more sense to update them to >>> support TLS 1.3 than TLS-LTS. >>> >>> The rationale section (3.7) of the draft presents two reasons for using >>> TLS-LTS over TLS 1.3. The first is the slow deployment cadence of a new >>> protocol. LTS requires a change to the protocol and deployment of that new >>> change, no different from 1.3. The second reason is fear of the unknown in >>> 1.3: "TLS 1.3 is an almost entirely new protocol. As such, it rolls back >>> the 20 years of experience that we have with all the things that can go >>> wrong in TLS". The 20 years of all the things that can go wrong in TLS were >>> due to unsound cryptographic decisions. The research and analysis that >>> found those 20 years of issues was applied to the design of 1.3 to avoid >>> making the same mistakes. 1.3 doesn't roll back that experience, and we now >>> have over 8 years of experience with 1.3. >>> >>> I do not support adoption of the draft in this format. If the draft made no >>> changes to the TLS 1.2 protocol and were deployable only through >>> configuration changes (e.g. a fixed list of cipher suites and extensions), >>> I would probably support it. >>> >>> On Tue, Nov 5, 2024 at 11:02 AM Salz, Rich >>> <rsalz=40akamai....@dmarc.ietf.org <mailto:40akamai....@dmarc.ietf.org>> >>> wrote: >>>> I strongly support adoption. >>>> >>>> I do not understand why anyone would be opposed to the IETF making >>>> deployment recommendations. I can understand why someone might be bothered >>>> by the impliciation that *THIS ONE WAY* is the only way to get long-term >>>> support, especially if it's seen to contradict our encouragement of TLS >>>> 1.3. But that is an editorial issue that can be easily fixed. >>>> >>>> I would like to see this adopted, a short change cycle, and then advanced >>>> in the same cluster with our TLS 1.2 is frozen document. >>>> >>>> >>>> _______________________________________________ >>>> TLS mailing list -- tls@ietf.org <mailto:tls@ietf.org> >>>> To unsubscribe send an email to tls-le...@ietf.org >>>> <mailto:tls-le...@ietf.org> >>> _______________________________________________ >>> TLS mailing list -- tls@ietf.org <mailto:tls@ietf.org> >>> To unsubscribe send an email to tls-le...@ietf.org >>> <mailto:tls-le...@ietf.org> >> >> >> This electronic communication and the information and any files transmitted >> with it, or attached to it, are confidential and are intended solely for the >> use of the individual or entity to whom it is addressed and may contain >> information that is confidential, legally privileged, protected by privacy >> laws, or otherwise restricted from disclosure to anyone else. If you are not >> the intended recipient or the person responsible for delivering the e-mail >> to the intended recipient, you are hereby notified that any use, copying, >> distributing, dissemination, forwarding, printing, or copying of this e-mail >> is strictly prohibited. If you received this e-mail in error, please return >> the e-mail to the sender, delete it from your computer, and destroy any >> printed copy of it._______________________________________________ >> TLS mailing list -- tls@ietf.org <mailto:tls@ietf.org> >> To unsubscribe send an email to tls-le...@ietf.org >> <mailto:tls-le...@ietf.org> > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
