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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
