Subject: [dane] Certificate usage 2 and TLS server certificate_list?

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 16 Apr 2013 14:52:27 +0000

On Mon, Apr 08, 2013 at 10:38:30PM +0000, Viktor Dukhovni wrote:

Does either RFC 6698, or draft-ietf-dane-srv mandate (or it is too
obvious to state in either standard) that:

  - Servers with "IN TLSA 2 x [12]" associations are obligated to include
    the full TA cert in their TLS "certificate_list".

  - It is correct to read "IN TLSA 2 1 0" as validating chains "signed by"
    (not known whether issued by) the TA, when the TA cert itself is not
    available in the peer's chain.  Or, per the previous question, is the
    TA cert is required, and the issue is moot.

Related Postfix documentation:

    http://vdukhovni.github.io/postfix/TLS_README.html#client_tls_dane

	..., the Postfix SMTP client does not assume that the remote
	SMTP server will necessarily be configured to present the certificate
	of any trusted CA in its TLS protocol certificate_list. Therefore,
	support for trust-anchor certificate and public-key digests is
	disabled by default, see tls_dane_trust_anchor_digest_enable for
	details. While undigested trust-anchor certificates in TLSA records
	are supported, publishing complete certificates in DNS is unwise given
	the resulting excessively large DNS record sizes.  Therefore, in its
	default configuration the Postfix SMTP client essentially supports
	only certificate usages "1" and "3" (with "1" treated as though it
	were "3").

    http://vdukhovni.github.io/postfix/postconf.5.html#tls_dane_trust_anchor_digest_enable

    tls_dane_trust_anchor_digest_enable (default: empty)

	RFC 6698 trust-anchor digest support in the Postfix TLS library.
	Specify zero or more of the following options, separated by comma or
	whitespace.  Option names are case-insensitive.

	ca-constraint
	    Enable support for RFC 6698 (DANE TLSA) DNS records that contain
	    digests of trust-anchors with certificate usage "0". These are
	    often public root CAs, and server operators may expect that
	    clients will have the corresponding root certificate in their
	    CAfile or CApath. Most SSL/TLS servers do not send public root CA
	    certificate in their certificate chain, so if Postfix does not
	    have the CA certificate locally, there is no way to associate the
	    digest with the trust chain from the server. These TLSA records
	    are fragile, and only work when you have a complete (whatever that
	    means) set of public CAs in your CAfile or CApath. Enable this
	    with caution if at all.

	trust-anchor-assertion
	    Enable support for RFC 6698 (DANE TLSA) DNS records that contain
	    digests of trust-anchors with certificate usage "2". In this case
	    the certificate usage should compel the server operator to
	    configure the server to include the trust-anchor certificate in
	    the server's SSL HELO certificate trust chain.  Problems are less
	    likely here, and most administrators choosing non-public CAs
	    should in any case publish TLSA records for leaf certificates
	    (certificate usage "3"). These TLSA records are somewhat less
	    fragile than "ca-constraint" TLSA records, but are also not
	    enabled by default. Having a complete CAfile or CApath may not
	    help in this case, you are at the mercy of the remote server
	    administrator's competence. Enable this with caution if at all.

-- 
 	Viktor.

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 16 Apr 2013 23:00:01 +0200

>    the full TA cert in their TLS "certificate_list".

I believe that is the case. RFC 6698 says: "The target certificate MUST pass PKIX certification path validation, with any certificate matching the TLSA record considered to be a trust anchor for this certification path validation." It is not possible to do path validation without having the full trust anchor certificate, thus the server needs to provide it in most cases. If it is not provided, and the client does not have its own copy, validation will fail.

>    TA cert is required, and the issue is moot.

Given that you need to do path validation, I believe the TA cert is required. In the case of "IN TLSA 2 1 x" or "IN TLSA 2 0 {1,2}, the server has to provide the certificate or the client has its own copy.

	jakob

-- 
Jakob Schlyter
Kirei AB - www.kirei.se

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 16 Apr 2013 22:21:15 +0000

On Tue, Apr 16, 2013 at 11:00:01PM +0200, Jakob Schlyter wrote:

> I believe that is the case. RFC 6698 says: "The target certificate
> MUST pass PKIX certification path validation, with any certificate
> matching the TLSA record considered to be a trust anchor for this
> certification path validation." It is not possible to do path
> validation without having the full trust anchor certificate, thus
> the server needs to provide it in most cases. If it is not provided,
> and the client does not have its own copy, validation will fail.

Thanks for responding, very much appreciated.  Somehow we're still
not talking the same language.  I understand and agree that the
logical consequence---when the certificate is not provided---is
that validation will generally fail.  What I don't see anywhere is
the statement in the specification that:

    - A server with "2 x [12]" TLSA RRs MUST therefore provide the
      certificate in question in its server certificate_list.

Is the server obligated to do this, or not?  Where is the normative
text?  Can I enable support for "2 x [12]" by default, or should
I expect to see a high failure rate if I do (with no explicit
support from the specification to compel the servers in questions
to provide the missing certificate)?

> Given that you need to do path validation, I believe the TA cert
> is required. In the case of "IN TLSA 2 1 x" or "IN TLSA 2 0 {1,2},
> the server has to provide the certificate or the client has its
> own copy.

I continue to be puzzled by the "or the client has its own copy".
The protocol has to work for all clients, not just some clients,
that happen to have their own copy.  That happenstance is not a
basis for interoperability of the specification.

Does 6698 certificate usage 2 require interoperable settings on
servers?  I don't see the language that states this.  Is it to
be inferred, or should it be explicit.

If I enable default support for "2 1 [12]" RRs in SMTP clients,
then this support will be on for *all* servers, and mail delivery
from Postfix SMTP clients will break to any SMTP servers that don't
provide the TA cert.  This would not be a good outcome for anyone.

I've submitted an erratum to the RFC editor, perhaps this will
resolve/clarify the issue.  With any luck I'll be able to ship
Postfix with support for all "2 x y" TLSA RRs enabled by default.

-- 
	Viktor.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 16 Apr 2013 15:50:23 -0700

Such a certificate could be pre-configured.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Viktor Dukhovni
> Sent: Tuesday, April 16, 2013 3:21 PM
> To: [email-masked]
> Subject: Re: [dane] Certificate usage 2 and TLS server certificate_list?
> 
> > validation without having the full trust anchor certificate, thus the
> > server needs to provide it in most cases. If it is not provided, and
> > the client does not have its own copy, validation will fail.
> 
> Thanks for responding, very much appreciated.  Somehow we're still not
> talking the same language.  I understand and agree that the logical
> consequence---when the certificate is not provided---is that validation
will
> generally fail.  What I don't see anywhere is the statement in the
specification
> that:
> Is the server obligated to do this, or not?  Where is the normative text?
Can I
> enable support for "2 x [12]" by default, or should I expect to see a high
> failure rate if I do (with no explicit support from the specification to
compel
> the servers in questions to provide the missing certificate)?
> 
> > Given that you need to do path validation, I believe the TA cert is
> > required. In the case of "IN TLSA 2 1 x" or "IN TLSA 2 0 {1,2}, the
> > server has to provide the certificate or the client has its own copy.
> 
> The protocol has to work for all clients, not just some clients, that
happen to
> have their own copy.  That happenstance is not a basis for
interoperability of
> the specification.
> 
> Does 6698 certificate usage 2 require interoperable settings on servers?
I
> don't see the language that states this.  Is it to be inferred, or should
it be
> explicit.
> 
> If I enable default support for "2 1 [12]" RRs in SMTP clients, then this
support
> will be on for *all* servers, and mail delivery from Postfix SMTP clients
will
> break to any SMTP servers that don't provide the TA cert.  This would not
be a
> good outcome for anyone.
resolve/clarify
> the issue.  With any luck I'll be able to ship Postfix with support for
all "2 x y"
> TLSA RRs enabled by default.
> 
> --
> 	Viktor.
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 16 Apr 2013 16:11:43 -0700

On Apr 16, 2013, at 2:00 PM, Jakob Schlyter <[email-masked]> wrote:

> I believe that is the case.

And your co-author strongly disagrees.

> RFC 6698 says: "The target certificate MUST pass PKIX certification path validation, with any certificate matching the TLSA record considered to be a trust anchor for this certification path validation."

Yes.

> It is not possible to do path validation without having the full trust anchor certificate,

Errr, why not? If the client has a certificate that says "the public key of the trust anchor that signed me is keyX", and you get keyX from TLSA, why do you need a full trust anchor certificate?

> thus the server needs to provide it in most cases. If it is not provided, and the client does not have its own copy, validation will fail.

Didn't the client just get it from TLSA? What am I missing here?

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 16 Apr 2013 23:19:30 +0000

> Such a certificate could be pre-configured.

I am reading this to mean that in some small-scale deployments,
where the set of clients is fully anticipated by the server operator,
there exists an opportunity to publish TLSA "2 x [12]" without the
TA cert in the server's chain, if all the clients are pre-configured
with a copy of the TA certificate.

This may to some extent be true, but it now obligates clients to
try to extend the server's chain with usage 2, which may be difficult
in implementations that only do chain extensions as part of PKIX
validation to a trusted root.  If the TA is present in the server's
chain, implementation of usage 2 verification is much more natural,
just locate the TA in the server's chain.  So even if the client
"could" in principle locate the missing certificate, it is not
clear that it should be required to try as this may not be easy
with at least some of the popular toolkits.

The simplest and most robust way to "pre-configure" the clients to
validate the server's chain even in our hypothetical small-scale
deployments is to include the trust anchor in the server's certificate
chain.  No other pre-configuration mechanism scales to the public
Internet, and the procotocol specified in 6698 is not restricted
to small-scale deployments.

I may yet enable "2 x [12]" verification by default, in the hope
that server operators will do the right thing despite lack of
normative language, but I am hoping that some helpful language will
be added to the RFC.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 16 Apr 2013 23:27:28 +0000

On Tue, Apr 16, 2013 at 04:11:43PM -0700, Paul Hoffman wrote:

[ The use-case under discussion is that the client gets a DIGEST
  of the TA certificate or public key from TLSA, not the actual
  certificate or public key. The digest alone cannot direct directly
  be used to validate any chains, since we can't check the TA signature
  given just a digest of its certificate or public key. ]

> > RFC 6698 says: "The target certificate MUST pass PKIX certification
> > path validation, with any certificate matching the TLSA record
> > considered to be a trust anchor for this certification path
> > validation."
> 
> Yes.
> 
> Errr, why not? If the client has a certificate that says "the
> public key of the trust anchor that signed me is keyX", and you
> get keyX from TLSA, why do you need a full trust anchor certificate?

You get a digest of KeyX or a certificate that contains keyX from
TLSA.  You don't get KeyX.  The client, by hypothesis receives an
incomplete chain:

	EE Server Certificate 0
	Some Issuer 1 (of 0)
	Some Issuer 2 (of 1)

The TA whose *digest* is in TLSA is "Some issuer 3 (of 2)" whose
certificate is not sent in the server chain.  How is the client
supposed to verify the chain?

> > thus the server needs to provide it in most cases. If it is
> > not provided, and the client does not have its own copy, validation
> > will fail.
> 

The client got a digest which could be compared to the TA certificate,
if only that certificate were on hand.  Otherwise the client is out of
luck.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 16 Apr 2013 16:42:24 -0700

On Apr 16, 2013, at 4:27 PM, Viktor Dukhovni <[email-masked]> wrote:

>  certificate or public key.

Sorry, I missed that. Jakob's answer threw me off track from the question.

> The digest alone cannot direct directly

Correct. But that still does not mean that the TLS server needs to send it.

> supposed to verify the chain?

As Jim points out, the client might already have it pre-loaded. If the client doesn't have it pre-loaded, the TLS handshake fails.

Getting the key or certificate from the TLS server would help, but it is not required for the scenario to work.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 16 Apr 2013 23:56:38 +0000

On Tue, Apr 16, 2013 at 04:42:24PM -0700, Paul Hoffman wrote:

> As Jim points out, the client might already have it pre-loaded.
> If the client doesn't have it pre-loaded, the TLS handshake fails.
> 
> Getting the key or certificate from the TLS server would help,
> but it is not required for the scenario to work.

Yes, some clients *might* have the certificate in hand, and *might*
be able to use it augment to augment the chain, and thus *might*
be able to use the TLSA association, but this is not a basis for
an interoperable protocol.

A client that uses DANE to authenticate servers per their TLSA RRs
or else fail must have some assurance that conformant servers can
be verified.

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.

Can I expect server operators to provide the TA certificate in the
TLS handshake server chain?  If so on what basis?  Their incisive
logical reasoning ability?

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.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 16 Apr 2013 17:24:50 -0700

On Apr 16, 2013, at 4:56 PM, Viktor Dukhovni <[email-masked]> wrote:

> be able to use the TLSA association,

How is this different than all of the "mights" in TLS?

> but this is not a basis for

Sure it is. There are plenty of things operators can do wrong, of course. What you are proposing is (perfectly reasonable) operator guidance, not a protocol requirement.

> or else fail must have some assurance that conformant servers can

This makes no sense at all. The whole point of path validation is that they don't need assurance, they can verify each step of the chain.

> is to promote DANE and DNSSEC adoption not give both a bad name.

Great! Don't give them a bad name then. (Well, no worse of a name than SMTP...)

> logical reasoning ability?

Operational guidance is always welcome. We have some of that in the TLSA spec, but more would be useful.

> makes mail delivery fail to RFC conformant peers is not particularly

Serious question: does your code somehow make sure that every SMTP client and every SMTP server can always agree on ciphers? (This is, of course, impossible.) If not, how does that differ from a PKIX administrator doing something stupid like only handing out the hash of a public key instead of the public key? These two situations can be prevented in the same way and have the same dire consequences if the operators mess up.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 17 Apr 2013 00:50:43 +0000

> the TLSA spec, but more would be useful.

If there is root for a new section in the specification that covers
operational guidance, and if you prefer downgrades the MUST to a
SHOULD (explaining when, ...) I guess I can live with that.  Would
that be agreeable?

> Serious question: does your code somehow make sure that every
> SMTP client and every SMTP server can always agree on ciphers?

Not a single report of such problems comes to mind (due to incompatible
cipher settings) in over a decade of reading the Postfix users list.

Unlike HTTP servers, the tweaking of ciphersuites in SMTP is rather
rare and is strongly discouraged.

    http://www.postfix.org/postconf.5.html#smtpd_tls_ciphers
    http://www.postfix.org/postconf.5.html#smtpd_tls_mandatory_ciphers
    http://www.postfix.org/postconf.5.html#smtp_tls_ciphers
    http://www.postfix.org/postconf.5.html#smtp_tls_mandatory_ciphers

Postfix SMTP clients enable every cipher supported by the underlying
library except "export" or "low-grade" ciphers when TLS is mandatory
(as it would be with DANE).

A lot of care went into designing the cipher controls to make them
self-tuning to sensible defaults and to give users a small number
of simple safe options rather than expose them to the rather complex
OpenSSL cipherlist language.

So yes, in fact it *does* make sure that incompatible cipher settings
don't occur, though of course concerted effort to aim shotgun at
foot can ultimately succeed.

> (This is, of course, impossible.)

In theory impossible, in practice, possible through careful
user-interface design.

> If not, how does that differ from
> a PKIX administrator doing something stupid like only handing out
> the hash of a public key instead of the public key? These two
> situations can be prevented in the same way and have the same dire
> consequences if the operators mess up.

Postfix has always worked robustly with default settings.  Neither
Wietse nor I have any plans to change that.  Will enabling support
for "2 1 1" and "2 0 1" DANE TLSA RRs leave Postfix robust?  What
default setting would you choose for your users if you were
maintaining Postfix and why?

Once a particular combination of TLSA RR fields is supported,
servers that publish these will only receive mail if they are
authenticated, otherwise mail stays in the sender's queue.

-- 
	Viktor.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 16 Apr 2013 20:16:48 -0700

I would consider the case of using one of the VeriSign roots certificates as
the TA certificate to be widely pre-configured and therefore would not think
that there is a big problem.

Jim

> Sent: Tuesday, April 16, 2013 4:20 PM
> To: [email-masked]
> I am reading this to mean that in some small-scale deployments, where the
set
> of clients is fully anticipated by the server operator, there exists an
> opportunity to publish TLSA "2 x [12]" without the TA cert in the server's
> chain, if all the clients are pre-configured with a copy of the TA
certificate.
> 
> This may to some extent be true, but it now obligates clients to try to
extend
> the server's chain with usage 2, which may be difficult in implementations
that
> only do chain extensions as part of PKIX validation to a trusted root.  If
the TA
> is present in the server's chain, implementation of usage 2 verification
is
> much more natural, just locate the TA in the server's chain.  So even if
the
> client "could" in principle locate the missing certificate, it is not
clear that it
> should be required to try as this may not be easy with at least some of
the
> popular toolkits.
validate
> the server's chain even in our hypothetical small-scale deployments is to
> include the trust anchor in the server's certificate chain.  No other pre-
> configuration mechanism scales to the public Internet, and the procotocol
> specified in 6698 is not restricted to small-scale deployments.
> 
> I may yet enable "2 x [12]" verification by default, in the hope that
server
> operators will do the right thing despite lack of normative language, but
I am
> hoping that some helpful language will be added to the RFC.
> 
> --
> 	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 17 Apr 2013 03:47:14 +0000

I have just updated the Postfix snapshot to support TLSA "2 0 1" and
"2 1 1", in the hope that appropriate operational guidelines will be
included in future specifications from the DANE WG.

Now that I have everyone's attention, perhaps a few more of the working
group leads can respond to the CNAME thread.

> that there is a big problem.

The default list of trusted CAs for Postfix is *empty*.  Even the
various Verisign roots cannot all be expected to be available on
every SMTP client.

There's nothing magic about Verisign (aka Symantec), there are
plenty of CAs whose popularity varies from country to country and
budget to budget.

If some day, when DANE is more widely deployed, augustcellars.com
becomes a DNSSEC domain, and you publish TLSA "2 0 1" or "2 1 1"
RRs for your SMTP servers with the digest of a Verisign root not
present in your server chain, you'll find you have a bit more free
time to spend on things other than reading email. :-)

The ietf.org mail server runs Postfix, it will I hope be upgraded
to enable DANE support not too long after 2.11 is officially released
circa Jan 2014.

-- 
	Viktor.

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 17 Apr 2013 07:40:36 +0200

> Errr, why not? If the client has a certificate that says "the public key of the trust anchor that signed me is keyX", and you get keyX from TLSA, why do you need a full trust anchor certificate?

Sure, I was referring to "IN TLSA 2 x [12]", where only the hash of the cert/key is available via DNS.

	jakob

---

From: John Gilmore <[email-masked]>
Date: Wed, 17 Apr 2013 01:21:33 -0700

> 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.

> makes mail delivery fail to RFC conformant peers is not particularly

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

---

From: [email-masked] (Martin Rex)
Date: Wed, 17 Apr 2013 14:59:42 +0200 (CEST)

Paul Hoffman wrote:
>
> Viktor Dukhovni <[email-masked]> wrote:
>>

In which case this will result in an interop problem.

The purpose of IETF RFCs/specification is to promote interop.
Any information that will generally be necessary to obtain interop,
and that is lacking from an RFC/specification, is a defect in of the
omission kind.

rfc2026 on Proposed Standard:

   Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified, deploying
   implementations of such standards into a disruption-sensitive
   environment is not recommended.

> but it is not required for the scenario to work.

That is a silly argument.

The client could have the server certificate pre-loaded, could use
just that for verification, and save itself the headaches of
PKIX and DANE validation entirely.

The intention, and default operational model of DANE is
(or at least should be), that it works as soon as the DNSSEC key
bootstrapping has been solved, the server's zone has been DNSSEC enabled,
and a TLSA record has been configured.

While it is OK for a TLS client to pin a server cert or certs from
the server's certificate chain in addition to DANE, or have any of
those certificates pre-loaded, that is an *ADDITIONAL* TLS client option.
It would be silly to assert that such extra complications would be
the default DANE operational model.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 17 Apr 2013 14:37:56 +0000

> and that is lacking from an RFC/specification, is a defect in of the

That was my motivation for proposing the erratum.  That said, I am
not a pedant with respect to the form in which the interoperability
requirement appears in the standard.

Though I think that a MUST is appropriate, perhaps the possibility
of interoperability under some narrow circumstances (pre-configured
clients) makes the TA cert optional in those circumstances and thus
not an absolute MUST in general. Nevertheless, in practice,
interoperability on the public Internet requires the inclusion of
any usage "2" root CA in the server chain.

> the default DANE operational model.

Thanks, I agree.  I find the counter-examples to be contrived,
focused on narrow use-cases when I see the purpose of DANE to be
broad Internet adoption.  One does not really need DANE in small-scale
intra-mural environments, and on the public Internet the "MUST"
seems obvious.  Once again, if it is preferable to express this
requirement as operational guidance rather than normative language,
I don't mind, so long as the requirement is ultimately clear to
server operators.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 17 Apr 2013 15:29:14 +0000

> think usage 2 is a bad idea, but it is in the spec and it is defined

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.

> 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
> 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*.

> 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.

> 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

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.

> 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:
> 
> 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.

> 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.

> 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
> 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

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.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 17 Apr 2013 10:34:36 -0700

> John Gilmore
> Sent: Wednesday, April 17, 2013 1:22 AM
> To: [email-masked]; [email-masked]
> > 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.
> 
certificates.
> RFC 6698 does not require TLS servers to do ANYTHING.
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:
> 
> 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

> 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?
> 
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:
> 
"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":
> 
> 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:
> 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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Apr 2013 02:34:23 +1000

> the trust this dialog, that is not true for everybody.

You mixing two different types of trust.  TLSA is about whether the connection
to the machine is legitimatly tied to the domain, not whether the activity of
the owner of the domain is legitimate.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]