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

[Paul Wouters <[e-mail]>]

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.

> In TLS WG we definitely need to keep an eye on TLS extension not
> 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.

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

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.

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

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

> (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'm not sure how this paragraph supports cached pkix objects over non-pkix.

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

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