Subject: [dane] tls oob vs tlsa 11x

From: James Cloos <[email-masked]>
Date: Wed, 04 Jun 2014 03:48:36 -0400

I just occurred to me that, given that oob is negotiated bewteen the
client and the server, that the oob concept is !pkix, and any
verification of the spki is conceptually identical, a tlsa 11x is just
as usable by an oob client as a 31x is.

It does not matter than a typical full cert client would do a pkix
verification on top of the tlsa verification when the tlsa is 11x.
The oob client *and server* have agreed not to bother with pkix,
so any ee-spki association is sufficient to verify the offerred spki.

In other words, by agreeing to oob, the server gives the client consent
to ignore any pki details about the verification.

Only tlsa 0 and 2, which do not dirrectly reference the ee, are really
unusable in the oob case.

So the proper language probably is something like:

  End-Entity SPKI association

via dane, ldap, firmare or any other pre-agreed method.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Jun 2014 14:15:32 +0000

> as usable by an oob client as a 31x is.

This is a slippery slope.  In my original SMTP draft I had language
suggesting aumatic mapping PKIX-TA(0)->DANE-TA(2) and
PKIX-EE(1)->DANE-EE(3).  This was abandoned in favour of 0/1
undefined (likely "unusable") for SMTP and only 2/3 supported.

If the server operator wants PKIX checks, client-side overrides
should probably not be an RFC-defined behaviour.

Now it turns out that Postfix treats "0" as "unusable", but indeed
automatically maps "1" to "3", because as you observe "why not?".
However, I think such liberties should not be officially endorsed.

> so any ee-spki association is sufficient to verify the offerred spki.

It would be better for such servers to publish "311" and be done.

> via dane, ldap, firmare or any other pre-agreed method.

If the WG collectively agree that non-PKIX clients are free to map
PKIX-EE(1) to DANE-EE(3) and that server operators can expect this
behaviour, then we still have time to ammend the SMTP draft, to
say that PKIX-EE(1) may be published but SHALL be treated as though
it were DANE-EE(3) by SMTP clients.

My view at this juncture is that such mappings should not be
expected, and are a matter of client implementation discretion.
If a client views PKIX-EE(1)/SPKI(1) as though it were DANE-EE(3)/SPKI(1)
then, that client obviously won't see any "oob" obstacles from any
associated RRs (of course PKIX-EE(1)/Cert(0) is still a potential
problem, barring new constraints the records servers should publish).

-- 
	Viktor.

---

From: John Gilmore <[email-masked]>
Date: Thu, 05 Jun 2014 11:23:34 -0700

> I[t] just occurred to me that, given that oob is negotiated bewteen the

Yes, in theory, any TLSA x 1 y record could be used to authenticate a
raw public key.  (That is, any record whose selector is "public key"
as opposed to "cert".)

But rather than defining that clients should expect such things, I
think the WG should first define a canonical representation for a raw
public key in a TLSA record, and require that "raw public key" clients
MUST support that representation.  This, then, will tell domain name
administrators what record format to use in the normal course of
publishing raw public keys with servers in their domain.

Then, as a separate and probably harder question, we should decide
what additional TLSA record formats that clients MUST, SHOULD, MAY, or
MUST NOT support.

	John