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
> On 5 Nov 2024, at 19:48, Nick Harper <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
> To unsubscribe send an email to 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
To unsubscribe send an email to tls-le...@ietf.org
