Subject: [dane] IN TLSA 2 0 0 and handshake trust chain?

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 22 Mar 2013 00:07:25 +0000

Are servers that publish their trust anchor details via DNS in full:

	_25._tcp.mail.example.com. IN TLSA 2 0 0 <DER cert in hex>

exempt from being obligated to provide the same certificate somewhere
in their trust chain?  It is far easier to treat the "2 0 0" case
as a more specific bulky match blob, than to also arrange for it
to be an input into the client's trust chain construction algorithm.

The latter is largely impractical with OpenSSL.  I though I saw
some text in the RFC about "2 x y" trust-anchors needing to be
explicitly provided in the server's trust chain, since clients
cannot be expected to already have these on hand.  Can't seem
to find it any more.

I am hoping that the above includes the "2 0 0" case, for though
the cert is available in DNS it is not in the trust chain or trust
store, and moving it from the DNS into the trust chain or trust
store is non-trivial.

I am also hoping that almost nobody will use match type 0 certs,
and that in practice all TLSA records will be sha2 digests.

If verifiers are obligated to attempt to use the certificate in
"2 0 0" as part of the trust chain if missing, then I may need
to treat "2 0 0" as "unusable" until OpenSSL makes it possible
to configure each connection with a private list of additional
trust anchors before starting the handshake (without polluting
the trust store for future connections that use the same
persistent SSL_CTX).

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 22 Mar 2013 16:51:34 +0000

On Fri, Mar 22, 2013 at 12:07:25AM +0000, Viktor Dukhovni wrote:

Any comments at all on the below?  It is tempting to simply treat
"IN TLSA x 0 0" as "unusable", for all "x", and thereby discourage
the notion that it is a good practice to deliver full certificates
via DNS, instead of the TLS handshake...

> The latter is largely impractical with OpenSSL.  I thought I saw

FWIW, I have a practical solution for OpenSSL, but I'd rather not
have to field it.

> the trust store for future connections that use the same

So no new OpenSSL library code is required to support this, if one
stares at the (lightly documented) OpenSSL API hard enough, but
still "IN TLSA x 0 0" looks unwieldy.

-- 
 	Viktor.

---

From: Guido Witmond <[email-masked]>
Date: Fri, 22 Mar 2013 19:30:57 +0100

On 03/22/2013 05:51 PM, Viktor Dukhovni wrote:
 >> 	_25._tcp.mail.example.com. IN TLSA 2 0 0<DER cert in hex>
 >>

 > still "IN TLSA x 0 0" looks unwieldy.

I use the 2-0-0 right now to set the TLS-context to that certificate 
only. (No global CA's), so that only server certificates signed with 
that certificate will pass validation. The connection fails if the 
server certificate doesn't match when my connection is hijacked with a MitM.

If I understand you correctly, dropping TLSA 2 0 0 (full certificates) 
means that I would have to connect to a server, learn its certificates 
in the handshake and then perform the hash verification against the 
TLSA-record. It could tempt some into adding a 'override tlsa-record 
validation' button later. That road leads to the madness we give to our 
browser users. People who are unable to make a good decision, especially 
if the rendered page (with the wrong certificate) looks like a bank-page 
with a large transaction pending. (phishing).

I have a very good use case to set the 2-0-0 certificate as the only 
certificate in the session connection context. It allows clients to 
limit their connections only to servers signed with the certificate from 
the TLSA-record.

I call it Cryptographic Same Origin Policy.
Please see: http://witmond.nl/ecca/eccentric-authentication.html

I humble believe that creating a new session context (with just a single 
CA-cert) for each session is the way forward. Having a single 
certificate store is the old way of the global 'Trusted' CAs.

I remember the pain of doing that in Firefox with NSS. It's easy in Go-lang.

Cheers, Guido.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 22 Mar 2013 19:30:26 +0000

> > still "IN TLSA x 0 0" looks unwieldy.

[ I should probably mention that my issue is even worse with "2 1 0".
I now have the public key of the TA, but as with "2 0 0" potentially
no TA certificate either in the server trust chain, or in the system
trust store.  So now I need a new API to validate trust chains
starting from just a public key (which is worse than with "2 0 0",
where I need to inject a possibly missing TA certificate into the
trust chain.). ]

> only.

Why "2 0 0" and not "2 1 1" (with the certificate configured in
your server chain)? So that instead of the TA cert coming from DNS,
it is explicitly included in the server's SSL/TLS HELO (response)?

> (No global CA's), so that only server certificates signed with

The effect of "2 1 1" is the same, but the DNS data is much more
sensible, and the TA certificate is supplied during the SSL handshake
inline, rather than out-of-band via DNS.

> If I understand you correctly, dropping TLSA 2 0 0 (full
> certificates) means that I would have to connect to a server, learn
> its certificates in the handshake and then perform the hash
> verification against the TLSA-record.

Yes, you have to connect to the server either way. With "2 0 0"
the trust-anchor certificate is out-of-band in DNS, and the handshake
might omit the TA cert from the server response (send only the
stuff signed by the TA down to the leaf).  With "2 1 1" just the
TA fingerprint is in DNS and the actual TA cert is in the TLS
handshake.

"2 1 1" does not tax DNS caches, especially when servers have certs
from multiple CAs and perhaps multiple versions of a CA when key
rollover happens.  And it dramatically simplifies client-side
implementation, when the TA is not already in the system store.

> It could tempt some into
> adding a 'override tlsa-record validation' button later.

This is a non-sequitur.

> limit their connections only to servers signed with the certificate
> from the TLSA-record.

Why is this better than "2 1 1".

> I call it Cryptographic Same Origin Policy.

How does "2 1 1" fail to serve the same need, with the server trust
chain containing the cert you publish via DNS?

A deployment guide for DANE should likely specify that domain owners
publishing "2 1 1" or "2 0 1" TLSA records MUST include the TA cert
in the server's configured trust chain.  The "x y 0" RRs are a pain
to implement, and substantially increase the effectiveness of
DNS reply amplification attacks.

> I humbly believe that creating a new session context (with just a
> single CA-cert) for each session is the way forward. Having a single

I seems you're somehow confused, or I'm not understanding your
reply.  The "3 1 1" and "2 1 1" use cases cover everything other
than how the mechanism for conveying the TA issuing certificate.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Sat, 23 Mar 2013 17:23:41 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

Fist of all, thank you for all of the questions.  Questions from
implementors are an important part of the process and the ensuing dialog
should help tlsa progress towards Full Standard.

VD> Are servers that publish their trust anchor details via DNS in full:

VD> 	_25._tcp.mail.example.com. IN TLSA 2 0 0 <DER cert in hex>

VD> exempt from being obligated to provide the same certificate somewhere
VD> in their trust chain?

I had a probably too long answer written, but after reading the rfc a
couple more times, and notwithstanding our early discussion here (some
of which would have supported permitting elision), I've concluded that
the text in §2.1.1:

,----< 2 -- Certificate usage 2 ... >
| 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.
`----

means that the cert has to be included in the tls startup negotiation;
it cannot be elided.

VD> I am also hoping that ... in practice all TLSA records will be
VD> sha2 digests.

Sha2 matches should be documented as the Best Practice for TLSA.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 24 Mar 2013 00:52:14 +0000

On Sat, Mar 23, 2013 at 05:23:41PM -0400, James Cloos wrote:

> the text in ?2.1.1:

I take it you read the phrase "with any certificate matching the
TLSA record... " to mean that such a certificate must come from
the server in the server SSL HELO.  If I squint hard enough, I can
read it the same way,  but I could also suppose that the PKIX
validation path in question was in part constructed by the verifier,
and so no explicit requirement for the server to provide the
certificate.

This should probably be spelled out more completely in an implementation
guideline section, or similar.  The above is rather subtle.

Since of course with usage 2 there is no presumption that the verifying
client has the TA public key (or equivalently a certificate containing
it) already in hand, the requirement to include the certificate in the 
trust chain should I think be more explicit.

At some noticeable complexity cost (though not a lot of lines of
code), I've added full support for "2 0 0" and "2 1 0" TLSA records,
so now I can verify trust chains that omit the corresponding issuing
certificate and begin with something signed by the TA.

> Sha2 matches should be documented as the Best Practice for TLSA.

So at this point what I have is:

    - Full support for "IN TLSA [13] x y ..." for all x, y.

    - Full support for "IN TLSA [02] x 0 ..." for all x.

    - Support for "IN TLSA 2 x [12] ..." for all x, provided it is clear
      from the RFC that the server is obligated to include the TA
      cert in its server SSL HELO (reply).  If this is not clear,
      then I might need to treat "IN TLSA 2 x [12] ..." as "unusable".

      [ If mail to enough sites fails because domain owners are having
	trouble creating a usable configuration, senders will not want
	to enable DANE TLSA support.  There should be no subtle traps
	for domain owners publishing TLSA records. ]

      If the RFC does not clearly require "IN TLSA 2 x [12] ..."
      to mandate the TA cert in server's SSL HELO, then I'll have
      to go with "2 x [12]" as "unusable".

    - I likely have to treat "0 x [12]" as "unusable", because when the
      TA in the association is a public root CA, they will typically
      (common practice pre-DANE) not include the TA cert in their trust
      chain.  I cannot require Postfix MTAs to have every single public
      CA in their CAfile, this is a non-starter.  So "0 x [12]" will
      fall back to mandatory TLS with no authentication.

I can only improve on qualified support for:

	IN TLSA 0 0 1 - Trust anchor cert likely not available in server HELO
	IN TLSA 0 0 2 - ...
	IN TLSA 0 1 1 - ...
	IN TLSA 0 1 2 - ...

	IN TLSA 2 0 1 - Trust anchor cert in SSL HELO may not be RFC mandated
	IN TLSA 2 0 2 - ...
	IN TLSA 2 1 1 - ...
	IN TLSA 2 1 2 - ...

if the RFC requires conforming server implementations to always
include the TA certificate in their SSL HELO (reply) trust chain.

I expect that progress on the "IN TLSA 2 x [12] ..." front is
possible, by clarifying the RFC text.  I would guess that I'll find
resistance on the "IN TLSA 0 x [12] ..." front, so support for that
will likely not be available in Postfix.

-- 
	Viktor.

---

From: Guido Witmond <[email-masked]>
Date: Sun, 24 Mar 2013 16:58:09 +0100

> than how the mechanism for conveying the TA issuing certificate.

To clear up any confusion, I wanted to give an example of why I use 
2-0-0 full certificates and I'm not convinced to give them up, yet. 
Although your DNS-cache arguments are quite compelling.

thanks, Guido.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 26 Mar 2013 08:22:19 +0000

> and so no explicit requirement for the server to provide the

This looks even more important with "2 1 0", since we find in:

    https://tools.ietf.org/html/rfc5280#section-6.1.1

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

and in

    https://tools.ietf.org/html/rfc5280#section-6.1

      (b)  certificate 1 is issued by the trust anchor;

Since, as James points out, we have in: 

    https://tools.ietf.org/html/rfc6698#section-2.1.1

      2 -- Certificate usage 2 is used to specify a certificate, or the
      public key of such a certificate, that MUST be used as the trust
      anchor when validating the end entity certificate given by the
      server in TLS.  This certificate usage is sometimes referred to as
      "trust anchor assertion" and allows a domain name administrator to
      specify a new trust anchor -- for example, if the domain issues
      its own certificates under its own CA that is not expected to be
      in the end users' collection of trust anchors.  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.

a clear requirement to build a PKIX trust chain.  Since the word
"issued" (not the same as "signed") implies a name comparison not
a signature check,  in order to use an "IN TLSA 2 1 0 ..." RR, we
need to map the trust-anchor's public key to its subject name, which
is only possible when the corresponding certificate must appears in
the peer's chain!

Now if that's a requirement, then "2 1 0" use-case is simply a waste
of bits in DNS, we get the same result via "2 1 1", since both
match the same element of the chain, but 2 1 1 is substantially
more compact.

------
SO: What's the story wrt. requiring the trust-anchor certificate in
the server's chain?  Is my analysis correct?  Should the text be
more clear?
------

> certificate and begin with something signed by the TA.

My current "2 1 0" support checkes "signed by TA" not "issued by
TA", is that a valid interpretation of "2 1 0"?  There is a real
tension here between robustness of the protocol in the face of
sloppy administrator practices (neglecting to include the top signer
in the chain) and the stated requirement to do "PKIX validation".

Which do you want?  If it's strict "PKIX", then the TA cert is
required and then "2 1 0" devolves to "2 1 [12]" and is redundant
(modulo SHA2 2nd-preimage attacks which break so much else that it
is not worth considering other than future introduction of SHA3 or
beyond matching types via the IANA registry).

If "2 1 0" is not strict PKIX, and supports chains merely signed
by a TA, but not necessarily "issued" by that TA, then 2 1 0 has
some meaning, but violates the "issued by TA" requirement on the
top element of the chain.

Implementing the TA portion of the standard is uncovering murky
corner cases that I don't see clearly covered in 6698.

The leaf certificate use cases all work.  None of the certificate
usage "2" (other than "2 0 0") cases work at all unless the TA
certificate is absolutely required in the peer's chain, but even
"2 0 0" is DNS-hostile due to excessive RRset sizes.

If one takes certificate usage 0 at face value, then one is required
to be able to build a PKIX chain for all its incarnations without
any DANE RRset input, and then with all the right material already
hand, there are no problems with "1 x y".

For SMTP however, the requirement on the verifier of having at hand
"a complete CA certificate set" (whatever that means) is untenable.
There is no human to click "OK" when the CA list is incomplete,
and administrators will quickly disable DANE if it routinely breaks
mail delivery to a non-trivial fraction of destinations.

So I need to ignore the requirement for pre-existing shared CA trust
with certificate usage "0" and treat it as equivalent to "2". Thus
I'm left with either (amended 6698 or draft-ietf-dane-smtp):

    - All DANE-enabled TLS servers MUST respond with server SSL HELO
      chains that contain the associated TA certificate (for both
      usage 0 and 2).  In this case "2 0 0" and "2 1 0" are both
      silly, "2 0 1" or "2 1 1" do the same job much better.  And,
      for SMTP at least, "0 0 0" and "0 1 0" meet the same fate.

OR

    - I can support only the DNS-hostile "0 0 0" and "2 0 0" and
      also the more compat "0 1 0" and "2 1 0" provided I re-interpret
      "issued by TA" as "signed by TA" in the case of full public-key TAs.

What I have implemented so far is the second alternative.  I am a bit
stunned by the silence of the majority of the list.  Are my questions
to hard, too annoying, or just inconveniently timed?

-- 
	Viktor.

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 26 Mar 2013 12:52:36 +0100

> match the same element of the chain, but 2 1 1 is substantially

I agree "2 1 0" is a waste of bits - "2 x {1,2}" makes a lot more sense".

	jakob

---

From: James Cloos <[email-masked]>
Date: Tue, 26 Mar 2013 09:50:06 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD> Since the word "issued" (not the same as "signed") implies a name
VD> comparison not a signature check,

I'm not sure that such a meaning is intentional rather than possibly
sloppy language.

I'd consider a signature sufficient.

-JimC

---

From: James Cloos <[email-masked]>
Date: Tue, 26 Mar 2013 09:48:11 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD> I take it you read the phrase "with any certificate matching the
VD> TLSA record... " to mean that such a certificate must come from the
VD> server in the server SSL HELO. 

Yes, but I should have written something more like "in the HELO or in
the client's trust store"; any case where a type 0 can work also should
work with a type 2 pointing at the same cert.

VD> If I squint hard enough, I can read it the same way, but I could
VD> also suppose that the PKIX validation path in question was in part
VD> constructed by the verifier, and so no explicit requirement for the
VD> server to provide the certificate.

I did forget the other day, as I wrote above, the case where the type 2
points at a cert in the client's store.  

Since you wrote that, after all, you wrote the code to handle the type 2
case where the cert isn't in the local store or in the HELO, I have to
say "working code beats word lawyering".

I think it would have been OK to skip the extra code for those possibil-
ities, using the language in the RFC as an excuse.  But since you wrote
it anyway, use it.

-JimC

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 26 Mar 2013 17:27:25 +0000

> work with a type 2 pointing at the same cert.

I must not be making my question clear enough.  The "or in the
client's trust store case" is NOT an option for any of the "2 x y"
forms.  The domain owner is not psychic, and must not be given the
freedom to divine what may or may not be in the trust stores of
every plausible client.

Yes, I have code that supports the DNS unfriendly "2 0 0" and I'll likely
keep it in place,  although I am also considering disabling it by default.

The deeper problems are:

    - "2 x [12]" are too fragile to support in any implementation that
      commits *verify* the peer's certificate or else drop the connection.
      If we're proceeding opportunistically without dropping the connection,
      what's the point of DANE?

      Unless the certificate in sure to be in hand, that is unless
      it is REQUIRED (MUST, no excuses) to be provided in the
      server's SSL HELO, I cannot make TLS certificate *verification*
      mandatory for a connection to a "2 x [12]" endpoint".  Since
      usage "2" supports private CAs, there is NO presumption that
      clients already have the TA cert, so the RFC has to mandate its
      presence in the server SSL HELO chain.

      If this is not clearly required by 6698, server operator
      practices will vary on this point, and I must then treat all
      "2 x [12]" TA associations as "unusable".

    - In addition, "2 1 0" is also unusable if PKIX means "issued and
      signed by the TA", and not just "signed by the TA".  Which is it?
      Is 6698 relaxing 5280 on this point?  My reading of 5280 is that
      they mean "issued", and TAs must have a subject name for that purpose.
      If that's not what 5280 means, DANE should specify the "signed by is
      sufficient" interpretation, or else MANDATE that the peer
      present the TA certificate after the server SSL HELO reply.

    - Without a MANDATE to include the TA in the server's configured
      SSL trust chain, it turns out that the *only* "2 x y" case I can
      implement robustly, but hesitantly, since I'm endorsing bad DNS
      hygiene in doing so, is "2 0 0".

Since for SMTP I must also read "0 x y" as "2 x y", and I am guessing
that this group will not agree to language in 6698 or related
standards that also MANDATES the TA certificate in the server's
SSL certificate chain (sent by the server itself, not optionally
found by the client),  I have to treat all "0 x y" associations
other than "0 0 0" as unusable.  I am also inclined to treat "0 0
0" as unusable in order to promote "DNS hygiene".

I cannot encumber Postfix users with a feature that routinely makes
email sit in queues for spurious reasons.  Can the group clarify the
RFC 6698 requirements with respect to the content of the SSL "server
certificate" message:

    https://tools.ietf.org/html/rfc2246#section-7.4.2

       Structure of this message:
	   opaque ASN.1Cert<1..2^24-1>;

	   struct {
	       ASN.1Cert certificate_list<0..2^24-1>;
	   } Certificate;

       certificate_list
	   This is a sequence (chain) of X.509v3 certificates. The sender's
	   certificate must come first in the list. Each following
	   certificate must directly certify the one preceding it. Because
	   certificate validation requires that root keys be distributed
	   independently, the self-signed certificate which specifies the
	   root certificate authority may optionally be omitted from the
	   chain, under the assumption that the remote end must already
	   possess it in order to validate it in any case.

The part starting with "Because certificate validation..." is clearly
cast in a new light by DANE with associations that specify TA digests.
Where/what is the normative language in 6698 that refines this requirement
for server operators (and domain owners) who choose to publish DANE
TLSA associations?

> ities, using the language in the RFC as an excuse.  But since you wrote

Yes, I have code that handles "2 0 0" and "0 0 0" out-of-band, but
I'd much rather not need it, it brings-in dependencies on low-level
primitives (X509 signature checks) from OpenSSL's libcrypto that
I'd rather not introduce.

For the same implementation complexity price, I also have code that
handles "2 1 0" and "0 1 0", but only if "issued by" is to be taken
to mean "signed by".

I have no code that can deal with "2 x 1" or "2 x 2" unless there
is clear language in 6698 that mandates the corresponding TA in the
server's "certificate_list" (https://tools.ietf.org/html/rfc2246#section-7.4.2)

My request to the group is as follows:

   Please consider *mandating* that any TLSA association that
   specifies a trust anchor (0, 2 and any additional ones in the
   future) obligates the server to present the corresponding TA
   certificate in its "certificate_list".

If that is done, I can support all "0 x y" and all "2 x y"
associations, and publish documentation for Postfix SMTP server
operators to be DNS-friendly and use "2 x 1" rather than "2 x 0".

If the group can only mandate on-the-wire TA certificates in
the "certificate_list" for "2 x y" associations and not for
"0 x y" associations, then I must drop support for all "0 x y"
associations other than "0 0 0", but it may be better to simply
not support "0 x y" at all for all "x y".

If there is no "certificate_list" mandate for any of the "usage"
values, then I can only implement "0 x 0" and "2 x 0", with x=1
meaning "signed by".

So my take on the standard from an implementation viewpoint is that
so far the *only* robust associations are "3 1 1" and "3 0 1".

    - 3 0 0 and to a lesser extent 3 1 0 are not DNS-friendly.

    - 3 1 2 alone is fragile because matching type 2 support is optional,
      one must publish 3 1 1 along with it.  So essentially nobody will
      publish 3 1 2.

    - "0 x y" and "1 x y" needlessly risk rejection by clients with an
      incomplete public CA set that implement the spec as written and
      implement these as "constraints" and not "assertions".

    - "2 x [12]" is unusable without the "certificate_list" mandate.

    - "2 1 0" is unusable unless "issued by" is read as "signed by",
      it is also not very DNS-friendly, a 2048-bit RSA public key
      is around 300 bytes of DER (an EC public key at ~90 bytes
      may be sufficiently svelte, but we're not yet at broad support
      for EC in SSL).

    - "2 0 0" is not DNS-friendly.

With a "certificate_list" mandate for "2 x y", I get:

    - Cleaner implementation support for "2 x 0" associations, no need
      for signature checks in my code, the chain will be checked by
      OpenSSL's built-in verification code.

    - Support for "2 x [12]" associations, since I can expect to find the
      TA in the server chain.

With a "certificate_list" mandate for "0 x y" (which I expect I won't
get, but it would be a shame not to ask) the above applies with "2"
replaced by "0".

With no "certificate_list" mandate, and without clarification of
"issued by" vs. "signed by", I may have to withdraw support for
everything other than "3 x y" and (after remapping constraint to
assertion) "1 x y".

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 26 Mar 2013 21:54:08 +0000

> I agree "2 1 0" is a waste of bits - "2 x {1,2}" makes a lot more sense".

What about the larger issue, how can I use "2 x 1" or "2 x 2" if
the TA certificate is not required in the peer's chain?  Or is it?

How can I use "2 1 0" (waste of bits and all) if I must check
"issued" rather than "signed"?  Is the group tired of my questions?

I need to converge on a viable implementation profile and some
guidance is essential at this point.

The problem isnt't how to write the code, that's easy. The problem
is choosing appropriate TLSA RR semantics.  I don't know when it
is safe to commit to verification of the peer's chain if I can't
predict its required contents.  What requirements on the peer's
"certificate_list" are implied by publishing a trust anchor TLSA
RR with "2" (and ideally also "0") as the certificate usage?

-- 
	Viktor.