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

Paul Wouters <> Wed, 27 July 2011 21:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0065521F89A7 for <>; Wed, 27 Jul 2011 14:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.531
X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lO4RyU1FoEIn for <>; Wed, 27 Jul 2011 14:13:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 457B021F8853 for <>; Wed, 27 Jul 2011 14:13:24 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 7C14257124; Wed, 27 Jul 2011 17:14:20 -0400 (EDT)
Date: Wed, 27 Jul 2011 17:14:20 -0400
From: Paul Wouters <>
To: Eric Rescorla <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Jul 2011 21:13:26 -0000

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 "" that pretends to be "". 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.