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

[Martin Rex <[e-mail]>]

Paul Wouters wrote:
> 
> On Thu, 28 Jul 2011, Martin Rex 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).
> 
> 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 see not having to modify syntax and semantics of existing TLS handshake
> > 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.

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


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


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

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

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


> 
> >> "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.
> 
> Not at all. I am also thinking of a browser supporting non-pkix alongside
> pkix authentication.


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.


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

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/


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

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