Hi Thomas,
From: Thomas Fossati <thomas.foss...@arm.com> Sent: 18 July 2022 16:41 To: Rob Wilton (rwilton) <rwil...@cisco.com>; Martin Thomson <m...@lowentropy.net>; Peter Saint-Andre <stpe...@stpeter.im>; The IESG <i...@ietf.org> Cc: draft-ietf-uta-rfc7525...@ietf.org; uta-cha...@ietf.org; uta@ietf.org; le...@sunet.se Subject: Re: [Uta] Robert Wilton's Discuss on draft-ietf-uta-rfc7525bis-09: (with DISCUSS and COMMENT) Hi Rob, On Monday, 18 July 2022 at 15:35, Rob Wilton (rwilton) <rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote: > > I think that you are right to be cautious here. What you want to > > have happen is interoperability. If you say 1.2 or later, then > > there is a risk of some implementations doing 1.2 only and some > > doing 1.3 only, then you lose the ability to communicate. > > The introduction states: > > This document attempts to minimize new guidance to TLS 1.2 > implementations, and the overall approach is to encourage systems > to move to TLS 1.3. > > and > > These are minimum recommendations for the use of TLS in the vast > majority of implementation and deployment scenarios, with the > exception of unauthenticated TLS (see Section 5). > > And section 3.1.1 states: > > Rationale: secure deployment of TLS 1.3 is significantly easier > and less error prone than secure deployment of TLS 1.2. > > I completely get wanting the interop, but the MUST implement TLS 1.2 > still feels too strong given that AIUI, one of the reasons for TLS 1.3 > was to help mitigate some of the security issues that turned up in TLS > 1.2. > > It feels reasonable to me for a server deployment to decide that > they will only support TLS 1.3 because it is easier to deploy > securely, placing the requirement on the client to also support TLS > 1.3 for successful interop. > > Equally, I can also foresee continued deployments, where they still > decide to support old versions of TLS before 1.2 to ensure that they > can still interoperate with legacy clients that have not upgraded. Sure a deployment can do as they decide to, but negotiating < 1.2 is not considered secure anymore. Sure. Agreed. OTOH, the 1.2 profile that the document describes (and that the endpoints are required to implement) is not less secure than 1.3. The document in its current form acknowledges the reality that today not all stacks are fully ready and, for a variety of reasons, not all deployments can be readily upgraded to 1.3. MbedTLS and its ecosystem are in that position: nearly there, but not 100% yet. The desired state is everyone runs 1.3 (because it's less complex, not because it's more secure than the profiled 1.2 defined in the BCP.) What are the risks of mandating 1.2 as baseline? I think that there are two risks: 1. It may be less secure, if this comment is correct "secure deployment of TLS 1.3 is significantly easier and less error prone than secure deployment of TLS 1.2"? 2. My interpretation from the document is that it is more important to implement TLS 1.2 than it is to implement TLS 1.3. If that is the intent, then okay, but then the quoted comment about TLS 1.3 being significantly easier sort of seems entirely irrelevant if implementations MUST still deploy TLS 1.2. But I just find the guidance in the document somewhat confusing: Years later this transition is largely complete and TLS 1.3 is widely available. ... This document attempts to minimize new guidance to TLS 1.2 implementations, and the overall approach is to encourage systems to move to TLS 1.3. However, this is not always practical. ... As noted, the TLS 1.3 specification resolves many of the vulnerabilities listed in this document. A system that deploys TLS 1.3 should have fewer vulnerabilities than TLS 1.2 or below. Therefore this document replaces [RFC7525<https://datatracker.ietf.org/doc/html/rfc7525>], with an explicit goal to encourage migration of most uses of TLS 1.2 to TLS 1.3. So, I read this document saying TLS 1.3 is great, and fixes a load of issues with TLS 1.2 which is why you absolutely MUST deploy TLS 1.2, and it would be nice if you did TLS 1.3 as well! Do we disincentivise converging to the desired goal? Maybe, it depends on how other levers play out. Anyway, worst case the parties negotiate the profiled 1.2, which guarantees excellent security. What are the risks of not mandating 1.2 as baseline? What about saying SHOULD support 1.2 except for deployments where TLS 1.3 is supported and it is known that all clients are capable of supporting TLS 1.3? E.g., TLS 1.3 for NETCONF is coming along, and the ISPs may want to configure the device to only use/allow TLS 1.3 and not TLS 1.2, but they would have to violate/ignore this guidance to turn off TLS 1.2 ... or perhaps the implementation could argue that they don't need to allow TLS 1.2 to be disabled because this RFC mandates that it has to be supported everywhere ... Do we create breakage that can't be easily fixed? Quasi certain. To me it's a question of timing, and I think we can defer the decision to when data give us confidence that the induced breakage is minimal. Note that a "SHOULD support 1.3" is pretty strong (RECOMMENDED may be slightly stronger?) and paves the way for being more radical with the next iteration of this document. RECOMMENDED means exactly the same as SHOULD, so alas that won't help. I appreciate the slight frustration, but a policy of small steps is the probably the most adequate for a BCP. Yes. I agree to the small steps thing, and I understand setting TLS 1.2 as the minimum bar. But as I said above, my current reading of the RFC 2119 language makes it unclear to me whether the goal is really to move everyone to TLS 1.3 or at least TLS 1.2. If I find this text confusing then I suspect that general implementors will also do so. Thanks, Rob Cheers, thanks IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
