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

[Martin Rex <[e-mail]>]

Paul Wouters wrote:
> 
> Eric Rescorla wrote:
> 
> >> 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.

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


>
> > What's clumsy is:
> >
> > (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.

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