On Wed, Apr 17, 2013 at 01:21:33AM -0700, John Gilmore wrote:
> > I am writing a client that needs to know whether certificate usage
> > "2" TLSA RRs are "usable". Failure to authenticate peer SMTP
> > servers and delayed email will not do anyone much good. The idea
> > is to promote DANE and DNSSEC adoption not give both a bad name.
>
> Yes, certificate usage "2" TLSA RR's are "usable". You or I may
> think usage 2 is a bad idea, but it is in the spec and it is defined
> to work.
I don't think usage "2" is a bad idea, I am trying to *implement*
it after all. I've implemented "2 0 0" and "2 1 0", with "2 1 0"
implemented as "signed by" rather than "issued (and signed) by",
since with "2 1 0" I don't have the certificate in hand.
> The spec does not require you to parse and reject combinations of
> usage 2 that use digests. All combinations of the usage, selector
> and match fields are valid.
Validity is not a synonym for interoperability, my commitment to
Postfix users is not deliberately expose them to non-interoperable
protocol features.
> But you, Viktor, can invoke it to
> disapprove of usage 2 records, for any reason or for no reason. You
> can disapprove of usage 1 or 0 records as well, if you like.
And I've already volunteered that my implementation does by default
treat "0 0 [12]" and "0 1 [12]" as unusable in the perfectly ordinary
sense that it is not possible to use it without routinely failing
*even when both sides are configured correctly*.
> > If I can't then usage 2 digests are "unusable". Shipping code that
> > makes mail delivery fail to RFC conformant peers is not particularly
> > attractive.
>
> An earlier message from you seemed to indicate that you were building
> a configuration option into your mail transfer agent that defaults to
> "don't include code that supports usage 2". That looks like a much
> better way to "make mail delivery fail to RFC conformant peers" than
> the case that you have a bee in your bonnet about.
When I treat matching type digest TLSA RRs with certificate usage
"0" (or if the user so chooses "2") "unusable" the result is not
mail delivery failure, it is rather mail delivery success, because
the sending MTA will use TLS without enforcing SMTP server
authentication. Enforcing authentication when it is highly likely
to fail may be what you want, in which case you can deploy Postfix
and configure it to use "0 0 [12]" and "0 1 [12]" TLSA RRs, perhaps
if you install the right set of trusted CAs you'll be lucky enough
to not delay or bounce too much mail.
> I'm a bit confused by your vehemence on this point. Suppose a mail
> server operator publishes a TLSA record that isn't usage type 2, but
> which includes or hashes a cert or public key that doesn't match what
> the mail server actually uses for its TLS handshake?
Or the server's CPU can't add properly, or replies "554" instead
of "250"... This line of reasoning is ludicrous.
We are discussing the behaviour of properly configured systems,
and asking whether *these* interoperate. If the specification
falls short of ensuring that properly configured systems interoperate,
some guidance or normative language is needed to ensure that the right
ingredients for interoperability become available.
> Why should one of these obvious, easily tested, easily corrected
> misconfigurations be called out as a MUST in the spec, while the
> others are not even mentioned?
Because they are obvious misconfigurations, but not sending the
root of a cert usage "2" chain when the TLSA RR is a digest is far
from obvious for most people. Sure it is obvious to most of us
now, we've discussed it to death, but it was substantially non
obvious at first reading, it is actually a subtle point that
is easy to get wrong.
> One is usage 2, with a selector of 1 and a matching type of 0, that
> is, usage 2 specifying a public key for the trust anchor, rather than
> a certificate. Does your code handle that combination?
Yes, by admitting chains signed by the TA public key. I don't know
whether the issuer of the top of the chain (whose public key I used
to verify the chain) is the same issuer as the one the TLSA RR had
in mind, but both have the same key pair, and the association is
for a key not a certificate, so I am content to check for "signed by".
> Suppose the TLSA specifies public key ABC, and the server sends a
> cert chain like this:
>
> site cert, signed by key LMNOP.
> LMNOP cert, signed by key ABC.
>
> I believe your code should see that chain as valid.
It does.
> It never sees a "certificate" for the trust anchor, but trust anchors
> don't need a certificate.
Yes, though 5280 PKIX requires a bit more than a key:
> And in section 6.1.1, "Inputs" (to the path validation algorithm):
>
> (d) trust anchor information, describing a CA that serves as a
> trust anchor for the certification path. The trust anchor
> information includes:
>
> (1) the trusted issuer name,
>
> (2) the trusted public key algorithm,
>
> (3) the trusted public key, and
>
> (4) optionally, the trusted public key parameters associated
> with the public key.
>
> A TLSA record with usage 2 and containing a full public key supplies
> all this information to define a trust anchor. (The "trusted issuer
> name" can be synthesized as "example.com TLSA record", or anything
> similar, since its contents do not affect the validation algorithm.)
Actually, not quite "all", that was another question I asked upstream
about "signed by" vs. "issued by". An "IN TLSA 2 1 0" RR gives me
(2), (3), and (4) but not (1), so I can't determine "issued by" if
hypothetically multiple CAs use the same key pair, but I am not
overly concerned about such CA key abuse.
> In a second useful edge case, suppose the TLSA usage 2 record
> specifies either public key ABC, or its hash, and the server sends a
> cert chain like this:
>
> site cert, signed by key LMNOP.
> LMNOP cert, signed by key ABC.
> ABC cert, signed by key FUBAR.
> FUBAR cert, signed by key CATRUSTANCHOR.
>
> In this case, the TLSA record has identified an intermediate
> certificate in the TLS server's chain as its trust anchor.
> This should work, and require no change to the TLS server.
The server sent the TA certificate conforming to the language I
suggested for erratum. Yes, this is no change from its behaviour,
and that's OK too.
> It is even useful.
It is even required, since only the topmost cert in the chain is
optional with pre-DANE PKI.
> It means that even if the keys FUBAR or CATRUSTANCHOR become
> untrusted or invalid, the site cert should be accepted anyway, as long
> as it is signed by the LMNOP cert, because the LMNOP cert is signed by
> the TLSA-specified trust anchor.
And now that I am (perhaps incorrectly) lead to believe that some
appropriate (be operational guidance or normative) text will be
added to 6698 or related documents Postfix has been changed to
support "2 x [12]" by default, including this case.
> Meanwhile, non-DANE clients will
> validate the site cert via the CATRUSTANCHOR public key that came
> embedded in the TLS client (from Microsoft or Thawte or somebody like
> that). This looks valid to me. Does your code implement it?
Yes. Feel free to try it out if that's not too much of a burden.
What's not supported (with default settings) is:
IN TLSA 0 ? 1 -> "unusable" with fallback to mandatory unauthenticated TLS.
IN TLSA 0 ? 2 -> "unusable" with fallback to mandatory unauthenticated TLS.
What's implemented in a partly conformant manner is:
IN TLSA 1 ? ? -> no attempt made to chain to PKIX root, "1" treated as "3".
What's implemented in a manner not conformant with the SRV and SMTP drafts is
the treatment of CNAMEs. Postfix will always expand the CNAME (recursively
up to ~10 deep, failing if depth exceeded) and will look for TLSA RRs at the
target not the query host,
; Illegal since MX RRs are required to not be CNAMEs
;
example.com. IN MX 0 mail.example.com.
mail.example.com. IN CNAME mail.example.net.
; Postfix TLSA query domain:
;
_25._tcp.mail.example.net. IN TLSA ?
Likewise for non-MX destinations:
; RFC 5321 supports mail addresses of the form user@domain even
; when host is a CNAME, and it could be a CNAME for a non-MX host.
;
example.com. IN CNAME mail.example.net.
; Postfix TLSA query domain:
;
_25._tcp.mail.example.net. IN TLSA ?
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
