Re: [Last-Call] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Keith Moore <[e-mail]>]

On 11/27/20 11:30 PM, Eric Rescorla wrote:

>
> Well, I can't speak to how it sounds to you, but it's not a marketing
> argument but rather a security one. This is easiest to understand in
> the context of the Web, where you have a reference that contains one
> bit: http versus https,and all https content is treated the same, no
> matter which version of TLS it uses. In that context, having all the
> supported versions meet some minimum set of security properties is
> quite helpful. It's true that TLS 1.0, 1.1, 1.2,and 1.3 have different
> properties, which is precisely why it's desirable to disable versions
> below 1.2 so that the properties are more consistent.

Sure, it would be great if users and operators never had to worry about 
old TLS versions.  But in practice, they do, for reasons already 
mentioned.  It's simply not feasible to upgrade or discard everything 
using old versions of TLS in the next few years, and a lot of those 
hosts and devices and programs will continue to need to be used for a 
variety of valid reasons.    Pretending otherwise for the sake of an 
unrealistically simple statement of security policy seems unhelpful.

>
> > That's technically correct of course, but I think you know what I
> > mean. Without a reliable way of knowing that the server's certificate
> > is signed by a trusted party, the connection is vulnerable to an MITM
> > attack. And the only widely implemented reliable way of doing that
> > is to use well-known and widely trusted CAs.
>
> Yes, and those certificates can contain IP addresses. Not all
> public CAs issue them, but some do.

I'm aware of that.  But what really is the point of a cert (especially 
one issued by a public CA) that has an RFC1918 address as its subject?   
Not that it matters that much because the vast majority of sites using 
embedded systems aren't going to bother with them.  Most of those 
systems probably don't support cert installation by customers anyway.

>
>
> > > I'm not sure what clients you're talking about, but for the clients
> > > I am aware of, this would be somewhere between a broken experience
> > > and an anti-pattern. For example, in Web clients, because the origin
> > > includes the scheme, treating https:// URIs as http:// URIs will have
> > > all sorts of negative side effects, such as making cookies unavailable
> > > etc. For non-Web clients such as email and calendar, having any
> > > kind of overridable warning increases the risk that people will
> > > click through those warnings and expose their sensitive information
> > > such as passwords, which is why many clients are moving away from
> > > this kind of UI.
> > UI design is a tricky art, and I agree that some users might see (or
> > type) https:// in a field and assume that the connection is secure.
>
> In the Web context this is not primarily a UI issue; web client
> security mostly does not rely on the user looking at the URL (and in
> fact many clients, especially mobile ones, conceal the URL). Rather,
> they automatically enforce partitioning between insecure (http) and
> secure (https) contexts, and therefore having a context which is
> neither secure nor insecurecreates real challenges. Let me give you
> two examples:

To clarify, my suggestion was that https with TLS < 1.2 be treated as 
insecure, not as neither secure nor insecure or any kind of "in between".

(and yes, I was ware of that kind of partitioning)

> > But I think it's possible for UI designs to be more informative and 
> less
> > likely to be misunderstood, if the designers understand why it's
> > important. I also think that IETF is on thin ice if we think we're
> > in a better position than UI designers to decide what effectively
> > informs users and allows them to make effective choices, across all
> > devices and use cases.
>
> I'm not suggesting that the IETF design UI.
>
> We're getting pretty far into the weeds here, but I can tell you is
> that the general trend in this area -- especially in browsers but also
> in some mail and calendar clients -- is to simply present an error and
> to make overriding that error difficult if not impossible. This is
> informed by a body of research [0] that indicates that users are too
> willing to override these warnings even in dangerous settings.

Yes, I'm aware of that too.   You should probably be aware that one 
effect of this that I've seen affect actual products, is to avoid 
supporting TLS in embedded systems.

Keith