Re: [Uta] Robert Wilton's Discuss on draft-ietf-uta-rfc7525bis-09: (with DISCUSS and COMMENT)

[Thomas Fossati <[e-mail]>]

Hi Rob,

On Monday, 18 July 2022 at 15:35, Rob Wilton (rwilton) <[e-mail]> 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.  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?
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?
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.

I appreciate the slight frustration, but a policy of small steps is the
probably the most adequate for a BCP.

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.