On Thu, Jul 24, 2014 at 04:13:19PM -0400, James Cloos wrote:
> >>>>> "VD" == Viktor Dukhovni <[email protected]> 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.
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.
> 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/.
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.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
