> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > John Gilmore > Sent: Wednesday, April 17, 2013 1:22 AM > To: [email protected]; [email protected] > Subject: Re: [dane] Certificate usage 2 and TLS server certificate_list? > > > 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.
Three things: 1. Yes the intent of the paragraph is to allow implementations to refuse to accept an arbitrary trust anchor that does not meet their security requirements. While one can construe this as saying that they do not approve of the record that is not quite the same thing. Just because a spammer or a phisher is willing to actually have a domain and to use DNSSEC does not mean that I should accept them as being a trusted entity because they have a TA published in their TLSA records. That is a local policy decision that should be made. While for most people they would willing accept any TA published, just as they are willing to press the OK button in the trust this dialog, that is not true for everybody. 2. I don't know who else was pushing for this, but I know that I was one of the major people doing so. I have no stake in any CA company and therefore the reasons that you are implying that I have are completely incorrect. 3. I guess one can always "disapprove" of the use of any standard part of an RFC. However if it is required to be implemented and you do not implement it then do no say that you have complied with the RFC. Jim > > > 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 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
