Well, I think our respective positions are clear, so I'll just limit myself to one point.
On Fri, Nov 27, 2020 at 8:43 PM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
>
>
> > > 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".
Well, the problem is that it is secure from the perspective of the site author
but insecure from the perspective of the client. That's not going to end well
for the reasons I indicated above.
Regardless, this is not likely to happen on the Web: browsers are already
converging on simply disabling older versions, and I doubt are going to
have any interest in the approach you propose.
-Ekr
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
