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

From: Eric Rescorla <[email-masked]>
Date: Mon, 25 Jul 2011 13:19:00 -0400

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.

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.

In support of these motivations it lists the following use cases
(numbered by me):

   1. The TLS server public key is obtained from a [PKIX] certificate
      chain from an [LDAP] server

   2. The TLS server public key is obtained from a DNSSEC secured RRset
      using [DANE]

   3. The TLS server public key is provisioned by the operating system
      and updated via software updates

   4. A TLS client has connected to the TLS server before and has cached
      the TLS server certificate chain or TLS server public key for re-
      use

The second motivation does not apply to use cases (1) and (4): The
server's credentials are already phrased as PKIX credentials and
client can validatte them however it wishes, the only need is for the
server and client to assure themselves that they have the same set of
validated credentials. Thus, the only issue here is bandwidth; the TLS
WG already has a (dormant) work item on caching certificate messages,
draft-ietf-tls-cached-info. That item is dormant due primarily to lack
of energy. To the extent to which we are dealing with certs phrased as
PKIX credentials, then energy should be applied to that document.

The second motivation is more convincing for cases (2) and (3) [though
in truth it is IMO still more likely that in case 3 the credential
will be phrased as a cert.] However, it's not really that convincing
to me: TLS stacks already have X.509 parsing, and pulling the public
key out is a fairly straightforward task. 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.
So, I don't see this as that troublesome. As above, the bandwidth
issue can be dealt with by draft-ietf-tls-cached-info.

In summary, I don't see a lot of use for this extension. However,
if there is real demand for it, the right approach would be to
resurrect draft-ietf-tls-cached-info and add a new cache type
for the EE public key.

OTHER COMMENTS
What's the reason why you would want to send the server the
SPKI instead of the hash?

         opaque SHA256Hash<32>;

You probably want [32] here.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 27 Jul 2011 16:14:40 -0400 (EDT)

On Mon, 25 Jul 2011, Eric Rescorla wrote:

Thank you for your review Eric.

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

The TLS client indicates that it has authenticated the key out of band,
not neccessarilly only when it cached it from a previous session. In
fact, the primary use case intended here is out of band public key
validation.  Reusing a cached key is just a bonus effect of the more
modular authentication mechanism.

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

> server's credentials are already phrased as PKIX credentials

This is part of the current problem we are trying to solve. Currently,
there is no choice but to wrap the TLS Server public key into a PKIX
container that necessitates specifying certain information that can
be problematic for some reasons:

- Conflicts with the actual TLS client authentication scheme
- PKIX mandated data that cannot be processed by the TLS client for non-PKIX
   authentication.

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)

> client can validatte them however it wishes

While that is true, it is a weak argument for necessitating sending cruft
in the TLS protocol forever after.

I would say especially so, since this TLS extension is a pretty trivial change,
both in specification and implementation. Especially on the TLS server side.

Additionally, asking to send PKIX freeform data inside a crypto protocol does
make me nervous from a security point of view. We've seen issues in the past of
PKIX certificates with mangled data and pre-image attacks by using various PKIX
fields.

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.

> TLS stacks already have X.509 parsing,

That might be considered a security problem instead of an asset.

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

> SPKI instead of the hash?

Originally, we put it in as SPKI because we were envisioning that the TLS
server could just respond with the extension containing an empty list, as
the client already has knows (and authenticated) the public key out of band,
and we wanted at least one full copy of the TLS server key covered by the
Finished Message. In response to talking to some people, it was deemed more
orthogonal to the current TLS protocol to have the TLS server send a copy
of its public key (as it does so in the regular PKIX case inside the container)

With the TLS server sending the full public key, we can indeed remove it from
the TLS client side.

> You probably want [32] here.

Thanks. I've updated it in my copy.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Jul 2011 16:46:16 -0400

> The TLS server never omits sending its public key. It only omits sending

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?

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

> container has been properly validated with a non-PKIX method (eg DANE)

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

> need an ASN.1 parser anymore if the TLS server supports this new TLS

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.

> 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

---

From: Paul Wouters <[email-masked]>
Date: Wed, 27 Jul 2011 17:14:20 -0400 (EDT)

On Wed, 27 Jul 2011, Eric Rescorla wrote:

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

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

> 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 :)

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Jul 2011 17:36:39 -0400

> who wish to remain using horses.

For some reason this argument is not exactly convincing.

> 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

---

From: Paul Wouters <[email-masked]>
Date: Wed, 27 Jul 2011 20:18:05 -0400 (EDT)

> For some reason this argument is not exactly convincing.

Funny, this exact topic came up today at the Privacy Enhancing Technology
conference in Waterloo today (that I'm sadly missing because it conflicted
with IETF).

Do you trust Peter Gutmann's research more?

http://www.nspw.org/papers/2006/nspw2006-gutmann.pdf

Dealing with X.509 is hard, even for CS people. It might not seem logical
to you or anyone else skilled enough to participate with the IETF,
but it is true nonetheless.

> duplicative of cached info (and in fact, rather clumsier).

I'm interested in knowing why you consider it "clumsy". Especially because
it closely follows the RFC 6066 section 6 extension for supressing of
sending CA bundles with "trusted_ca_keys".  That apparent clumsiness
passed WGLC and IESG.

This extension basically lets the client say "I have trust for this
key, no need to send it in PKIX" and the server to simply suppress that
message. It's not like this is something complicated as writing up some
80's container format from hell, add an arbitrary inception and expiry
date, some magical key purpose bits that will not get used, property
bits to be ignored, and some made up conflicting identity for us to
later ignore and then grab all of that and wrap it up by signing itself.

Seriously, what is "clumsy" is saying "Just make up some unvalidatable
data for the PKIX container and then have the client ignore it later".

> Is there something here that couldn't be accomplished

You mean apart from dragging in less then just the subjectPublicKeyInfo
from ASN.1?  Yes we could use a side effect of "caching" or
"trusted_ca_keys", though they "MAY" would force every new TLS client
to still drag in all of PKIX.

I see value in a clear and unambiguous method for a TLS client to say
"I am not going to use PKIX validation - do not send me PKIX".

As for your 99.99999% figure - if you don't have a technical method to opt out
of PKIX validation, then sure, 99.9999% of TLS in 20 years will use PKIX. But
it would not proof your point. instead, you would made it happen. I for one hope
to see that in 20 years people can just use a "generate key" and "generate TLSA"
command, and put that in their DNS zone - even without a CS PHD.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Jul 2011 09:20:17 -0400

> sending CA bundles with "trusted_ca_keys".  That apparent clumsiness

What's clumsy is:

(1) It's not generic, even though generic caching is useful.
(2) It doesn't support bare keys when the client doesn't know the key, which
is also useful, if you want to use bare keys at all. In fact, it
doesn't even appear
to support cases where the client knows only the key hash, which is common.

Whether it follows 6066 doesn't seem particularly relevant here, since we have a
worked example of something better.

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Thu, 28 Jul 2011 10:06:30 -0400 (EDT)

> (1) It's not generic, even though generic caching is useful.

1) It's generic for allowing an arbitrary authentication method outside PKIX, which
    generic caching does not, as it requires the TLS client to compute hashes over
    PKIX information. In fact, the TLS client has to lie about already having the CA
    bundle in order not to receive the PKIX blob.

2) generic caching is useful and it should also proceed through the IETF process.

> to support cases where the client knows only the key hash, which is common.

That is a use case I had not considered. It is not hard to add support for that.

> worked example of something better.

"something better" only works with your other assumption of "sending and signing
cruft in PKIX is fine". I strongly disagree with that.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Jul 2011 10:13:09 -0400

>   bundle in order not to receive the PKIX blob.

As I said, you should *extend* cached-info.

> cruft in PKIX is fine". I strongly disagree with that.

I'm talking about cached-info here.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Thu, 28 Jul 2011 18:58:51 +0200 (MEST)

Paul Wouters wrote:
> Eric Rescorla wrote:

To be fair, the trusted_ca_keys extension was originally proposed
in rfc3546, and the document update 6066 simply did not change it.

The trusted_ca_keys TLS extension itself is a simple/lightweight extension
in that it does _not_ modify the syntax or semantics of any other
TLS handshake messages (besides the TLS extensions container in
ClientHello and ServerHello).

> 1) It's generic for allowing an arbitrary authentication method
>    outside PKIX, which generic caching does not, as it requires
>    the TLS client to compute hashes over PKIX information.
>    In fact, the TLS client has to lie about already having the CA

In TLS WG we definitely need to keep an eye on TLS extension not
duplicating each other resulting in conflicts an interop problems.

The TLS WG had previously adopted a work item (currently dormant,
primarily because of fights over hash algorithm agility that haven't
been settled) to do caching in a generic fashion, so caching
of data from TLS handshake messages, and in particular _existing_
TLS handshake messages should IMO not be duplicated in any newly
proposed TLS extension.

> 
> "something better" only works with your other assumption of "sending
> and signing cruft in PKIX is fine". I strongly disagree with that.

You seem to be thinking purely about a niche area

  1) that does not have TLS at all today
  2) where you want to implement TLS newly from scratch and having
     to implement _all_ of ASN.1-ladden PKIX as a huge burden
  3) and where you do not care the slighest about interop with the
     installed base of TLS.

But in case that interop with the installed base of TLS is or may
ever become an issue, it might be worthwile thinking about implementing
the subset "X.509v1 self-signed cert" as an alternative to inventing
a new bare key format, because that is still fairly trivial to
implement and fully interoperable with the existing installed base
(OK, newer browsers have a braindead nag-ware warning page, but
 I haven't lost hope yet that they grok it one day and offer sensible
 cert pinning -- and having to regularly update bug-ridden web browsers
 is a sad fact of life we've all become used to, it's not nearly as bad
 with TLS implementations used by programmatic TLS clients and servers).

I see not having to modify syntax and semantics of existing TLS handshake
messages in order to implement a TLS extension as a big plus.

-Martin

---

From: Paul Wouters <[email-masked]>
Date: Thu, 28 Jul 2011 14:01:38 -0400 (EDT)

> ClientHello and ServerHello).

trusted_ca_keys changes sending the CA bundle with EE-cert PKIX blob with
only the EE-cert PKIX blob. I am proposing to send only the subjectPublicKeyInfo
PKIx blob. It's not different a change of semantics.

> duplicating each other resulting in conflicts an interop problems.

Hency my method that is suitable not just for DANE, but for any non-PKIX
out of band authentication.

> TLS handshake messages should IMO not be duplicated in any newly

cached PKIX objects is quite different from not using PKIX.

Currently in saag there was also the interesting point of PKIX needing
to send duplicate certs in the CA bundle for SHA1/SHA2/SHA3 because you
don't know what hashing algo the TLS client can support. The non-PKIX
authentication of the TLS server public key could just publish different
DANE records with the different hashes of the public key, and the TLS
client can pick the one it supports. Please don't suggest that it is
perfectly reasonable to keep mandating ever larger PKIX containers that
are just scrap around the public key.

>  3) and where you do not care the slighest about interop with the

Not at all. I am also thinking of a browser supporting non-pkix alongside
pkix authentication.

> it might be worthwile thinking about implementing

We've been carrying PKIX containers for too long already.  Suggestions we
continue to do so for another twenty years are simply not good enough
in my opinion. I know not everyone agrees with me, and I'm not asking people
to switch. I'm just asking for the opportunity for everyone to make their
own decision on using PKIX or not.

> with TLS implementations used by programmatic TLS clients and servers).

I'm not sure how this paragraph supports cached pkix objects over non-pkix.

> messages in order to implement a TLS extension as a big plus.

See the start of this email and the comparison with trusted_ca_keys.

We are not forcing TLS servers to change anything like a requirement
to support TLS version 1.42. We suggest giving TLS implementations the
*option* to implement a non-PKIX extension. cached-objects is not good
enough for this case.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 28 Jul 2011 14:19:32 -0400 (EDT)

> As I said, you should *extend* cached-info.

Note that it was you told me in Prague you found it important that the TLS
public key remained transfered and covered by the Finished Message. Using
a cached object would only have the hash of the object to be covered by
the Finished Message.

Would you have no objection to a scheme using cached-info and that would trust
a public key that has never been transferred in-band?

Paul

---

From: Martin Rex <[email-masked]>
Date: Thu, 28 Jul 2011 21:50:39 +0200 (MEST)

Paul Wouters wrote:
> trusted_ca_keys changes sending the CA bundle with EE-cert PKIX blob
> with only the EE-cert PKIX blob. I am proposing to send only the
> subjectPublicKeyInfo PKIx blob. It's not different a change of semantics.
> 

I do not know what you're looking at, by _my_ copies of rfc6066 and
predecessors 4366,3546 are crystal clear, there is *NO* change of syntax
and semantics of any other TLS handshake messages, like e.g. the server's
Certificate handshake message, so I fail to understand what you mean.

There are no such things as CA bundles or PKIX blobs either, btw. 

The trusted_ca_keys TLS extensions does support more data types to
identify acceptable CAs than the certificate_authorities list
in the original CertificateRequest handshake message, however,
but "cert" is not supported by either.  You might be confusing
"CA cert" with "distinguished name of CA".

> cached PKIX objects is quite different from not using PKIX.

The design of the TLS caching extension is not strictly limited
to PKIX-related data.  But since PKIX-related data is the largest
static data in current TLS handshakes, these data elements are
the ones described in the currently dormant WG document.

> don't know what hashing algo the TLS client can support.

That affects only folks who want to perform academic exercises.

For TLS, the use of SHA-1 is pretty pervasive and going to continue
just like that for at least the next 5 years.  Having to maintain multiple
alternative server certificate would currently be a waste of admin and
helpdesk resources, if the server software supports it at all.

I'm not actually aware of TLS clients or servers that implement and use
the TLS extension trusted_ca_keys and personally, and I do not consider
that extension generally useful.  TLS clients that come with
50+ independent trust anchors preloded will hardly want to use that
extension.

> The non-PKIX

Or you could just wrap that server's public key in an X.509v1 self-signed
cert and use it with pretty much any existing TLS client and TLS server
software in the installed base.   :)

> Not at all. I am also thinking of a browser supporting non-pkix alongside

If we were still in year 1995 and the installed base of TLS software
was still insignificant, I might believe that TLS with bare public
keys might have uses.  SSH worked with bare keys back then and
succeeded.  But we're in 2011 now.  I believe support for X.509
(and other authentication schemes) were added to SSH.
But personally, I just fail to see a use case for adding raw
key support to TLS that I could not simply solve with
self-signed X.509v1 certs and existing TLS software in the
installed base, even 10+ year old TLS software.

Implementing support for self-signed X.509v1 (and JUST THAT) from scratch
is probably _a_magnitude_ easier and faster than writing a specification
for doing TLS with raw keys, working it through standardization and
getting others to implement it.

I can perfectly understand that you do not want to implement
entire PKIX (rfc5280) from scratch, because that would really be
an exhausting multi-year battle.

> own decision on using PKIX or not.

Admittedly, PKIX is bad, really really bad.  But managing raw keys
is _not_ better than a self-signed X.509v1 subset of PKIX,
and I'm not aware of a suitable replacement for PKIX so far.

And standardizing more ways to skin a cat may cause more harm than good
and should be done lightheartedly.

(recently mentioned on the IETF list:)
  http://www.xkcd.com/927/

> *option* to implement a non-PKIX extension. cached-objects is not good

I don't mind adding TLS extensions that can be safely ignored and
don't affect syntax&semantics of other TLS handshake messages and
further evolution of the protocl.

But I'm slighty worried about changing syntax or semantics of
existing TLS handshake messages, because such changes scale very
badly (every future change must address and fully specify the situation
for all existing variants and their combinations).

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 28 Jul 2011 23:42:25 +0200

On 07/28/2011 08:01 PM, Paul Wouters wrote:

>> The trusted_ca_keys TLS extension itself is a simple/lightweight 
>> extension in that it does _not_ modify the syntax or semantics of 
>> any other TLS handshake messages (besides the TLS extensions 
>> container in ClientHello and ServerHello).
> Hency my method that is suitable not just for DANE, but for any 
> non-PKIX out of band authentication.

I see two use-cases here. One is to be able to send raw public keys
(whether a certificate has been communicated out-of-band seems pretty
irrelevant), and the other to reduce bandwidth and (possibly
round-trips) by not sending any certificates, either because they have
been cached or because they are obtained out-of-band.

I think of those of two distinct issues, but before going and
solving them check whether it is worth the effort.
draft-ietf-tls-cached-info tried to solve the bandwidth
problem, but as far as I know it has never been implemented.

The other goal of yours of sending raw public keys might as
well be solved by defining a new certificate type RAW in the
certificateType registry defined in RFC6091 and send anything you like
in the "Certificate" message. You don't need WG consensus to do that.
But do you really have a use case that makes all that effort
worthwhile? Why would others be interested into implementing
the RAW keys you are proposing?

regards,
Nikos