I am also against adoption.
I would not be against a draft that made deployment recommendations, if
RFC 9325 was considered insufficient. (Although I don't like the idea of
suggesting that TLS 1.2 without support for quantum-resistant
cryptography is a recommended long-term solution.) However, as others
have noted, this draft is not making deployment recommendations, it is
specifying a new extension that signals the use of a slightly modified
version of TLS 1.2. I also agree that not adopting this draft does not
prevent people from using it, let alone continuing to use TLS 1.2.
Even if I thought the idea of having an extension to signal the use of a
slightly modified version of TLS 1.2 were a good idea, I believe there
is another reason that it would be best for this WG not to adopt the
draft. If the draft were adopted by the WG, then it would need to be
open for the WG to make technical changes to it. However, Peter
indicated in 2018 [0] that the extension defined in
draft-gutmann-tls-lts had been in use since 2016. It would be contrary
to the goal of this draft to suggest that those who have been using it
since 2016 should not modify their implementations to align with changes
made by the WG. It would also be inappropriate to adopt it as a WG
document, especially as a standards track document, and then effectively
declare that no technical changes can be made.
[0] https://mailarchive.ietf.org/arch/msg/tls/q7up_-tJH3ysD5Xip1mKGtTLKbg/
On 11/5/24 1:45 PM, Eric Rescorla wrote:
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> 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 | broadcom.com <http://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> 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
To unsubscribe send an email to tls-le...@ietf.org
