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

[Eric Rescorla <[e-mail]>]

On Wed, Jul 27, 2011 at 4:14 PM, Paul Wouters <[e-mail]> wrote:
> On Mon, 25 Jul 2011, Eric Rescorla wrote:
>
> Thank you for your review Eric.
>
>> This document describes a mechanism for allowing the client to
>> indicate to the server that he has cached the server's TLS
>> public key. The server then omits the key from the handshake
>> and the client relies on the cached value.
>
> Not entirely.
>
> 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. It says:

   The TLS server MAY respond with an extension of type
   "oob_pubkey_list" in the (extended) server hello.  The
   "extension_data" field of this extension SHALL contain
   "PublicKeyList" containing exactly one of the "PublicKey" identifiers
   used in the received client hello message.  It SHALL use the same
   IdentifierType as the TLS client used to send the identifier to the
   TLS server.  It MUST NOT send and empty PublicKeyList.

   If the TLS server responds with an extension of type
   "oob_pubkey_list", it SHOULD omit sending a "Server Certificate"
   message.


If the client sends a hash, then I read this as saying the server also says
a hash. where does the server send it's public key?


>> OVERALL
>> Section 1.1 appears to describe two primary motivations for this
>> extension:
>>
>> - It saves the cost of transmitting the certificate over the network
>>  to the client.
>> - It potentially conflicts with other validation mechanisms which
>>  the client may have for checking the server cert.
>
> 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. The argument
you offer against that is that there are conflicting semantics.



> One example given were the conflicts of TLSA/HASTLS data with PKIX data
> when using DANE.
>
> Another one we did not mention is, and which we should probably add,
> is that some applications (eg browsers) cannot store PKIX received
> information for non-PKIX authentication methods. In other words, a browser
> cannot store a certificate used as packaging container for a DANE TLS
> server public key, because it contains a made up, unvalidatable, CN=
> which cannot be left out of a PKIX cert. Think of my DANE certificate
> specifying CN=paypal.com for the host dane.xelerance.com. The browser is
> forced to maintain an internal list of what information inside the PKIX
> container has been properly validated with a non-PKIX method (eg DANE)

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


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


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


>> I don't see any reason why it's troublesome to ignore the rest of
>> the certificate; indeed this is a quite common practice when
>> self-signed certs are in use.
>
> 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.


-Ekr