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

[Paul Wouters <[e-mail]>]

On Wed, 27 Jul 2011, Eric Rescorla wrote:

>> The TLS server never omits sending its public key. It only omits sending
>> it in a PKIX container.
>
> I don't get this from the draft.

Sorry for the confusion. I meant "an identifier of the key (full or hash)".
Previously, we thought about completely omitting the seerver from sending
its key (or hash thereof). If sending hashes makes people uncomfortable,
we could look at insisting the full public key is sent. But that has its
disadvantages (requiring an ASN.1 parser)


>> Perhaps we were not clear enough in section 1.1. The primary motivation
>> is to allow decoupling of TLS server public key authentication from PKIX
>> validation, allowing TLS clients to determine their own authentication
>> scheme to apply for talking to the TLS Server.
>
> Yes, but that's not an argument against using the PKIX container.

In my opinion, it is.

[ PKIX wrapping ]

> I don't see that this is a big deal.

Yes, I understood that's your view.

>> TLS clients that would only need to support something like DANE, would not
>> even
>> need an ASN.1 parser anymore if the TLS server supports this new TLS
>> extension.
>
> 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.

> Oh, and to parse the SPKI, which is in BER.

Not if you use the hashed public key variant :)

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

Paul