Re: [Uta] Opportunistic encryption and authentication agility

[Keith Moore <[e-mail]>]

On 03/21/2014 09:37 PM, 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.
Partly.   And again, I expect that the mandate will be different for 
different protocols.

Note that as far as I can tell, it will still be possible to implement a 
client that supports only OE; it just doesn't bother verifying the cert 
/ DNSSEC + TLSA record / pinned key / whatever.    Whether that client 
will conform to the recommendations that this group produces, is a 
different question.   But offhand I don't know of a way to keep such 
clients from working (though for new protocols, it might be nice if 
there were one).

Similarly, even if we require TLS for some protocols, it will still be 
possible for a server to supply a self-signed cert with no additional 
validation; then it becomes up to the client to decide what to do with 
that.   We can make recommendations (or "mandates"), but we can't force 
clients to behave in any particular way.     And of course there will be 
some protocols for which it's impractical to require TLS in the near 
term, or maybe ever; e.g. cleartext operation for SMTP mail relaying is 
so well-entrenched that it might be harder to transition to all-TLS SMTP 
than it has been to transition to all-IPv6.

So our task is to make recommendations that server operators and client 
implementors want to implement, but which still improve security in the 
near term - and (perhaps more importantly) which also leave room for 
security to get better in the future.   To me this says that to endorse 
bare OE for any particular application should be an absolute last 
resort.   There should always be _some_ way for clients to learn which 
servers can be expected to support authenticated encryption, even if 
that varies from one application/protocol to the next.

Another subtlety:  There can be a difference between what we "mandate" 
for client and server implementations, versus what we "mandate" for 
services.   Example:   If a web site that does nothing but supply free 
information to unauthenticated parties doesn't want to support 
authenticated encryption, maybe that's just fine.   We might still want 
to "mandate" authenticated encryption for web sites that provide access 
to sensitive information, or for which user authentication is otherwise 
necessary.   But independent of the requirement for services, web client 
implementations could still be required (maybe as a SHOULD) to support 
authenticated encryption (using server certs, TLSA, pinning, or whatever 
set of methods were deemed appropriate to mandate).

> 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.

Who has mandated the "Web PKI" as the only way to verify a server 
cert?   Is this carved in stone?

> 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.
>
> I think that argues in favor of opportunistic TLS, for HTTP and other protocols.

I don't get it.  If the UTA WG can recommend that web clients permit OE, 
why can't it just as easily recommend that web clients treat OE (from a 
UI perspective) as no better than cleartext, but support pinning and/or 
DANE TLSA as alternative ways to verify a server cert to provide some 
indication to the user that the connection is secure?

Keith