Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt

[Eric Rescorla <[e-mail]>]

On Wed, Jul 27, 2011 at 5:14 PM, Paul Wouters <[e-mail]> wrote:
> On Wed, 27 Jul 2011, Eric Rescorla wrote:

>> Except, you know, to talk to the 99.99999% of the universe that uses PKIX
>> certs.
>
> With that reasoning, we'd all be riding horses still. The extension offers a
> way
> out of some overly complex outdated overkill technology, with no impact on
> people
> who wish to remain using horses.

For some reason this argument is not exactly convincing.



>>> And what did that ignoring get us? Massive amounts of popups and security
>>> warnings to click away. The idea is that we cannot receive a TLS public
>>> key for "dane.xelerance.com" that pretends to be "paypal.com". Saying
>>> that it is easy to ignore is not a strong argument for trying to ensure
>>> no one has to make the ignore/not ignore decision by a proper design.
>>
>> I think you misunderstand my point, which is that if the implementation
>> has some
>> other mechanism for validating the cert it can ignore the rest of it.
>> I'm not talking about the user ignoring it.
>
> The two are coupled., if the browser needs to store the incoming PKIX for
> its
> own administration. If using DANE only the pubkey is authenticated, it
> cannot
> ever display the CN= to the user if the user requests to see more info on
> the
> security status of its connection.

I have no idea why this would be true.

Regardless, as I said in my review, this seems like it's largely
duplicative of cached
info (and in fact, rather clumsier). Is there something here that
couldn't be accomplished
by a SPKI cache type in cached-info?

-Ekr