Re: [Uta] Opportunistic encryption and authentication agility

[Aaron Zauner <[e-mail]>]

Trevor Perrin wrote:
> A point I haven't seen in the recent debate:
> 
> Whether a TLS connection is "opportunistic" or "authenticated" depends
> not just on the wire protocol but on the client's capabilities.
> 
> A client who possesses an HPKP or TACK pin, or is capable of querying
> DANE or Convergence, might be able to authenticate a connection which
> to a different client would be opportunistic.
> 
> So when we talk about OE at the protocol level, I think we're really
> talking about whether to allow agility of authentication methods, or
> mandate a specific method.
We should, yes. And we should get rid of the term "opportunistic". It
seems to me that a lot of people do mean different things by that. Not
necessarily on this ML: Just Google through blogs and search twitter.

But I certainly do not want to start up this discussion again. The thing
is, we need to be clear on what we define as "opportunistic".

> In the case of HTTPS, the Web PKI has been mandated.  A small site
> that doesn't want to pay the costs of Web PKI but would be willing to
> deploy cheaper methods (pinning; DNSSEC/DANE) cannot do so.
Common sense tells you that trust is not something you can buy. Trust
has to be earned, just like in the real world, and proven over and over
again.

I have repeated myself for the last couple of years on this issue, and
am repeating myself almost continuously since last summer: just get rid
of X.509 for trust on the internet. On local scale it might make sense,
it does not, however, on a widely dispersed and distributed system.

TACK is an elegant proposal that might in the end be able to fade out CA
bound trust as in use today. I hope it does get accepted and deployed,
as of today I cannot see any reason why it shouldn't be.

> If opportunistic TLS was allowed, then we would have the ability to
> deploy new auth methods without having to forever support whatever was
> in vogue when the initial standard came out.
+1

> I think that argues in favor of opportunistic TLS, for HTTP and other protocols.
+1

Aaron