Re: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd)

[Marsh Ray <[e-mail]>]

Question. This item:
> o  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

Is that behavior endorsed by current RFCs, or is server cert caching a
new optimization being enabled by this draft (perhaps in conjunction
with HSTS pinning)?

Seems like that topic could merit a whole nother RFC of its own. Maybe
reference that or drop it from here?

Clearly this document "specifies a new TLS certificate type for
exchanging raw public keys or their fingerprints in TLS and DTLS". But I
guess the deeper question is to what extent this draft intends to
endorse ad-hoc approaches to TLS authentication when it says "By
specifying a minimum resource for raw public key exchange,
implementations can use alternative authentication methods."

In the Security Considerations there is the statement "A client using
this cert_type needs to be confident in the authenticity of the public
key it is using." This is obviously correct, but is it worded strongly
enough?

For example, it's no secret that a great many non-browser TLS client
applications do not bother with cert validation or they fail to check
that the cert matches the host they requested. Often they allow plain IP
addresses in their configuration. Today we can say this is against
various RFCs, but if this draft were accepted perhaps such clients would
be able to simply request cert type RawPublicKey and say "yep, looks
good enough for me therefore I am RFC-compliant!"

This is an ongoing discussion that I encounter among users and app
developers on a regular basis. For example:
> http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2011-02/msg00650.html


On 11/17/2011 10:20 AM, Paul Wouters wrote:
>
> Though I see your point, I cannot really see any case where a TLS
> implementation would obtain a public key from DNS without any PKIX
> information and without any DNSSEC protection. In this case there is
>  not even the PKIX fallback information to go on, so regardless of
> what DANE decides to do for "validatable PKIX", a TLS client MUST
> NOT use a TLSA record containing just a public key if it did not
> authenticate that data with DNSSEC.
>
> Perhaps it can be reworded?

Perhaps you could use a different example such as:

* Certs obtained via LDAP (e.g. http://tools.ietf.org/html/rfc4523 )

* IPsec using X.509 certs http://tools.ietf.org/html/rfc4301

* Established SSH RSA keys (if this is actually well-defined)

Just some ideas.


> But I think it is a valid security concern to point out people
> should not just pluck spoofable TLSA records from DNS and build a TLS
> trust relationship based on that. Even if DANE decided to always
> mandata DNSSEC, I think it is a good reminder to make that explicit
> in the Security Considerations here?

I agree that it's worth repeating on principle, but I don't think it's
necessary to include more of an explanation of the full PKI security
model. Just a reference should do.

- Marsh