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

[Paul Wouters <[e-mail]>]

On Wed, 27 Jul 2011, Eric Rescorla wrote:

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

> Regardless, as I said in my review, this seems like it's largely
> 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
> by a SPKI cache type in cached-info?

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