On Sat, Apr 20, 2013 at 07:51:23AM -0700, Paul Hoffman wrote:
> > Observation: If server does not want the client to fail, include
> > the TA cert in the chain A, B, C, D (assuming, for example, that
> > D is the missing TA certificate that signed C).
>
> Yes. And there are probably other valuable operational considerations
> that are not in RFC 6698 that you and others are discovering as
> well. These should be captured in an RFC that updates RFC 6698.
> That way, future developers and implementers can find them in a
> widely-distributed and stable document series.
Since my goal is not IETF politics, but rather an attempt to help
would be users who deploy server-side DANE achieve interoperability
with my implementation, I don't really have a prior bias on the
form in which my experience is disseminated.
Since RFCs don't change once published, and errata are rarely read,
though getting an erratum adopted would be a moral victory, and I
think even a legitimate "bug fix" to 6698, it likely would not
address my goal.
So a separate document needs to be published either way. So far
the totality of what I have to share is:
- The already discussed to death server requirements for usage 2 digests.
- Client requirement for usage 0 digests (willingness to fail with
servers whose root CA cert is not on hand). If the client does not
expect to have a sufficiently complete set of trusted root CAs, it
may need to treat usage 0 digest TLSA RRs as "unusable" in order
to avoid failing.
Thus with SMTP, with no user to click OK, and no history of
requiring a "complete" set of CAs, "IN TLSA 0 0 1" and "IN
TLSA 0 0 2" (and their public key variants) should by default
be treated as "unusable", with the choice to enable these
left to the user (SMTP client administrator).
- Client processing of "IN TLSA 2 1 0" full public keys in DNS.
Here the client can't actually fully conform to RFC 5280
PKIX, since DNS only provides a TA public key and parameters,
with no TA "name" (DN, or any other kind). Since the client
will often not have the full TA certificate on hand, if the
server operator does not provide the TA certificate in the
chain, the client needs to check whether the top of the server
chain is "signed by" the TA from DNS, it cannot build verify
whether the chain is "issued by" "the TA", since the DNS
specifies only an equivalence-class of TAs that share the
same public key, presumably some member of that class issued
the chain (and with CA best practice ideally the class has
at most one member).
- Futility of usages "0" and "1" with DNS indirection. When
the base domain of the TLSA server is obtained from DNS (e.g.
via MX or SRV records), the additional protection that some
seek from successful attacks on DNSSEC by also performing
PKIX validation is not available. Once DNSSEC is compromised,
the attacker can freely serve forged SRV or MX records, and
thus freely chosen associated TLSA RRs. [I would like to see a
substantive comment on this from Tony Finch].
Therefore, applications such as SMTP, that are completely at
the mercy of DNSSEC, as they rely on MX or SRV RRs to construct
the TLSA base domain, may reasonably choose to avoid the
PKIX validation requirements for usages 0 and 1. For "1 x y",
the application may choose to simply treat the TLSA RR as "3 x y",
with no loss in security. Likewise for "0 x 0" (full certificate
or public key in DNS). For "0 x [12]", per the previous comment,
the application may need to treat the TLSA RR as "unusable".
- Leveraging CNAME indirection to simplify key management in virtual
hosting environments. Use CNAME target domain as the base domain
for TLSA lookups. Avoid requirement for domain owners and server
operators to resort to SNI. (Clients must still send SNI since
the server operator may be using SNI to support TLS certificate
selection even sans CNAME RRs). Servers don't have to implement
SNI, they may choose to only support a single TLS server name.
(CNAMEs are illegal in SRV and MX RRs, and clients should either
fail or securely chase the CNAME to obtain the TLSA base domain).
- A description of an implementation of DANE with no changes to
OpenSSL, just a verification callback.
Would these all be one draft? Are there are other implementors on this
list, and do they have additional material to contribute?
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
