Re: [Uta] Opportunistic encryption and authentication agility

[Trevor Perrin <[e-mail]>]

On Fri, Mar 21, 2014 at 7:51 PM, Keith Moore <[e-mail]> wrote:
>
> 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.

I'm not sure how much we disagree.  Of course authentication is better
than none.

But I disagree with the HTTPS approach of disallowing encryption
unless it can be done with an IETF-approved method of authentication
and signalled to the user as a secure connection.

I think we should have the ability to encrypt HTTP using new auth
methods which may or may not get signalled.  That would lower the bar
for experimenting with and deploying new methods.


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

I'm talking about mandates on the server.

The installed base mandates that any HTTPS URL requires a valid cert.
That pretty much *is* 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?

Sounds great, that's what I want.


Trevor