Subject: [dane] on tlsa for rfc 7250

From: James Cloos <[email-masked]>
Date: Wed, 23 Jul 2014 15:42:28 -0400

Thinking about 7250, I'm becoming convinced that we should recommend
that anyone publishing tlsa, whose software might have or gain support
for 7250, or might be accessed by clients which can support 7250, SHOULD
publish a 31x for them, in addition to any non-31x tlsa they publish.

Ie, those who prefer 0, 1 or 2 should publish both, for the benefit of
any 7250 clients which might access them.

Thoughts?

I also remain conviced that, per liberal in what you accept, any 7250
client should accept a 11x just as though it were a 31x, since the
association data is identical.

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 24 Jul 2014 00:37:32 +0000

On Wed, Jul 23, 2014 at 03:42:28PM -0400, James Cloos wrote:

> that anyone publishing TLSA, whose software might have or gain support

That is, publish "DANE-EE(3) SPKI(1) ? {blob}" associations for
the public keys in any extant certificates, so as to allow the
corresponding bare public keys to be used without the surrounding
X.509 baggage later.  If the protocol is in fact TLS (in which case
the full keys are exchanged in-band), the matching type SHOULD
typically be a digest, though for some algorithms (say EC curve
25519 keys), the key size is comparable to the size of its SHA2-256
digest.

However, once "3 1 x" records are published, there is little point
in publishing any other type of record.  So I am not sure about
the "in addition to" bit.  Rather I would suggest "instead of".

> any 7250 clients which might access them.

The cost of publishing "3 1 x" is that the server operator needs to
update DNS when keys change, while with DANE-TA(2), a CNAME to the
TA TLSA record can be published for each service, and the task
of DNS updates is left to the organization's TA administrator.

Once the cost burden (on each server operator) of updating "3 1 x"
records is present already, also publishing "2 1 X" just makes
things needlessly complex.  There is no point.

> Thoughts?

I think that in most cases DANE users will publish either "3 1 X"
or "3 0 X".  With 7250 in mind, they should be encouraged to
publish "3 1 X" and avoid "3 0 X".

> association data is identical.

This is what Postfix does, but is not what the SMTP draft says.
I was dissuaded from formalizing such creative interpretation of
TLSA RRs.  If the publisher wants PKIX then the service should not
agree to RPK (raw public keys) use and the client should be free
to either do PKIX or treat the record as unusable,  or at least
that's all the server operator can expect.  Clients might be more
lenient, but no standard will require them to do it.

If the group believes that Postel's rule applies here, and that
non-PKIX clients SHOULD always be willing to treat PKIX-EE(1) as
DANE-EE(3), then we SHOULD add that to the text the OPS draft, and
update the SMTP draft accordingly.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Thu, 24 Jul 2014 16:13:19 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD> However, once "3 1 x" records are published, there is little point
VD> in publishing any other type of record.  So I am not sure about
VD> the "in addition to" bit.  Rather I would suggest "instead of".

The idea is that some seem to so wedded to pkix that they feel that they
MUST publish 0 or 1 if they publish tlsa at all.

(I obviously don't agree with that sentiment; and there is the
possiblity that those who do lost interest here and it may not ever be
an issue???)

Publish both is directed at them, to ease interoperability with any 7250
clients.

VD> Once the cost burden (on each server operator) of updating "3 1 x"
VD> records is present already, also publishing "2 1 X" just makes
VD> things needlessly complex.  There is no point.

I considered that issue even though I didn't call it out.  You're
right that it may lead type 2 users to choose between easy updates
and supporting 7250 clients.

That is part of why I'm only 'becoming convinced'.

VD> If the group believes that Postel's rule applies here, and that
VD> non-PKIX clients SHOULD always be willing to treat PKIX-EE(1) as
VD> DANE-EE(3), then we SHOULD add that to the text the OPS draft, and
VD> update the SMTP draft accordingly.

Postel's rule goes without writing; even when it isn't mentioned in
(potential) standards it remains proper for code to implment it.
But I would prefer to see it mentioned in the documents.

For a one-way authenticated sockect like tls often is, if the client can
create a trust path which /it/ likes, the server's pref doesn't matter.

Similarly, when the server authenticates the client, it is only the
server's choices about trust paths et alia which should matter to /it/.

-JimC

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 24 Jul 2014 22:57:24 +0000

> MUST publish 0 or 1 if they publish tlsa at all.

Once they stoop to publishing "3 1 x", the've accepted lack of
PKIX, with one caveat, the recommendation in the OPS draft to
support either only PKIX or only non-PKIX DANE usages is a
recommendation primarily for the *client*.  If a server supports
both PKIX-loving clients and PKIX-hating clients, then it can
reasonably publish mixed TLSA RRsets, with each type of client
using only the RRs it supports.

A client that supports both, is maximally burdened (to have
comprehensive CA lists, ...) and minimally secured (by being
vulnerable to DNSSEC-only attacks).  So while the client should
rarely if ever support both PKIX and non-PKIX usages, servers can
in some cases straddle the two worlds when the application protocol
leaves the choice of security model to the each particular client.

In that case, servers that want to support all types of clients
might pay the operational cost to support both "3 1 X" and one
of the PKIX usages.

> server's choices about trust paths et alia which should matter to /it/.

Is this generally the WG's view?  IIRC Wes played a role in dissuading
me from recommending playing "fast and loose" with the server's RR
semantics, by down-grading PKIX-EE(1) to DANE-EE(3).  Note also
that one cannot in general downgrade PKIX-TA(0) to DANE-TA(2), and
this lack of symmetry might cause confusion.

The reason for not being able to map 0->2 is that PKIX root CAs
are optional in the server's handshake chain, while DANE TAs are
not.  So a non-PKIX client can't expect to succeed in validating
a PKIX-TA chain.  This is actually part of the reason I'm reluctant
to map 1->3, because it sets up false expectations of being able
to map 0->2 which can't be met reliably.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 24 Jul 2014 00:36:55 +0000

-- 
	Viktor.