Subject: [dane] Certificate usages 1/3 and subject name checks

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 1 Mar 2013 16:59:00 +0000

Having read RFC 6698 multiple times recently, I would like to ask
for clarification of the semantics of Certificate usage "3", aka
"Domain-issued certificate".

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

Given an explicit binding in the DNS for a specified service end-point
to a unique certificate (in full or by subject-publickey-info), it would
seem rather unnatural to apply subject name checks to the certificate so
bound. The binding in the DNS should ideally obviate any need for similar
(potentially conflicting) bindings inside the certificate.

In fact when one deploys a cluster of hosts with a shared key-pair
that provide the same service (possibly via MX or SRV records), it
would be surprising to find that a "TLSA 3 1 1" certificate binding"
needs to be updated when a new host is added to the cluster in
order to resign the public key with an additional name in the SAN
extension, merely to duplicate the DANE binding.

Thus my reading of 6698 is that usage 3 (and 1) obviate any
requirement for name validation, which should only apply with
certificate usage 2 and 0.

However, https://tools.ietf.org/html/rfc6698#section-4 in passing
and without any normative text mentions the issue of name verification
without specifically commenting on any distinction between 0/2 and
1/3. I think follow-on RFCs (dane-srv perhaps) should amend or
clarify this text.

What is the expected interpretation of 6698 in this respect? Does
it support DNS-only bindings to essentially bare public keys
encapsulated in minimal X.509 structures? Is it fair to say that
certificate usage 3 (and I would posit also 1) is such a binding?

This matters because the text in

	https://tools.ietf.org/html/draft-ietf-dane-srv-02#section-7.3

which is I hear nearing final review at the IETF seems to fly in
the face of (what I see as) a reanable interpretation of 6698 and
suggests semantics for previously unseen certificate usage values,
and in particular unconditional name checks.

I should note that in my opinion, as a matter of sound design, name
checks for usages "3" and "1" MUST not apply. The reason is that
name checks on already "bound" (via DNSSEC + DANE) certificates
add nothing to security, since a malicious DNS administrator is
free to create whatever certificate contents they see fit (including
a suitably matching name), and publish a "TLSA 3 1 1 <public-key-digest>"
for that certificate.  Thus checking names for usage "3" (and usage
"1") is simply an extra opportunity for the handshake to fail, with
no tangile security benefit.  So in my view a name check here is
an opportunity "to snatch defeat from the jaws of victory".

Thanks.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Fri, 01 Mar 2013 18:28:05 -0500

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

VD> Given an explicit binding in the DNS for a specified service end-point
VD> to a unique certificate (in full or by subject-publickey-info), it would
VD> seem rather unnatural to apply subject name checks to the certificate so
VD> bound. The binding in the DNS should ideally obviate any need for similar
VD> (potentially conflicting) bindings inside the certificate.

Thanks for bringing that up.  I seem to have glazed over at that point
when I read draft-ietf-dane-srv-*.

It is an interesting issue.

The target for the SRV/MX TLSAs is for the server to have a single name
and a single matching cert; this issue will not occur in that case and I
expect that and a desire to minimise code paths are why the draft has
that language.

But even so, a type 3 shouldn't require any verification beyond checking
that the TLSA matches as it specifies.  Especially with selector 1.

[I had more to write; but have to cut this short and run.... -JimC]

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 2 Mar 2013 04:01:22 +0000

> that the TLSA matches as it specifies.  Especially with selector 1.

I don't think that selector "1" vs. "0" ought to substantively
influence the semantics of the certificate, even we intuit that
the domain owner is fervently trying the world of CAs behind him.

However, I do believe that the same (subject name checking) policy
should apply for both certificate usage "3" and "1".

> [I had more to write; but have to cut this short and run.... -JimC]

Looking forward to additional comments. In particular, is 6698
sufficiently clear, and was merely misconstrued by the dane-srv
draft? Or does 6698 itself need clarification in section 4 to
avoid similar confusion in implementations and future related
standards?

-- 
	Viktor.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 2 Mar 2013 10:53:39 +0200

> should apply for both certificate usage "3" and "1".

I think you are mixing up usages 1 and 2 or something.

My reading of RFC 6698:
Usage 0: Validate up but excluding RP trust anchor[1].
Usage 1: Validate up but excluding RP trust anchor[1].
Usage 2: Validate up but excluding DANE trust anchor.
Usage 3: Validate none.[2]

[1] If DANE pinned certificate is below RP trust anchor,
DANE checks can't pass (can't happen for usage 1 anyway,
since nothing is below EE).

[2] This is actually a special case of validate up but
excluding DANE trust anchor.

-Ilari

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 2 Mar 2013 18:20:39 +0000

> I think you are mixing up usages 1 and 2 or something.

I am quite sure I am not.

In both usage 3 and usage 1 the TLSA RR specify the end-entity
(leaf) certificate deployed on the server.  Once a particular
certificate is explicitly bound to the server via a TLSA RR, there
is no point in comparing the server name with the content of the
certificate, we already have a binding and name checks can only
fail with no security gain (snatch defeat from jaws of victory).
One simple design rule I try to adhere to is: "don't fail when
success is an option".

I read the DANE certificate usage numbers as falling into a 2x2
feature matrix:

          TYPE: TA | EE
        PKIX:/-----------\
        YES  |  0  |  1  | 
        -----|-----------|
        NO   |  2  |  3  |
        -----\-----------/

The TA usages specify a trust anchor while the EE usages specify
an end-entity certificate. The PKIX "YES" usages request trust-chain
validation to an existing CA root, while the "NO" usages do not.

If we encode the certificate usage as a 2-bit number, the least
significant bit is the EE bit, and the most significant bit is the
"CAs? We don't need no stinkin' CAs!" bit (where by CAs one means
the usual panoply of public root CAs found in browser cert bundles,
and not privately label trust-anchors is in usage 2).

Bottom line, the type of trust path validation is completely
irrelevant when deciding whether the client should check the
SAN (or fallback CN) name binding of the server certificate,
given a DANE binding to an EE certificate, whether we check
the trust path or not, we're done with the name binding.

Therefore, 1 and 3 should I believe be treated identically with
respect to the semantics of the certificate content (as distinct
from its trust path).

-- 
	Viktor.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 2 Mar 2013 22:05:57 +0200

> One simple design rule I try to adhere to is: "don't fail when

Ah, if one has universal RP trust anchor[1], then the path validation
rules simplify to:

-Usages 0/2: Validate up to DANE pin / trust anchor.
-Usages 1/3: Validate nothing.

[1] Eseentially meaning any certificate (or any CA certificate)
is treated as trust anchor.

-Ilari

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 2 Mar 2013 20:21:26 +0000

> -Usages 1/3: Validate nothing.

I honestly have no idea what you mean, but it sure seems that you
are talking about trust chain validation, where-as the question in
this thread is about the necessity (or lack there-of) of checking
the certificate name (subjectAltName or CN).

The certificate is in this context already presumed trusted by some
means (whether DANE EE or TA, trust assertion or constraint), the
question that remains to be settled is whether the server certificate
is the *right* certificate or an unrelated trusted certificate.

I posit that with certificate usage 1/3 this question is moot, the
DANE EE data is sufficient to bind the certificate to the service,
and no name checks should be required.

The text in 6698 is perhaps ambiguous on this point, and the text
in draft-srv seems to suggest a contrary interpretation that I
believe needs to be corrected.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Tue, 5 Mar 2013 01:20:10 +0100 (CET)

> certificate usage 2 and 0.

I would actually very dislike such an interpretation, and require the
name validation for *ALL* variants of X.509 certificates.

For usage DNS usage (1) it would actively subvert the name binding
that the public CA (from the Web Browser X.509 PKI) placed into the
certificate.  What about other cert attributes in DANE usage (1)
(such as BasicConstraints, KeyUsage, ExtendedKeyUsage, NameConstraints,
 Certificate Policies, PolicyConstraints and Validity)?

The end users, some of which sometimes actually look at the attributes
of X.509 certs, would get totally confused by such weird rules.

For Usage (3) it should be trivial for the server admin to provide
a correct server cert where the name matching succeeds, without confusing
any users that may occasionally look at the server cert.

-Martin

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 4 Mar 2013 20:25:00 -0500

That is completely antithetical to my understanding.

For types 0, 1 and 2 - the DANE check is in addition to ALL existing PKI
checks.
For type 3 - I would agree that no PKI checks are to be done.  That would
include the name matching check.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Viktor Dukhovni
> Sent: Saturday, March 02, 2013 1:21 PM
> To: [email-masked]
> Subject: Re: [dane] Certificate usages 1/3 and subject name checks
> 
> (leaf) certificate deployed on the server.  Once a particular certificate
is
> explicitly bound to the server via a TLSA RR, there is no point in
comparing
> the server name with the content of the certificate, we already have a
> binding and name checks can only fail with no security gain (snatch defeat
> from jaws of victory).
> One simple design rule I try to adhere to is: "don't fail when success is
an
> option".
> 
> I read the DANE certificate usage numbers as falling into a 2x2 feature
matrix:
> 
>           TYPE: TA | EE
>         PKIX:/-----------\
>         YES  |  0  |  1  |
>         -----|-----------|
>         NO   |  2  |  3  |
>         -----\-----------/
> 
> The TA usages specify a trust anchor while the EE usages specify an end-
> entity certificate. The PKIX "YES" usages request trust-chain validation
to an
> existing CA root, while the "NO" usages do not.
> 
significant bit
> is the EE bit, and the most significant bit is the "CAs? We don't need no
> stinkin' CAs!" bit (where by CAs one means the usual panoply of public
root
> CAs found in browser cert bundles, and not privately label trust-anchors
is in
> usage 2).
> 
> Bottom line, the type of trust path validation is completely irrelevant
when
> deciding whether the client should check the SAN (or fallback CN) name
> binding of the server certificate, given a DANE binding to an EE
certificate,
> whether we check the trust path or not, we're done with the name binding.
> 
> Therefore, 1 and 3 should I believe be treated identically with respect to
the
> semantics of the certificate content (as distinct from its trust path).
> 
> --
> 	Viktor.
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 5 Mar 2013 02:00:17 +0000

> name validation for *ALL* variants of X.509 certificates.

This dislike translates into an important lost feature, no support
for direct binding of a service end-point to a public-key sans all
the baggage of the legacy public CA PKI.

The additional name check is, as I pointed out upthread, simply an
opportunity to fail with no security gain. Why should we force the
client to fail when it has all the information required to succeed?
This, I think, makes little sense.

Yes, we can suggest to server operators that their certs SHOULD
carry a name that may be acceptable to legacy public CA PKI clients,
(if they are indeed signed by such legacy public CAs, for example,
today most SMTP certs are self-signed and one only gets protection
from passive eavesdroppers). Telling clients that they MUST reject
certs that don't have a corresponding CA-blessed name, even though
they have an authoritative DANE binding to the EE cert would be a
real shame.

My (not outlandish) view is that the legacy public CA X.509 PKI is
a sinking ship.  There is little reason to entrench its semantics
into new protocols except as an optional transition aid.

> certificate.

Hallelujah! I thought that the whole point of DANE was to actively
subvert the public CA model (be it over time).  I place as little
faith as possible in the name bindings provided by public CAs and
hope to some day be entirely unencumbered by such faith.

When the service operator publishes a DNSSEC public key binding
(binds the service end-point to an EE certificate), that binding
should suffice.

>  What about other cert attributes in DANE usage (1)

If a client application performs PKIX trust path validation for
certificate usage 1, it will check everything relevant for that.

> of X.509 certs, would get totally confused by such weird rules.

With DANE, and EE certificate bindings any UI should simply indicate
that the certificate is bound to the end-entity (service host/port)
via secure DNS. The content of the certificate is irrelevant it is
just an ephemeral public key that could be rotated daily!

Smaller certificates use less bandwidth. This is the sort of lean
and mean certificate (303 bytes of DER) I plan to deploy on MX host
MTAs (bare minimum extensions to support TLS key usage).

	$ openssl x509 -in cert.pem -text
	Certificate:
	    Data:
		Version: 3 (0x2)
		Serial Number: 1 (0x1)
	    Signature Algorithm: ecdsa-with-SHA256
		Issuer: 
		Validity
		    Not Before: Mar  5 01:33:43 2013 GMT
		    Not After : Mar  5 01:33:43 2014 GMT
		Subject: 
		Subject Public Key Info:
		    Public Key Algorithm: id-ecPublicKey
			Public-Key: (256 bit)
			pub: 
			    ...
			ASN1 OID: prime256v1
		X509v3 extensions:
		    X509v3 Basic Constraints: 
			CA:TRUE
		    X509v3 Key Usage: 
			Digital Signature, Key Encipherment
		    X509v3 Extended Key Usage: 
			TLS Web Server Authentication, TLS Web Client Authentication
	    Signature Algorithm: ecdsa-with-SHA256
		 ...
	-----BEGIN CERTIFICATE-----
	MIIBKzCB0aADAgECAgEBMAoGCCqGSM49BAMCMAAwHhcNMTMwMzA1MDEzMzQzWhcN
	MTQwMzA1MDEzMzQzWjAAMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE7a1YF62n
	6XjcPzMGZGjsxSzlJPyq7B5J/q8FNdkS3LG2RrjmlxgjnzIkuzOCHP2AK8z2sKkF
	36XRiiVI8X+NeaM8MDowDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCBaAwHQYDVR0l
	BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAoGCCqGSM49BAMCA0kAMEYCIQDRTRJU
	qwUrkoju65eONV2WcijOh5vxFX6K0AA2cy0oOQIhAK7bv88ee71coa9chdB/YIOD
	+9FvyHx3wLebt4clSEzr
	-----END CERTIFICATE-----

> any users that may occasionally look at the server cert.

Not when the same key-pair is fielded on a cluster of hosts, and
one wants to avoid minting new certs each time a host joins or
leaves the cluster. Administration is much simpler when all one
needs to do is point another CNAME to the same TLSA record:

    $ dig +noall +ans -t tlsa _25._tcp.open.nlnetlabs.nl
    _25._tcp.open.nlnetlabs.nl. 10190 IN    CNAME   3.1.1._dane.nlnetlabs.nl.
    3.1.1._dane.nlnetlabs.nl. 10190 IN      TLSA    3 1 1 0D1FCBD71686199607A...

    $ dig +noall +ans -t tlsa _587._tcp.open.nlnetlabs.nl
    _587._tcp.open.nlnetlabs.nl. 10200 IN   CNAME   3.1.1._dane.nlnetlabs.nl.
    3.1.1._dane.nlnetlabs.nl. 10182 IN      TLSA    3 1 1 0D1FCBD71686199607A...

I have started the implementation of DANE TLSA support for Postfix
2.11, the plan is to map 1/3 to the "fingerprint" security level
(trust a specified EE cert) and 0/2 to the "verify" security level
(trust a specified set of CAs).

With 0/2, naturally the certificate peer name binding asserted by
the CA will be checked against the DNSSEC validated MX hostname.
With 1/3 it will not, there is no reason to fail when success is
an option.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 5 Mar 2013 02:25:15 +0000

> For types 0, 1 and 2 - the DANE check is in addition to ALL existing PKI

So the client validates two separate cryptographically signed name
bindings (DNSSEC and EE cert contents), just to maximize the odds
of failure?  Why?  What is gained by such checks?

Does the group believe that in practice most TLS applications do
CRL and/or OCSP checks and it is operationally easier to publish
a timely revocation via a public CA than to maintain sensibly short
RRSIG time limits and update one's own DNS when a key is lost?

If this is not the case, then why doubt the DANE binding?

[ One data point if you like: though Postfix has supported TLS for
  a decade, it doesn't and won't have CRL or OCSP support, but it
  will soon have DANE support. ]

> include the name matching check.

Thanks, I hope this is the consensus view of the working group.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Mar 2013 19:04:50 -0800

> of failure?  Why?  What is gained by such checks?

The asserting party doesn't have to worry about a rogue CA.

BTW: you probably misunderstood Jim's shorthand for type 2: there are no PKI checks because it is a trust anchor.

> If this is not the case, then why doubt the DANE binding?

I'm not sure anyone suggested trusting the DANE binding.

> Thanks, I hope this is the consensus view of the working group.

Nothing in the RFC indicates that the relying party would do name binding for type 3, I hope.

--Paul Hoffman

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 4 Mar 2013 22:06:33 -0500

> Sent: Monday, March 04, 2013 9:25 PM
> To: [email-masked]
> > For types 0, 1 and 2 - the DANE check is in addition to ALL existing
> > PKI checks.
> 
bindings
> (DNSSEC and EE cert contents), just to maximize the odds of failure?  Why?
> What is gained by such checks?

Yes - we want to maximize the security checks that are done.  In this case
the DANE checks are additional checks.  If you don't like it - don't use
these values.

> 
> Does the group believe that in practice most TLS applications do CRL
and/or
> OCSP checks and it is operationally easier to publish a timely revocation
via a
> public CA than to maintain sensibly short RRSIG time limits and update
one's
> own DNS when a key is lost?
> 
> > For type 3 - I would agree that no PKI checks are to be done.  That
> > would include the name matching check.
>

---

From: [email-masked] (Martin Rex)
Date: Tue, 5 Mar 2013 05:14:32 +0100 (CET)

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

I have a very very very bad feeling about this.

Making a server cert for a server in DNS zone example.org succeed a
name check for DANE usage type "3" might be as simple as creating
such a cert with a "CN=*.example.org".

Sending out the message that there are conditions when the name should
be entirely ignored by TLS clients will cause creation of more new problems 
(and less of the existing problems getting fixed) in the long run.

  e.g. https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html

It will also make it much harder to go from DANE usage 3 to DANE usage 2.

And it might cause users to ignore names and other cert attributes,
because most users will not understand the difference for name validation
between DANE usage 0,1,2  and DANE usage 3.

-Martin

---

From: Paul Wouters <[email-masked]>
Date: Mon, 4 Mar 2013 23:34:27 -0500 (EST)

> the baggage of the legacy public CA PKI.

While I also dislike the name check, which should not be required or
looked at for non-CA use, it is not hard to generate a wildcard
certificate.

> into new protocols except as an optional transition aid.

While I agree here, it is kinda strange to put in a selfsigned
generated cert in DNS. If you go through the effort of putting in
a TLSA, you can also generate a proper cert for the mailserver?

> (binds the service end-point to an EE certificate), that binding

local policy :)

> MTAs (bare minimum extensions to support TLS key usage).

Loking forward to bare public key support in gnutls :)

Then there is no name binding, so everyone is happy!

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 5 Mar 2013 05:59:35 +0000

> > The asserting party doesn't have to worry about a rogue CA.

Yes, of course, with 0/2. With 1, the asserting party told the
client *exactly* which certificate to expect. That's it game over.
With the EE certificate pinned-down, who cares about the name
asserted by the CA. What concrete threat does the name check avert?

It is not enough to "feel more secure" with the extra check in
place, that looks like security theatre, there must actually be a
real use-case in which the client avoids an attack by checking the
CA asserted name.  What is that use-case and attack?

The only plausible use-case I see is that the PKIX CA checks
facilitate revocation support, if one believes that revocation via
public CAs is easier than removing records from DNS in a timely
manner. Revocation checks are just as effective without the name
check being performed.

> I have a very very very bad feeling about this.

Scars from the beatings of X.509? My response "doctor it hurts when
I do that" is the usual one.

> such a cert with a "CN=*.example.org".

How many domains will have domain names in certs that will be raw
UTF-8 rather than encoded as Punicode IDNs? How many will have
multiple conflicting CNs? How many client applications won't support
"*" wildcards or will vary in whether "*" means arbitrarily deeply
nested hosts or just hosts in the immediate domain?

> (and less of the existing problems getting fixed) in the long run.

In the long run, good riddance to the existing public CA PKI.

>   e.g. https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html

bugs due to complexity we have the opportunity to reduce.

> It will also make it much harder to go from DANE usage 3 to DANE usage 2.

This claim deserves evidence.  Self-signed certs will need to be replaced
to switch from 3 to 2 whether or not the self-signed cert bears a name.

> between DANE usage 0,1,2  and DANE usage 3.

Users should not be burdened with understanding certificates at
all.  With DANE, the application simply makes a secure connection, or
fails.  Users won't be revalidating DNSSEC RRSIGS in their heads,
computing SHA256 checksums, ...

DANE will make TLS security scale, and asking users to trust
certificates signed by "Honest Achmed's Used Cars and Certificates"
will fade into distant memory.

	https://bugzilla.mozilla.org/show_bug.cgi?id=647959

Does anyone have a real example in which a validator that ignores
the CA signed name with certificate usage 1 (but not revocation, ...)
faces a new tangible risk they don't face if they perform the name
check?  If there are no such examples, no RFC should compell the
TLS client to check the (inside the cert) name bindings from the
issuing CA in cert usage 1.

[ FWIW, I'm still planning to ignore names with 1/3 in Postfix, as
  the suggested checks seem to have only negative value (they may
  fail) without redeeming features (they may avert a real threat). ].

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 5 Mar 2013 06:11:46 +0000

> looked at for non-CA use, it is not hard to generate a wildcard

Not all applications understand wildcard certificates, or even
correctly parse certificate content.

When the Moxie Marlinspike embedded NUL attack on CA name bindings
was published, Postfix was one the few applications not impacted,
since I already anticipated this problem and Postfix already had
checks for embedded NULs in ASN.1 strings.

The moral of this anecdote is not that the Postfix developers go
the extra mile, but rather that X.509 is a very complex standard
with many pitfalls, and anything that makes the application's job
easier is a big win. 

The easiest way to check that you have the right certificate is to
not parse it at all, or parse it just enough to extract the public
key (this is generally directly supported by the SSL toolkit), and
then just compare that or a digest of it to the value bound by DANE.

The simplicity of the DANE binding leaves PKIX with its horde of
trust anchors, local versions of intermediate certs, servers that
fail to present all intermediate certs, depth limits, expiration
date arithmetic, name constraints, multitudes of name types,
critical extensions, ... in the dust.

It is almost a miracle anyone ever gets X.509 validation right.
>From the X.509 mess we get as many opportunities for insecurity as
opportunities for enhanced security.

> a TLSA, you can also generate a proper cert for the mailserver?

It is a historical accident (naive MIT senior thesis in the early
80's IIRC) that we're using publica CA PKI at all. We might have
had keys in DNS a lot sooner if X.509 were not an expedient crutch
for a while.  IMHO DANE provides a mechanism to bind service end
points to public keys disguised as EE certificates only because we
need to work with the current installed base, not because there is
inherently something compelling about the existing "PKI".

> Then there is no name binding, so everyone is happy!

Hooray, there is no name binding *inside the  X.509 certificate*,
but the real name binding (DNSSEC TLSA record) remains.

-----

Speaking of name bindings, it would perhaps be useful to have DANE
support for SMTP clients that are MTAs (not people using MUAs) to
use client certificates to authenticate their EHLO names to servers.

Since clients are not a _port._tcp.<hostname> endpoint, we'd need
some fixed prefix (_smtpc for smtp client?) that would allow the
receiving MTA to check the DNS for:

	_smtpc._tcp.<ehloname> IN TLSA

and verify the client's identity. This would enable scalable
TLS-based client authentication without public CAs.  This supports
various outsourcing arrangements in which content provider or email
hosting service relays mail through a client's gateway for DKIM
signing, compliance archiving, ...

But this is a different thread, for another day.

-- 
	Viktor.

---

From: Tom Ritter <[email-masked]>
Date: Tue, 5 Mar 2013 11:08:29 -0500

I think that name checks MUST be performed when validating
certificates marked with usage 1. (And 0 & 2 obviously)

Whatever your feelings on CAs are, DANE includes options to use them,
and to assert that a certificate is valid within the CA system.
Making name checking optional for Usages 1 means that a certificate
*may not be valid* through the CA system but is still accepted.  Thus
I feel it violates the intention of the RFC with regards to Usage 1:
To assert validity through BOTH DNSSEC and the CA system.

> issuing CA in cert usage 1.

Stated simply: No, not today. (Because if you can change the record
you could change it to Usage Mode 3)

But I don't think that DANE in isolation is the only thing to
consider.  I think you should also consider how it can interact with
other policy mechanisms.  DANE, HSTS, Public Key Pinning, Content
Security Policy - these are all mechanisms to assert that a site
desires a certain security policy and asking the client to enforce it.
 Usage Modes 0 & 1 state "In addition to my policy here, you should
follow this other (admittedly nebulous) policy." Ignoring name
checking in 1 breaks that statement.

Consider a situation where a domain asserts, through a new policy
mechanism[0], that it ONLY wishes to use Usages 0 or 1 with the
intention of requiring a validity assertion through both systems.
It's a simple fact: it's harder to hack two unrelated systems than it
is to hack one. So if I recieve a DANE Usage mode of 2 or 3 - I ignore
it, because that's invalid, someone must have hacked my DNS.  Ignoring
name checking in 1 breaks that new policy mechanism.

> In the long run, good riddance to the existing public CA PKI.

Lots of people expressed that opinion, but the rough consensus model
showed us that there was support for both supporting the CA model in
Usages 0 and 1 and doing without it in Usages 2 & 3.  Disabling name
checking in Usage 1 feels like trying to give that rough consensus a
run-around and invalidate what was decided with regards to Usage Mode
1.

-tom

[0] As an example: https://domainpolicy.org/

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 5 Mar 2013 18:29:26 +0000

> certificates marked with usage 1. (And 0 & 2 obviously)

Thanks Tom, I think you give a clear explanation for the
position that 1 means name checking. So I'll try to state
my final objection in-line, and leave it at that...

> To assert validity through BOTH DNSSEC and the CA system.

I agree only to the extent that the intension has a rational basis
in added security. If we compel the client (via MUST name check)
to reject some certificate, there must be a real reason for this,
otherwise we're just breaking valid connections because it feels
more PKI compliant.

I have a proof that no such rational basis is possible, see below.
It seems we're mistaking a server SHOULD (have a certificate with
a matching name) for a client MUST (check for such a name), which
limits flexibility and likely offers no additional security.  This
is I think the result of an incomplete threat model analysis.

> you could change it to Usage Mode 3)

Lemma. If the attacker has compomised the DNS to the extent that
he can sign new RRsets that the domain owner never signed, he wins,
whether the client checks names or not.

	Proof 1: The attacker publishes a 3 1 1 usage for a new
	certificate of his choice, and even puts in the right name,
	though name checks in usage 3 are not needed.

	Proof 2: The attacker publishes a 2 1 1 usage for a new
	issuing CA of his choice, which signs a new certificate of
	his choice which bears the right name.

Note 1: Such an attacker can subvert all other DNSSEC validated
policy, so if there is anything in DNS published by the compromised
domain that asserts that the domain never issues valid 2/3 TLSA
records and always uses 0/1, this too can be subverted by the
attacker, so it is not clear how say DPF would mattter.

Note 2: How many potentially overlapping policy sources do we expect
a DANE-aware client to consult? MUST a DANE-aware MTA also implement
the future DPF, and then later yet another policy source? Surely
complying with the semantics of TLSA records should not be a game
of RFC whack-a-mole!  Must I hold-off implementing DANE in Postfix
until DPF is published, what else must I wait for?

Corollary. Any justification for name checks must assume the attacker
is not able to generate fraudulent TLSA records for the target
domain.  Therefore, in any attack thwarted by name checks the client
acts on authentic (possibly stale, but not yet expired) TLSA records
for the target domain.

Proof:
Since we're considering whether client name checks in usage 1 thwart
active attacks, we focus on an authentic usage 1 RR signed by the
target domain.  When such an authentic record was issued, it
legitimately bound the end-entity certificate to the service.
Therefore, the certificate in question was the right one at that
time.  It was at that time properly signed by some public CA, and
bound by the domain owner to the service in question.

If the binding was once valid for the given service, and is not
yet expired nor is the TLSA RR expired, to make it invalid one must
revoke the certificate.  PKIX trust chain validation gives us
revocation checks and expiration checks.  Therefore, there is
nothing to be gained from name checks, as the name in the certificate
is immutable.	Q.E.D.

Comment:
The name check only serves to bind the hands of the domain owner.
If name checks are mandatory on the client, the client must reject
the EE certificate even though it was authentically bound to the
service by the domain owner via DANE.  This limits the domain owner
to deploy said certificate only on the hosts originally anticipated
when the certificate was obtained.

Example:

Consider an expensive 2-year certificate for mail.example.com, for
a then small business which hosts POP, IMAP and inbound MX on a
single host.

The business has a good year and grows to the point that it makes
sense to separate the MX host from the POP/IMAP service.

The POP/IMAP MUAs predominantly do traditional PKI, so the
mail.example.com name and certificate stay with the new mailbox
host.  Most MTAs on the other hand do opportunistic TLS at best,
but some business partners already have explicit SMTP TLS security
policy to connect to and verify mail.example.com.

The business wants to improve mail security and use DANE to allow
more partners to deliver email securely. So it makes sense to
publish a 1/1/1 TLSA record binding mx.example.com to the existing
certificate which still has 1 year of validity.  This is thwarted
by Tom's reading of the consensus interpretation. :-(

I don't see any reason for DANE to prevent the domain owner from
binding the still valid mail.example.com certificate to the new
mx.example.com (split-off host) via a 1/1/1 TLSA record.

Gut feeling is sometimes just indigestion. :-) What rational basis
do we have to exclude this and other related use-cases?

-- 
	Viktor.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 5 Mar 2013 13:45:49 -0500

> whether the client checks names or not.

If the attacker actually has control of the domain, all bets are off.
I fail to see how this is an interesting case.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 5 Mar 2013 19:09:14 +0000

> I fail to see how this is an interesting case.

It is not, we agree, I am ruling it out for the record.

My argument boils down to:

- If the domain owner never generates TLSA 1 records for end-entity
  certs whose name does not match the <fqdn> in:

	_port._proto.<fqdn> IN TLSA 1 ...

  the the client check never fails and is therefore redundant (for
  those domains).

- If the domain owner does generate an authentically signed
  a TLSA 1 record:

	_port._proto.<fqdn> IN TLSA 1 ...

  with <fqdn> nowhere to be found in the cert, we should take the
  the domain owner at his word. There's no attacker here, just a
  domain owner who wants to bind an existing end-entity certificate
  to a new host, he chooses 1 rather than 3, as he believes that
  the CA he paid money adds some value via e.g. OCSP support allowing
  the certificate to be revoked.  (As noted in a parallel thread there
  is no revocation for TLSA).

The choice should be up to the server owner, and there is no reason
for the client (really clients collectively by enforcing name checks
in sufficient numbers) to take away this choice. The domain owner can
still make the choice by never binding mismatched names. I claim that's
where the choice ought to be made.

-- 
	Viktor.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 5 Mar 2013 14:21:00 -0500

On Tue, Mar 05, 2013 at 07:09:14PM +0000, Viktor Dukhovni wrote:
> in sufficient numbers) to take away this choice.

I think this boils down to the usual philosophical issue about whether
the party whose interests are to be most protected is the client or
the server.  My own view is that it is entirely legitimate for the
client to be in control here, because it is never possible for a
server to assert anything that a client must do.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 5 Mar 2013 20:00:08 +0000

> server to assert anything that a client must do.

This is a flippant response.  Sure, the client can chooose to not
implement DANE, or choose to misimplement it by adding 1 mod 4 to
each cert usage and to take the bitwise complement of each digest
value.  Or any other number of crazy things.

This thread is about the semantics of the TLSA "1 x y" RR (and the
hopefully settled "3 x y" RR), and whether such records are
potentially valid when the DNSSEC fqdn after _port._proto is not
listed as a SAN or CN in the certificate.

The semantic validity of such RRs is moot if client implementations
(guided or perhaps misguided by RFCs) reject the target EE certificate.

If such RRs, when intentionally created by domain owners, are to
be given the chance to be useful, then clients that do choose to
implement DANE must not enforce name checks on 1/3 EE certs. Name
checks are only unavoidable when there is no explicit EE cert at
hand, and all we have is an issuing CA and so are forced to check
that we have the *right* EE cert by comparing names.

When an EE cert is given a priori, trust chain validation boils
down to making use of a revocation service for said EE certificate.
This is the difference between 1 and 3 that follows from a security
analysis.

We can attempt to more completely mimmic legacy public CA PKI
certificate validation and remove the choice I advocate, but that
would be unfortunate, since it would needlessly only serve to limit
the choices available to domain owners.

There is nothing in the legacy public CA model that looks like
usage "1" with an a priori given EE certificate, therefore it is
not an axion that certificate validation (which always had two
parts: trust chain checks often in SSL libraries, and name checks
often at the application level) should look the same in this new
case.

Is it reasonable to continue to advocate my interpretation based
on logic and consideration of security models? Or is it the group's
view that structural similarity to existing legacy CA PKI practices
trumps logical analysis? [ Cargo-cult security at the IETF? I hope
not! ] Or is "the die cast" and it is simply too late to clarify
the ambiguity in section 4 of 6698.

At the very least, I hope updated dane-srv and dane-smtp drafts
and final RFCs will not mandate name checks for "TLSA 3 x y", so
this thread won't be entirely hot air.  I also hope that the
group will consider clarification the 0/2 1/3 feature matrix:

	High bit:	PKIX trust chain validation
	Low bit:	EE certificate, hence no name checks

if nothing else this is a more orthogonal feature matrix. As
I tried to show it supports reasonable additional use cases
and opens no new attack vectors.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Tue, 05 Mar 2013 14:57:31 -0500

Types 0 and 1 were included because some expressed interest in
continuing to rely on the existing PKI, but with extra confirmation
from DANE.  They very much wanted to have the TLSA only as an added
check, hence the language in the rfc and many of the replies in
this thread.

Which is why, when I agreed that ignoring the CN and subjectAltName
certainly makes sense for type 3, I didn't comment on type 1.

I think that the type 0 and 1 supporters feel that keeping the
tlsa as only an extra validation is more important than any other
consideration.

Skipping the name checks with type 1 doesn't bother me, and will
not stop me from continuing to use pf or from enabling the tlsa
lookups (if it is to be configurable).

But I can understand the positions and motives of those who want
complete adherence to the legacy pki model when using tlsa type 1.
Even though I strongly prefer the type2/type3 model.

-JimC

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 5 Mar 2013 20:23:33 +0000

> tlsa as only an extra validation is more important than any other

And yet logic leads us to observe that since the choice of certificate
usage type is made by the domain owner and not the client, the
domain owner gets exactly the desired semantics by never generating
TLSA "1 x y" RRs where the name inside the cert is not the host
fqdn.  The client name check is then always redundant, since the
certificate always matches.

We can create additinal space for domain owners that want to choose
1, but don't want to consume the full legacy PKI banquet, they just
want the revocation support main-course. They should be able to do
so by generating non-matching (different name inside the cert) TLSA
"1 x y" records.

This way everyone is happy.  Why should the domain owner's choice
to be constrained by clients given that the domain owner, who
defines TLSA records can equally publish 0, 2, 3 or other future
certificate usages at their pleasure?

I would like to suggest that the substance of TLSA being an additional
check in 0/1 is completely retained when name checks are optimized
out with 1 (as with compiler optimization of constant expressions),
since the name checks would always succeed if made for domains
that want this. To quote the Mikado:

    It's like this: When your Majesty says, "Let a thing be done,"
    it's as good as done---practically, it is done---because your
    Majesty's will is law. Your Majesty says, "Kill a gentleman,"
    a gentleman is told off to be killed. Consequently, that
    gentleman is as good as dead---practically, he is dead---and
    if he is dead, why not say so?

No name checks need to happen, because they automatically match
for the domains that want name matches, and never match for those
that don't.
 
-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 5 Mar 2013 21:23:37 +0000

On Tue, Mar 05, 2013 at 08:23:33PM +0000, Viktor Dukhovni wrote:

> that want this.

I think the above the best and final argument. The domain owner
can perform all 1/3 name checks *statically* at the time at which
the TLSA record is generated. This frees the client from performing
the name checks *dynamically* since RRs whose FQDN is not compatible
(in the domain owner's eyes) with the EE certificate will never be
generated.

By specifying *static* (the domain owner does these when the TLSA
record is generated) rather than *dynamic* name checks the DANE WG
can enable new use-cases where the domain owner is free to associate
an EE certificate with a new FQDN not originally included among
the signed names in that certificate.

I can help draft suitable revised language for section 4 of 6698
and/or an accompanying rationale, example use-cases, ...

The only thing I can't do unfortunately is travel to IETF meetings,
for lack of free time and sponsorship funds.

-- 
	Viktor.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 5 Mar 2013 17:29:18 -0500

On Tue, Mar 05, 2013 at 08:00:08PM +0000, Viktor Dukhovni wrote:
> 
> This is a flippant response.

I don't.

>  Sure, the client can chooose to not

That's not my point.  My point is rather that you seem to want the
server to be the boss here, and I don't think that's reasonable.

> (guided or perhaps misguided by RFCs) reject the target EE certificate.

I don't think it's misguided.  The point of this feature in the
specification is for the server operator to be able to declare, "Oh,
and by the way, the certificate I offer you in the DNS is the one you
ought to be validating according to the traditional CA certificate
chain, not other ones."  At that point, the client gets either to use
traditional CA validation without TLSA, or to use TLSA to perform
additional validation beyond what would be done with the traditional
CA chain.

> be given the chance to be useful

For the use case, they're not useful.  If you want this additional use
case, why not create a new type?

> the choices available to domain owners.

It's not needless.  It's part of the design of this feature.

> trumps logical analysis?

I think it's wonderful when people present false dichotomies in their
arguments in the form of rhetorical questions, but it doesn't make the
position any more reasonable, no.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tom Ritter <[email-masked]>
Date: Tue, 5 Mar 2013 18:40:36 -0500

> attacker, so it is not clear how say DPF would mattter.

DPF was an example for me, not a lynchpin of my argument, but I'll say
that a component of DPF was allowing a policy on a root tld (e.g.
.secure) like "only allow Usages 0 and 1, and require TLS 1.1 or
above" and a domain in .secure (whether a legitimate or a hacked one)
could not override the policy.

> until DPF is published, what else must I wait for?

Of course not.  Any security mechanism: DPF, DANE, or TLS is an
optional thing for anyone to implement.  RFC whack-a-mole is a reality
we must live with.  TLS, TLS1.1, TLS1.2, AES-GCM, AES-CCM, DANE, HSTS,
HPKP, so on and soforth. Caring about security, I'd like everyone to
implement all the relevant mechanisms as soon as possible, but it's
always been the prerogative for implementers to ignore or alter
standards in their implementations.  The goal is for you to see value
in a standard and want to implement it.  If you don't see value, we've
failed as standards-creators or as evangelists.

DPF could complement DANE by removing components of it that people
feel nervous about, just as it could complement TLS by removing
components people feel nervous about (requiring strict revocation
checking, requiring TLS >1.1, etc).  But I would never imply that it
is a MUST-implement for a DANE (or anything-else) compliant
implementation.

I don't think formal proofs work well in things aside from math,
because we'll wind up arguing over what is a valid assumption and what
is not.

> acts on authentic (possibly stale, but not yet expired) TLSA records

I do not assume that, I assume the attacker CAN generate fraudulent
TLSA records, but is constrained by a higher-level Domain Policy that
disallows usages 2 & 3.  He can repoint the A record, he can make a
new TLSA record, and he can create a Usage 2 & 3 but those won't be
accepted.

The attacker is not able to compromise a CA. With name checking the
attack is thwarted, without it is not.  Q.E.D. (Or something.)

> do we have to exclude this and other related use-cases?

My rational basis is that a certificate for mail.example.com is not a
valid, CA signed certificate for mx.example.com.  It may be a valid
CERTIFICATE for the domain, but it is not a valid CA-signed
certificate.  To claim it is would be to state something untrue, just
as if I were to say that my certificate for ritter.vg is a valid CA
signed certificate for https://fuckyoulookatthiskitten.com[0].

There are a multitude of ways to allow those machines to interoperate
with the businesses that violate standards or best practice - such as
disabling certificate validation entirely.  I think this is another
example.

[0] pardon the expletive, I just wanted to use a domain I actually control

On 2 March 2013 13:20, Viktor Dukhovni <[email-masked]> wrote:
> certificate, we already have a binding and name checks

We have ONE binding (DNSSEC) we do not have ALL the bindings for
option 1: the valid Certificate Authority check.  Checking the name is
a required part of being "valid according to CAs rules".

> One simple design rule I try to adhere to is: "don't fail when

I try to adhere to the opposite when regarding network protocols:
assume malice and untrustworthiness until proven otherwise.

> view that structural similarity to existing legacy CA PKI practices

We disagree, but I resent being told my arguments are not logical.
Your arguments make excellent sense, I just think you're dismissing
something I care about.

> this thread won't be entirely hot air.

I agree, they should not.

I'll try to state my point succinctly, and leave it at that...

Although DANE mechanisms 2 & 3 allow bypassing CA checks, an alternate
security policy may disallow usages 2 & 3 and require 0 or 1.
Eliminating name checking for usage 1 nullifies the point of usage 1,
because it is trivial to get a valid CA-signed cert for *some* domain
- it is equivalent to usage 3 at that point.  I see no reason to
require name checking for usage 3.

-tom

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Mar 2013 00:09:52 +0000

> It's not needless.  It's part of the design of this feature.

If the meaning of the design is not crystal clear in the RFC (e.g.
the dane-srv draft misread 6698 at least in part), and I am
challenging the rationale used to justify a putative interpretation,
telling me that is so by design merely begs the question.

The feature (certificate usage "1") gives the domain owner a
mechanism to express a policy preference for PKIX validation
constrained to a given EE certificate. The name check part of this
policy can and should be carried out by the domain owner statically
before the TLSA RR is signed (if that's what the domain owner
intends).

Why delegate this (ostensibly important to the domain owner) policy
check to the client, if it can be performed exactly once when the
TLSA RR is about to be generated?

A substantive answer would explain why static name checks by the
domain owner are insufficient and why it is better to defer the
static checks in favour of dynamic checks by clients.

Such a subtantive answer should take into account evidence to the
effect that static-only checks support use-cases not supported by
dynamic checks with no detriment to the use-cases in which static
and dynamic checks are functionally equivalent (provided clients
never fail to carry out the dynamic checks).

I think that section 4 of 6698 should be clarified to explain
where name checks are appropriate and *who* should carry them
out. I further posit that for 1/3 usage the *who* in question
is the domain owner alone.  If the working group does not agree
with this analysis on logical grounds, please tell me why.

If you concede my point, but the standard is set in stone and
sufficiently clear on this point, and it is too late to clarify or
amend, fine there are other imperfect standards.

The only reason I'm tilting at this windmill is that it seems
that the standard is not yet clear, and it could be clarified
in a more fruitful direction.

In addition the implementation of the standard in Postfix would be
more natural if all a priori given EE certificates were treated
identically with regard to name checks. Check that we have the
right cert because either we knew which one to expect (1/3), or
because the CA provided a name binding (0/2).

The interpretation presented by Andrew and others asks for a hybrid
model, which I am loathe to implement. It does not pass:

- Don't fail when you can succeed.
- Don't do dynamically what can be cheaply+reliably done statically.

If there is still any opportunity to reconsider the issue, please
examine my suggested interpretation on its merit.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Mar 2013 01:27:36 +0000

> new TLSA record, and he can create a Usage 2 & 3 but those won't be

If that's a real concern, and what we're getting from "1" is
verification of the endpoint in the face of a compromised DNSSEC,
when we can somehow securely obtain policy records that prohibit
2/3, then OK, this is a rationale for name checks in 1. Is this
essentially the actual rationale, or a retroactively plausible one?

We should consider what the above implies in the context of dane-srv
and dane-smtp.  Given that the DNSSEC controlling attacker can
freely change the name that is going to be verified, that is the
name of the MX host or SRV host:

	example.secure.	 IN MX   0 example.evil.
	example.evil.    IN TLSA 1 1 1 <public key digest>

the name the client is going to look for in the CA-issued certificate
(example.evil) is now under the control of the attacker. Can we
statically optimize out name checks in this case?

> attack is thwarted, without it is not.  Q.E.D. (Or something.)

With say, HTTP where the user entered the https://example.secure/
URL directly and something like the DPF policy you describe exists,
and ideally also constrains or specifies the trust anchors for the
gTLD.

> CERTIFICATE for the domain, but it is not a valid CA-signed

If we believe that the purpose of "1" is to thwart DNSSEC compromise
when the client is armed with additional policy that rejects 2/3
DANE certificate usages for the destination domain, OK, in that case
name checks for "1" make some sense, provided there are no pesky MX
or SRV records.

>  To claim it is would be to state something untrue, just

In my threat model, game over when DNSSEC is compromised, so the
certificate was signed by you at some point, and if that's the CA
certificate you want to use at https://FULATK.COM you're free to
do so. You paid the cert and get the benefits of the CA's certificate
revocation services.  It should not be DANE's job to protect the
CA's revenue stream by ensuring that a certificate for server X is
never deployed in server Y.

Is the model you present in fact expected to gain some traction?
Do we expect browsers to consult DPF?

How will DPF interact with SRV and MX records? Will ".secure" gTLD
domains be constrained to never generate SRV or MX records that
point outside the sandbox?

> Your arguments make excellent sense, I just think you're dismissing

You just gave a logical argument.  Thanks.  I don't recall seeing
anything as specific upthread.  If I missed it, apologies to the
poster.

> require name checking for usage 3.

If this is protecting against DNSEC subversion in the presence of
policy that partly overrides DANE, I agree. If this is protecting
against compromised server private keys, ... then the value of the
CA is just revocation support, in which case the name check is
redundant and can be performed statically by the domain owner.

So for Postfix (MTA to MTA SMTP), since we don't yet have DPF (and
may not in any case benefit from it given MX record indirection),
and don't have or plan to offer revocation checks or OCSP, the plan
is to simply ignore the CA bit and to treat each of 0/2 and 1/3 as
equivalent sources of either a trust anchor or an end-point
certificate.  This will substantially improve the security of email
delivery without substantially increasing the risk of email disruption
because the receiving domain's issuing CA is not locally trusted,
or some name check failed when the EE cert is available, ...

If it were up to me, I'd go further and in dane-smtp recommend that
administrators publish "TLSA 3 1 1" records (as in the case of
netlabs.nl) as the most likely to improve security without causing
delays from some senders due to verification glitches.  In some
cases the "3 1 1" cert may in fact be CA-issued, and some senders
will validate them via legacy PKI policy rather than DANE.

Since I'm sensing little support from this group for dropping name
checks in the "TLSA 1 1 1" use-case, email administrators will not
be able to leverage "TLSA 1 1 1" for revocation services, but this
is not a big loss, since few if any MTAs do revocation checks or
OSCP (most don't even offer correctly implemented name checks).

Thanks for your attention.

-- 
	Viktor.

---

From: Tom Ritter <[email-masked]>
Date: Tue, 5 Mar 2013 22:40:54 -0500

On 5 March 2013 20:27, Viktor Dukhovni <[email-masked]> wrote:
> Is this

Not retroactive, I am really concerned about situations where another
security policy (DPF, or organisationally local) trim what is
'acceptable' for DANE to 0&1.

Furthermore, I'll say specifically that I have argued because my
interpretation has been while you obviously are interested in the
mailserver side of things, that the argument applied to all DANE
checks...

> statically optimize out name checks in this case?

I will be the first to admit I'm not an expert in mail systems, and
will also add that you definitely know more about them than me.  In
this case, from what you're describing and from what I know (which is
limited) - it makes sense.  I obviously don't have to give you
permission in any case - I much prefer to say "Now that we're talking
specifically about mailservers, I don't know enough about it to give
an informed opinion in this matter."

> Do we expect browsers to consult DPF?

DPF is fledgling.  I *hope* DPF will be created and I *hope* browsers
will consult it.  I am also friends with the guy who's pushing DPF and
another venture (.secure).  They integrate well together, and while I
suspect you and a lot of folks won't like .secure (you can ping me off
list if you'd like to debate the merits) - I think DPF is cool, and I
am for it.

> point outside the sandbox?

I have *no idea*. I couldn't even conjecture intelligently. Sorry.
When that stage is reached, we'd love to get input on it.

> policy that partly overrides DANE, I agree.

That's all I was arguing.  Whoo-hoo! Common ground!

> or some name check failed when the EE cert is available, ...

I am all for opportunistic encryption of SMTP, and I think any DANE
entry (1 or 3) goes a very, very long way towards securing it.[0]
Thank you for working on it.

-tom

[0] http://ritter.vg/blog-no_email_security.html

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Mar 2013 06:54:50 +0000

On Tue, Mar 05, 2013 at 10:40:54PM -0500, Tom Ritter wrote:

> [...]

Yes, some common ground, which is good.

Though I must admit that with the logical bases for our positions
established, and a judgement call required to assess the pros/cons
of the implied trade-offs, I see the DPF rationale as a somewhat
nebulous corner-case that could apply to a small set of domains
that migrate into a walled-garden gTLD. For the bulk of .com and
.net domains, no protections against DNSSEC compromise will be
available in the form of constraints on DANE 2/3 from a parent
domain.

If this is the strongest reason to impose a MUST name check on
clients, and as a result one can no longer extend the utility of
an existing CA certificate when ones needs change in early in the
certificate's lifetime, where I at the WG meeting, I'd try to hold
my ground if there was some hope of getting support.

I'm not sensing much support here for my "static check" argument,
so I guess I'm done.

Thanks letting me air my views, I hope the WG will use whatever
useful insigths I may have provided for some good.

> Thank you for working on it.

Thanks, I hope to have working code by June and a Postfix snapshot
release some time after Wietse's had a chance to adopt it.

As for SMTP and SRV records, given the observations about unavoidable
reliance on DNSSEC security in choosing which names to check against
the certificate, I still contend that in protocols that choose their
peer indirectly, there is no reason to check names in 1/3, and so

should be revised to no only require name checks for 0/2 and to
suggest that clients accept the implied name binding via DNSSEC
TLSA for 1/3 without second-guessing it with certificate content
checks.  The fallback position which is less controversial is to
at least exempt 3.

Thanks again to Tony Finch for bringing the drafts to my attention,
I hope he is not sorry he did so (i.e. feel free to blame him for
my rants :-).

If Tony or anyone else wishes to discuss the specific use case of
SMTP+DANE or more generally SRV+DANE, I won't object to off-list
email.  I am happy to comment on proposed draft language, since I
have a stake in the outcome.

-- 
	Viktor.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 6 Mar 2013 14:08:48 +0100

> asserted by the CA. What concrete threat does the name check avert?

The '1' was deliberately designed, so it _is_ compatible with existing CA model and existing applications (DANE-aware and non-DANE-aware).  If you don't like that just use type 3.  (Or type <n> when bare TLS certificates are out.)

If you want to be compatible with DANE, I would suggest to implement the protocol as is, pretty please.  (On the other hand, the existing MTA implementations don't give a damn about existing standards, so it will be status quo anyway.)

O.
--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 6 Mar 2013 14:18:57 +0100

> examine my suggested interpretation on its merit.

I don't think there is still the opportunity to reconsider this within existing DANE protocol.  What we might do in the future:

- define new types (like the one for bare SPKI)
- obsolete old types

But if we want to keep our sanity, we should keep to only one interpretation of existing types.  No matter how hard you push and how many times you repeat your position (you already did too many times).

Don't get me wrong, I am literally jumping from a joy that Postfix will have DANE support.  That's what we are all waiting for, but there's one good thing the standards and their uniform interpretation is good for – the compatibility and interoperability.

I cannot tell you how you should implement DANE in the Postfix and from pure technical viewpoint your implementation ignoring names in type 1 will make no big difference, but at least please document the implementation differences from DANE protocol properly in the Postfix documentation.

Ondrej

---

From: Paul Wouters <[email-masked]>
Date: Wed, 6 Mar 2013 09:48:57 -0500 (EST)

> critical extensions, ... in the dust.

While I agree with most, the future to do this right is to use TLS with
raw public keys:

http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-07

That creates a "certificate" with just the SubjectPublicKeyInfo blob.

I welcome postfix to be an early adopter of that draft :)

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Mar 2013 17:20:02 +0000

On Wed, Mar 06, 2013 at 02:08:48PM +0100, Ond?ej Sur? wrote:

> If you want to be compatible with DANE, I would suggest to
> implement the protocol as is, pretty please.

The implementation will be fully *interoperable* with DANE as
specified.  The Postfix SMTP client will however be more liberal
than the spec in its interpretation of certificate usages 0 and 1.

Specifically:

    - 0 will be read as 2 with a "CA constraint" interpreted as a
      "trust anchor assertion".

    - 1 will be read as 3 with a "service certificate constraint"
      interpreted as a "domain issued certificate".

    - No trust-chain validation will be performed above the trust
      anchor in the conflated 0/2, or at all in the conflated 1/3.

    - MTA administrators will be strongly encouraged to publish
      "TLSA 3 1 1" RRs in preference to any other kind. This
      eliminates most opportunities for failure with no reduction
      in security.  I would like to see this best-practice advice in
      draft-ietf-dane-smtp, and any final resulting RFC.

The working group will I hope understand that in some application
areas considerations beyond the literal text of the DANE RFC may
dictate similar choices, and that as a practical matter it is
important to not erect needlessly high adoption barriers when the
cost of absolute RFC adherence is high, and the benefit is low or
absent.

The above decisions will be clearly documented, together with a
detailed rationale.  They will not cause any interoperability
issues, and will eliminate many opportunities for mail delivery
between sites failing for avoidable reasons, including:

    - Some over-worked and under-trained sysadmin assumes that his
      issuing public CA is on everyone's list of trusted public CAs.
      Browser users can click-through the warnings, but sending MTAs
      are not interactive applications and mail delivery will fail.

    - Some over-worked and under-trained sysadmin configures a trust
      chain that includes only the leaf certificate without intermediates.
      They specify "TLSA 1 x y" in DANE, but mail delivery fails because
      the sending MTA can't do the PKIX check.

    - Some over-worked and under-trained (Azure cloud?) sysadmin forgets
      to renew a certificate that is published as "TLSA 1 x y" in DANE.

    ...

Of course some similar and related problems will remain, most
notably failure to re-sign a DNSSEC zone in a timely manner and
dropping off the Internet for all DNSSEC-aware recursive resolvers.

Stil, on the whole DANE adoption will go much more smoothly without
avoidable service disruption barriers.

As you've all tired of hearing by now, in the case of MTA to MTA
traffic, given indirection through DNS MX records, the security of
DNSSEC is an unavoidable foundation with no opportunity for CAs to
provide an additional *independent* validity assertion.  The best
that CAs can do is provide revocation support, but the code and
operational cost of implementing this in an MTA is prohibitive.

So PKIX public root CAs do not add any value beyond serving as
potential trust anchors in a "TLSA 2 x y" or "TLSA 0 x y" RR.

A non sado-masochist MTA developer will not subject his users to
frequent avoidable outages and himself to a flood of "the MTA is
broken" help requests just to adhere to the letter of an RFC when
adhering only to its essential elements will not expose users to
any new risk.

Widespread DANE adoption would be a giant leap forward in email
security, let's hope DANE is a sufficient carrot to encourage users
to endure the pain of deploying DNSSEC.

> (On the other hand, the existing MTA implementations don't give
> a damn about existing standards, so it will be status quo anyway.)

[ Note to self: don't feed the trolls. ]

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 6 Mar 2013 12:44:37 -0500 (EST)

On Wed, 6 Mar 2013, Ondřej Surý wrote:

> If you want to be compatible with DANE, I would suggest to implement the protocol as is, pretty please.

But since HASTLS seems dead, please interpret "TLSA record present" as
"don't deliver without TLS"

*ducks*

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Mar 2013 18:20:17 +0000

> I welcome postfix to be an early adopter of that draft :)

This is very unlikely to be implemented in Postfix. It is predicated
on an API change in OpenSSL to allow it to return bare public keys
for the peer certificate.  Users will still need to generate and
configure X.509 certificates, and there is very little upside for
this proposal in existing applications that don't start life as
public-key only TLS applications.

For the forseeable future, it is much more practical to just create
minimal certificates that essentially consist of just the public
key. With ECDSA and SHA256 the DER cert is just 275 bytes vs. 91
bytes for the associated public key.  While an extra 184 (less
overhead for the new extension) bytes on the wire could be avoided
it sure is a lot of new code in libraries and applications to save
a small amount of extra packet payload.

Example via bash(1) with its subprocess file-descriptor arguments:

  $ (
	umask 077; tmp=$(mktemp .pem.XXXXXX); dst=cert+key.pem
	openssl req -new >> $tmp \
	-newkey param:<(openssl ecparam -name prime256v1) \
	    -nodes -keyout /dev/stdout \
	-x509 -sha256 -set_serial 1 -subj "/" -days 3650 -config <(
	    printf "[req]\n%s\n%s\n[dn]\n[x509]\n%s\n" \
		"distinguished_name=dn" "x509_extensions=x509" \
		"extendedKeyUsage=serverAuth,clientAuth") &&
	mv $tmp "$dst" &&
	openssl x509 -in "$dst" -text | tee /dev/tty |
		openssl x509 -outform DER | wc -c &&
	openssl pkey -in "$dst" -pubout | tee /dev/tty |
	    openssl pkey -pubin -outform DER | wc -c
    )
    Generating a 256 bit EC private key
    writing new private key to '/dev/stdout'
    -----
    Certificate:
	Data:
	    Version: 3 (0x2)
	    Serial Number: 1 (0x1)
	    Signature Algorithm: ecdsa-with-SHA256
	    Issuer:
	    Validity
		Not Before: Mar  6 18:14:15 2013 GMT
		Not After : Mar  4 18:14:15 2023 GMT
	    Subject:
	    Subject Public Key Info:
		Public Key Algorithm: id-ecPublicKey
		    Public-Key: (256 bit)
		    pub:
			04:be:d4:d6:18:d0:6a:55:b2:17:1f:53:18:02:a6:
			47:c1:f1:10:bb:df:a8:04:12:6b:f7:4b:b9:a7:21:
			97:83:31:c4:78:84:c1:9d:be:b5:16:09:0d:b5:04:
			f6:92:99:92:3a:e3:1d:2d:62:48:17:08:47:c1:05:
			43:ad:d2:3f:61
		    ASN1 OID: prime256v1
	    X509v3 extensions:
		X509v3 Extended Key Usage:
		    TLS Web Server Authentication, TLS Web Client Authentication
	Signature Algorithm: ecdsa-with-SHA256
	    30:45:02:20:6c:5f:21:3c:c6:09:c6:09:7b:07:55:da:94:4d:
	    16:0a:f8:7b:99:20:51:54:30:c3:48:87:43:45:0c:08:e1:00:
	    02:21:00:d8:2d:39:9d:08:7d:5f:22:ab:db:2e:3a:d2:ff:1d:
	    1e:73:bc:88:45:77:58:64:24:ea:c7:9f:b0:0e:97:be:41
    -----BEGIN CERTIFICATE-----
    MIIBDzCBtqADAgECAgEBMAoGCCqGSM49BAMCMAAwHhcNMTMwMzA2MTgxNDE1WhcN
    MjMwMzA0MTgxNDE1WjAAMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEvtTWGNBq
    VbIXH1MYAqZHwfEQu9+oBBJr90u5pyGXgzHEeITBnb61FgkNtQT2kpmSOuMdLWJI
    FwhHwQVDrdI/YaMhMB8wHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAoG
    CCqGSM49BAMCA0gAMEUCIGxfITzGCcYJewdV2pRNFgr4e5kgUVQww0iHQ0UMCOEA
    AiEA2C05nQh9XyKr2y460v8dHnO8iEV3WGQk6sefsA6XvkE=
    -----END CERTIFICATE-----
	 275
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEvtTWGNBqVbIXH1MYAqZHwfEQu9+o
    BBJr90u5pyGXgzHEeITBnb61FgkNtQT2kpmSOuMdLWJIFwhHwQVDrdI/YQ==
    -----END PUBLIC KEY-----
	  91

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Mar 2013 18:27:47 +0000

On Wed, Mar 06, 2013 at 12:44:37PM -0500, Paul Wouters wrote:

> On Wed, 6 Mar 2013, Ond?ej Sur? wrote:
> 

No need to duck, if DNSSEC serves-up usable TLSA records, then
indeed Postfix won't deliver without TLS. If *all* the records are
malformed or use unsupported parameters, then my reading of DANE
6698 is that one should behave as though no TLSA records were
present.  This is based on 6698 #4.1:

   If an application receives zero usable certificate associations from
   a DNS request or from its cache, it processes TLS in the normal
   fashion without any input from the TLSA records.  If an application
   receives one or more usable certificate associations, it attempts to
   match each certificate association with the TLS server's end entity
   certificate until a successful match is found.  During the TLS
   handshake, if none of the certificate associations matches the
   certificate given by the TLS server, the TLS client MUST abort the
   handshake.

Are you saying that an RRset consisting entirely of unusable TLSA
records should force TLS (to always fail)?

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 6 Mar 2013 14:47:01 -0500 (EST)

> public-key only TLS applications.

Why are you suddenly switching the argument? If you want a protocol that
is not encumbered by obsolete X509 mappings, you're going to need
some API changes.

> a small amount of extra packet payload.

Size was not the problem you were talking about. Problem was the
conflicting information between certificate content and DNS bindings
to name, ttl etc. This draft enables you a valid way out of your issue.

Neither one of us was talking about packet size or code size.

If you don't want conflicting X509 information in DNS, then the best way
out is to not have that information in the X509 certificate.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 6 Mar 2013 14:52:31 -0500 (EST)

On Wed, 6 Mar 2013, Viktor Dukhovni wrote:

> No need to duck

I was ducking for other people :)

> , if DNSSEC serves-up usable TLSA records, then
> indeed Postfix won't deliver without TLS.

And that is what the majority did not want the specification to mean.
They wanted the "is TLS mandatory for this connection or not" to be
signaled with a separate record, the draft had HASTLS. However, that
draft hasn't moved at all in over a year, and I am personally in favour
of using the presence of a TLSA record to mean "do not contact without
TLS".

> If *all* the records are

That section does not talk about whether or not to use non-TLS. It only
talks about "if you want to do TLS and you find one or more TLSA
records". It does not talk about "should we connect using TLS or
without?"

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Mar 2013 19:58:04 +0000

> is not encumbered by obsolete X509 mappings, you're going to need

I don't want to *depend* on complex certificate properties for
security. Their presence in the certificate does not bother me.
If I match a peer by the certificate or public key digest, ignoring
all extensions, names, ... I don't really care whether that key
was encapsulated inside an ASN.1 sequence of some additional useless
information.

Changing the Postfix code to depend as yet unreleased OpenSSL APIs
that users won't have for a long time, and TLS extensions that
may trigger interoperability problems just does not look that appealing.

> to name, ttl etc. This draft enables you a valid way out of your issue.

There is no conflicting information when the content of the
certificate (other than perhaps the public key) is simply ignored.
All I see is a pile of bits.

Sorry if this is disappointing, but for now the cost/benefit
ratio for oob-pubkey is too high.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Mar 2013 20:11:48 +0000

> of using the presence of a TLSA record to mean "do not contact without

Perhaps this has changed:

	https://tools.ietf.org/html/draft-ietf-dane-srv-02#section-3.2

	https://tools.ietf.org/html/draft-ietf-dane-smtp-01#section-3

Both say that TLS is mandatory when "secure" TLSA records are
present even if unusable!  Based on this, Postfix will do mandatory
TLS in this case, but without PKIX validation, providing the usual
(for MTAs) protection from passive eavesdropping.  The legacy public
CA PKI simply does not work well enough for MTAs to be broadly
useful.

Thanks for bringing my attention to this issue.

-- 
	Viktor.

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 6 Mar 2013 22:54:20 +0100

On 6 mar 2013, at 19:20, Viktor Dukhovni <[email-masked]> wrote:

> for the peer certificate.  

FWIW, there is work going on for implementing DANE in OpenSSL. I suggest you wait for this before moving forward.

	jakob

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Mar 2013 23:04:35 +0000

On Wed, Mar 06, 2013 at 10:54:20PM +0100, Jakob Schlyter wrote:

> FWIW, there is work going on for implementing DANE in OpenSSL.

Any support for DANE in OpenSSL is exceedingly unlikely to be useful
to Postfix.

The changes to the SSL_verify callback required to support DANE
certificate usage 2 were quite easy and are already done.  Postfix
already has support for end-entity certificate verification.

The Postfix verify callback also has to support pre-DANE
administrator implemented TLS security policy (destination
specific CAs, fingerprints, and matching rules).

All that remains to be added is support for hybrid policies where
some TLSA records provide EE cert information and other TLSA records
provide TA cert information.

Postfix will need a new security level which is a hybrid of
"fingerprint" and "verify" matching either a set of TA certs or a
set of "EE" certs.  This is easy.

The trickiest part will be integrating all of this with the MX
resolution and connection retry logic.  OpenSSL won't be of any
help there.

> I suggest you wait for this before moving forward.

Thanks, but I'm moving ahead independently.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Mar 2013 23:07:30 +0000

On Wed, Mar 06, 2013 at 10:55:06PM +0100, Jakob Schlyter wrote:

> If you want to provide comments on the OpenSSL DANE interface, let me know.

Sure just point me at the right git repo, I already have a clone
of the main repo, if the code is there, all I need to know is which
branch it is on.

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Wed, 06 Mar 2013 21:10:44 -0500

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

VD> Perhaps this has changed:

VD> 	https://tools.ietf.org/html/draft-ietf-dane-srv-02#section-3.2

VD> 	https://tools.ietf.org/html/draft-ietf-dane-smtp-01#section-3

VD> Both say that TLS is mandatory when "secure" TLSA records are
VD> present even if unusable!

Not so much changed; the difference is that there wasn't consensus to do
that for tlsa records in general, but Tony, et al propose that for those
cases which use SRV or MX records.  Other drafts also might propose such
for their specific cases.

But in the absense of such a more specific draft or rfc, 6698 on its own
does not specify forcing TLS whenever a validly signed TLSA is found.

Just another example where different use cases and user communities have
different requirements and expectations, but still benefit from a common
foundation.

-JimC

---

From: Paul Wouters <[email-masked]>
Date: Wed, 6 Mar 2013 21:56:04 -0500 (EST)

> certificate (other than perhaps the public key) is simply ignored.

Correct, if you ignore the conflict, then there is no conflict in your
eyes. However, there is still a conflict.

> ratio for oob-pubkey is too high.

Understood.

Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 7 Mar 2013 07:52:48 +0100

> of using the presence of a TLSA record to mean "do not contact without
In SIP we use NAPTR records to indicate choice of transport to contact
a specific domain name. In NAPTR, I can say "I'm only available over
TLS".

Just for the archive...
/O

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Mar 2013 19:05:37 +0000

> "don't deliver without TLS"

That is what my drafts require.

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 7 Mar 2013 20:03:21 +0000

> That is what my drafts require.

Speaking of the drafs, one point I'd like to see modified is the
MUST SNI requirement.  I think it is too restrictive for two
reasons:

  - Some servers will have a single multi-SAN certificate, that
    meets the requirements of both legacy and DANE-aware clients
    and so don't need to support SNI.

  - Many (or perhaps even most) servers will publish "TLSA 3 1 1"
    records, and we've just agreed (after bload sweat and tears)
    that "TLSA 3 x y" won't need name checks.  So just the legacy
    name in the certificate suffices.

Therefore, the "MUST SNI" is I think a "SHOULD SNI", if the server
does not have a multi-name certificate, and its DANE cert usage
leads to some clients expecting a different name than others.

Doing SNI in Postfix would be a pain, and its never been needed
before, I'd like to keep it that way.

-- 
	Viktor.