> 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.
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.
The spec also does not require TLS servers to send any particular
certificates. RFC 6698 does not require TLS servers to do ANYTHING.
In fact, its Abstract says "This requires matching improvements in TLS
client software, but no change in TLS server software." Making any
such changes would be within the realm of the TLS working group, not
our WG.)
However, there is a weasel-word paragraph inserted into the RFC in
section 8, over my opposition, which says:
Generators of TLSA records should be aware that the client's full
trust of a certificate association retrieved from a TLSA record may
be a matter of local policy. While such trust is limited to the
specific domain name, protocol, and port for which the TLSA query
was made, local policy may decline to accept the certificate (for
reasons such as weak cryptography), as is also the case with PKIX
trust anchors.
The intent of this paragraph was to allow implementations to refuse to
interoperate with particular TLSA records that they do not approve of.
The author of the paragraph appeared to disapprove of usage 3 records
because they bypass the CA system, which he had a financial incentive
to prevent the bypassing of. 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. I argued
at the time that this paragraph makes a mockery of interoperability,
but it remained in the document. So, feel free to make your
implementation fail to interoperate by defining "local policy" as
refusing to implement usage 2 because you got up on the wrong side of
bed today; it's all within the RFC.
> 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.
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? Then mail
delivery will fail. Suppose they supply an MX record that points to a
nonexistent host? Then mail delivery will fail. Suppose the host
exists, but not at the address in its A record? Then mail delivery
will fail. Suppose an operator publishes a TLSA record with usage
type 2, which includes a hash of a certificate that is not within
either the cert chain sent by the mail server, nor the trust anchor
set available to the client? Then mail delivery will fail. 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?
This discussion HAS brought up an couple of interesting edge cases,
though.
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? 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 never sees a
"certificate" for the trust anchor, but trust anchors don't need a
certificate. A TLS implementation can store its trust anchors any way
it wants to -- it is not required to use certificates for them. As
RFC 5280 says in section 6.2, "Using the Path Validation Algorithm":
The path validation algorithm presented in Section 6.1 does not
assume that trust anchor information is provided in self-signed
certificates and does not specify processing rules for additional
information included in such certificates.
And in section 6.1:
The primary goal of path validation is to verify the binding between
a subject distinguished name or a subject alternative name and
subject public key, as represented in the target certificate, based
on THE PUBLIC KEY OF the trust anchor. [emphasis added]
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.)
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. It is even
useful. 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. 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?
John
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
