Re: [dane] tls oob vs tlsa 11x

[Viktor Dukhovni <[e-mail]>]

On Wed, Jun 04, 2014 at 03:48:36AM -0400, James Cloos wrote:

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

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.

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

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

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

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.