Subject: [dane] Opening Issue #37.

From: Warren Kumari <[email-masked]>
Date: Sun, 8 Jan 2012 13:49:24 -0500

Hi all,

As threatened, I am opening DANE Issue #37 (We specifically waited till after the vacation to open it so that folk were around).

In order to jog you memory, here is an extract from the minutes (and to remind folk that the issue morphed over time, please see the list):
------------------------------------------------------------------------------------------------------
Issue #37
Idea: Add a usage to assert a self-signed server certificate directly
Proposal: Make no change to the core specification. This use-case can be covered via usage 2.
***
Alex Mayrhofer : I think this would make things easier for some people using self-signed certs
Richard Barnes: We could add an example to the document showing how to use usage 2 to address this use-case
EKR: Doesn't what Richard says require PKIX validation
Richard: Yes, there does need to be PKIX validation for usage 2, you can't just do byte-wise comparison
EKR: This sounds a lot more complicated
Alex M: I kind of agree with EKR. Let's go with direct certificate association to make this as simple as possible. This is a usability issue.
Steve Kent: There is code for PKIX validation that is currently available. This code can just be re-used to do usage 2 of DANE.
PHB: This is all a lot more critical if there is no choice about the exclusivity
Richard B: There is a requirement in the use-cases that you should be able to do this with a minimum of key management. The current document text does not require two key pairs (it just requires two certificates).
Jim Schaad: I am lost as to why this needs to be a separate certificate?
Richard B: The question is whether existing software stacks can do this usage 2 with only one certificate. There was some lack of clarity on the list with regards to what can be done with existing software stacks.
Bill Manning : I think this is a useful thing to have in the stack, regardless of whether we actually decide to deploy this. Code points are not scarce.
Paul Wouters: There will be a case (eg bare public key cert_type) that will not have anything of a PKIX TA. Make sure that's clear to implement
Richard B: If we support bare public keys in the future, we will probably need a new usage.
***
CONCLUSION: After hum, there is no clear results, we will open a big discussion of this on the list.

---------------------------------------------------------------------------

I would like us to discuss this issue (and try avoid going down any rabbit holes (like rat holes, but more surreal)) and come to consensus by Jan 23rd (around 2 weeks).

Thank you for your time and consideration,
W

---
Don't be impressed with unintelligible stuff said condescendingly .
    -- Radia Perlman.

Warren Kumari
[email-masked]

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 22 Jan 2012 17:31:24 -0800

> I would like us to discuss this issue (and try avoid going down any
> rabbit holes (like rat holes, but more surreal)) and come to consensus
> by Jan 23rd (around 2 weeks).

Is it really possible that no one has commented on this, or am I somehow
not seeing the messages?

To reiterate what I said in the previous round of discussion:

- When making a positive assertion (as I will be), the ability to
specify the exact server certificate and not call PKIX validation at all
would give me greater peace of mind.  Make of that what you will.

- As I observed at
https://www.ietf.org/mail-archive/web/dane/current/msg03583.html, it is
inconsistent that for restrictive assertions, we have separate usages
for CA certificate (0) and server certificate (1), while for positive
+restrictive assertions, we have a single usage for a CA certificate or
a server certificate (2).  If one would argue that we don't need a
separate usage for a positive+restrictive assertion of a server
certificate, the exact same argument would suggest that the current
usages 0 and 1 should be combined.

- If we do proceed with a single usage for positive+restrictive
assertions with the understanding that the server certificate can serve
as a trust anchor for itself, we need to make sure that implementations
that do not take the same viewpoint internally (NSS) handle this case as
we intend.

-- 
Regards,
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 22 Jan 2012 18:05:42 -0800

> Is it really possible that no one has commented on this, or am I somehow

The former. Maybe you are the only one who cares about it.

--Paul Hoffman

---

From: Scott Schmit <[email-masked]>
Date: Sun, 22 Jan 2012 22:31:24 -0500

> would give me greater peace of mind.  Make of that what you will.

Then, IMHO what you *really* want is the bare key support from
draft-ietf-tls-oob-pubkey (and the DANE draft that will surely follow
its publication as RFC).

> usages 0 and 1 should be combined.

Is there really a problem?

The draft states:
#     2 -- The target certificate MUST pass PKIX validation, with any
#     certificate matching the TLSA record considered to be a trust
#     anchor for this validation

But the trust anchor isn't required to be passed in the Server
Certificate message, and clients routinely ignore whether TAs are marked
as CA certificates or not (nor are they required to check).

So you can put a self-signed EE cert in your TLS server configuration
and the same certificate in your TLSA record (2 0 0). The TLS
client will look up the TLSA record, mark the certificate as a trust
anchor for this connection, get the one-certificate certificate chain,
see a self-issued EE cert issued by an omitted TA certificate (the one
in the TLSA record), and accept the certificate. And the RFCs would
defend that behavior, as far as I understand it.

Or am I missing something?

-- 
Scott Schmit

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 23 Jan 2012 00:38:27 -0800

> draft-ietf-tls-oob-pubkey (and the DANE draft that will surely follow

Actually, not.  My desire at this point is to have DANE clients use a
certificate acceptance test that does not involve PKIX validation.  I am
not adverse to the public key being wrapped in an X.509 certificate.

> defend that behavior, as far as I understand it.

This may or may not work in implementations.  But that wasn't the point
I was making.  If a separate usage for a positive and restrictive
assertion of a server certificate is unjustified complexity, then so too
is the distinction between usages 0 and 1.  We could have simply:

0 -- The target certificate MUST pass PKIX validation using the client's
usual trust anchor set, and also MUST pass PKIX validation with any
certificate matching the TLSA record (and only such a certificate)
considered to be a trust anchor for this validation.

2 -- The target certificate MUST pass PKIX validation, with any
certificate matching the TLSA record (and only such a certificate)
considered to be a trust anchor for this validation.

Nothing, except the document already being written, justifies the
current state of affairs with usages 0 and 1 separate but usage 2
serving a dual purpose.

-- 
Matt

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 23 Jan 2012 09:44:26 -0500

> current state of affairs with usages 0 and 1 separate but usage 2

Well, there is a use cases document that achieved consensus in this working group:
<http://tools.ietf.org/html/rfc6394>
The certificate usage types map exactly to the three major use cases in the document.

--Richard

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Jan 2012 20:21:28 +0100 (MET)

> #     anchor for this validation

That statement in the draft seems to be somewhat incorrect and misleading.

If the TLSA usage type 2 refers to a NON-self-signed End-Entity cert
(or its hash or its SPKI), then it will be technically impossible to
perform PKIX path validation.

So the PKIX path validation for usage type 2 needs to be conditionalized
to those situations where there exists a PKIX path.

-Martin

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 23 Jan 2012 12:39:36 -0800

This seems like a decent point to bring up (again) the fact that as
far as I am aware, "libpkix" is the only open-source *library* out
there that claims to implement RFC 4158 and 5280 in detail, and no
*client* I know of uses it unconditionally.  In particular, for HTTPS,
while both Firefox and Chrome have stated *plans* to switch to
libpkix, these plans have no dates attached to them, and the other
widely used browsers have expressed no interest at all in public.  The
"legacy" certificate validation algorithms that all browsers use at
the moment are *not* conformant to either RFC and there are advocates
for keeping it that way (largely on efficiency and "nobody needs all
of that damn complexity anyway" grounds).  Outside HTTPS, I am not
familiar with the state of play, but I would expect it to be similar.

Furthermore, as Peter Gutmann has pointed out repeatedly on this list,
"PKIX validation" is *not* a well-defined term even within the RFCs -
the language is sloppy enough that implementations can and do disagree
on what the correct behavior is.

I think it is not DANE's job to fix this mess, and we should drop the
phrase "PKIX validation" entirely from the spec, replacing it with
something like

# DANE clients SHOULD perform the same validation steps on the
# certificate chain that they would have in the absence of TLSA
# records, except that they MUST defer deciding whether the chain
# terminates in an acceptable root until TLSA information has been
# taken into account.

thus allowing DANE-compliant clients to continue with their present
state of (non)conformance to PKIX.

zw

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Jan 2012 14:50:27 -0800

> perform PKIX path validation.

I fully disagree with this statement. Trust anchors in PKIX (RFC 5280) are keys, not certificates. If you believe otherwise, please quote from RFC 5280.

> to those situations where there exists a PKIX path.

A path between a certificate and itself is still a path.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Jan 2012 14:54:34 -0800

> state of (non)conformance to PKIX.

-1. This proposed wording is just as silly as people saying that PKIX validation is well-defined and well-understood. Saying "we don't know what conformant means" is a terrible way to write a standard.

--Paul Hoffman

---

From: Ondrej Mikle <[email-masked]>
Date: Tue, 24 Jan 2012 00:09:57 +0100

On 01/23/2012 09:39 PM, Zack Weinberg wrote:
> *client* I know of uses it unconditionally.

[snip]

> state of (non)conformance to PKIX.

I agree with your description of the issue, but I don't think the proposed
replacement of "PKIX validation" will solve it. The real issue is in
"non-deterministic" way how clients build trust paths presently (and with
caching of intermediate certs, it's non-trivial to reproduce). While before DANE
a client built some chain that validated, with TLSA constraints it won't be enough.

RFC 4158 section 6 just adds more non-determinism, especially AIA retrieval.

I'm a bit afraid that the discover-all-chains-when-checking-TLSA algorithm,
while being correct, raises the bar too high (implementation-wise and
performance-wise; following thread has quite concise summary on real-world
implementation: http://comments.gmane.org/gmane.comp.mozilla.crypto/16445)

Ondrej Mikle

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 23 Jan 2012 15:35:44 -0800

On Mon, Jan 23, 2012 at 2:54 PM, Paul Hoffman <[email-masked]> wrote:
> -1. This proposed wording is just as silly as people saying that PKIX
> validation is well-defined and well-understood. Saying "we don't know
> what conformant means" is a terrible way to write a standard.

Well, I don't much care exactly how it's worded, but I think it is
*critical* that we manage to "allow DANE-compliant clients to continue
with their present state of (non)conformance to PKIX".  It seems to me
that the easiest way to do that is to define DANE clients' behavior in
the presence of TLSA records as adjustments to their behavior in the
absence of TLSA records, taking no position on what the "behavior in
the absence of TLSA records" should be.  Hence the suggested wording.
Do you have a better idea?

zw

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Jan 2012 15:42:41 -0800

> Do you have a better idea?

Yes: leave the current text as-is. If someone is not going to conform to PKIX today, we are not telling them to do it any differently with DANE.

--Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 23 Jan 2012 17:24:02 -0800

(accidentally hit reply-to-sender rather than reply-to-list, sorry about that)

On Mon, Jan 23, 2012 at 3:42 PM, Paul Hoffman <[email-masked]> wrote:
>> with their present state of (non)conformance to PKIX".
>
> Yes: leave the current text as-is. If someone is not going to conform
> to PKIX today, we are not telling them to do it any differently with DANE.

I disagree.  The current text is saying you have to conform to RFC
5280 if you want to implement DANE.  That will be taken as an argument
against implementing DANE by people who think RFC 5280 validation is
too expensive and/or complicated.

zw

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Jan 2012 17:25:43 -0800

On Jan 23, 2012, at 5:24 PM, Zack Weinberg wrote:

> 5280 if you want to implement DANE.  

Yep, just like RFC 2818 says you have to implement PKIX if you want to implement TLS.

> That will be taken as an argument

Errr, how are they doing TLS now without PKIX validation?

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Jan 2012 02:49:50 +0100 (MET)

Ondrej Mikle wrote:
> caching of intermediate certs, it's non-trivial to reproduce).
> While before DANE a client built some chain that validated, with TLSA
> constraints it won't be enough.
> 

rfc4158 is informative, and I am not aware of any reference from
PKIX (rfc5280) to rfc4158.

Btw. it would be folly to perform AIA retrievel (aka forward chaining) during
certificate path validation, because it would mean to perform downloads
from arbitrary untrusted URLs supplied by an attacker.  I'm aware that
Web Browsers do lots of folly things all the time, but a PKIX
implementation should not try to reproduce each and every security
vulnerability of a browser that displays a plain-http resource.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Jan 2012 02:59:19 +0100 (MET)

> A path between a certificate and itself is still a path.

Nope,  that applies only to *self-signed* certs.

Allowing TLSA usage type 2 EE-cert matches to *self-signed* EE-certs
(that are not even covered by existing ITU-T X.509 and PKIX specs),
but disallowing well-defined non-self-signed EE-certs to be matched
by TLSA usage type 2 records seems strange to me.

-Martin

---

From: Warren Kumari <[email-masked]>
Date: Mon, 23 Jan 2012 21:16:09 -0500

[ Administrative note, not aimed at anyone... ] 

We are going to delay calling consensus on this for a few more days as we have some (potentially) interesting / productive discussions.

Please let's all try keep this civil though - we are so close to finishing, and it would be nice to end on a positive note…

W

On Jan 23, 2012, at 8:59 PM, Martin Rex wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
> 

--
Don't be impressed with unintelligible stuff said condescendingly.
    -- Radia Perlman.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Jan 2012 18:36:44 -0800

> Nope,  that applies only to *self-signed* certs.

<sarcasm>Really? Where in the PKIX spec does it say that?</sarcasm>

You can repeat your assertion as often as you like; it's still wrong unless you support it with facts.

> (that are not even covered by existing ITU-T X.509 and PKIX specs),

<sarcasm>Really? Where in the PKIX spec does it say that?</sarcasm>

> by TLSA usage type 2 records seems strange to me.

When did anyone say that some types of EE certs are disallowed by type 2?!?!

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Jan 2012 04:39:26 +0100 (MET)

> When did anyone say that some types of EE certs are disallowed by type 2?!?!

the statement

  #     2 -- The target certificate MUST pass PKIX validation

clearly implies this.  

When talking about PKIX validation, that is a reference to performing
certification path validation (and optionally revocation checking)
along the lines of rfc5280 section 6.1 and ITU-T X.509 08/2005 Section 10.

If you believe that I have missed a part of rfc5280 or ITU-T X.509 08/2005
where it describes how to perform certificate path validation with
the same non-self-signed certificate being both path certificate and trust
anchor, I'll be glad about a reference to this description.

> Martin Rex wrote:

That is a common implementated behaviour that rfc5280 for the certificate
path validation.  rfc5280 section 6.1 contains this description:

rfc5280, section 6.1:

   When the trust anchor is provided in the form of a self-signed
   certificate, this self-signed certificate is not included as part of
   the prospective certification path.

that is often implemented as "this self-signed certificate is typically
not included as part of the prospective certification path, unless it is
also used as the TLS server certificate." -- which is perfectly OK
with rfc5280, as it does not use use imperatives (SHOULD NOT /MUST NOT).

> 
> You can repeat your assertion as often as you like;
> it's still wrong unless you support it with facts.
> 

And ITU-T X.509 08/2005 says this:

   3.3.56 self-signed certificate: [...]

      NOTE  Use of self-issued certificates and self-signed certificates
      issued by other than CAs are outside the scope of this
      Recommendation | International Standard.

rfc5280 declares itself a profile of ITU-T X.509 08/2005

   Abstract

   This memo profiles the X.509 v3 certificate and X.509 v2 certificate
   revocation list (CRL) for use in the Internet.  An overview of this

and does not currently cover self-signed non-CA either, that have
been exempted by ITU-T X.509.

So with respect to non-CA self-signed certs being used with TLS in
the installed base, there exists only implementation-defined behaviour.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Jan 2012 20:00:19 -0800

>  #     2 -- The target certificate MUST pass PKIX validation

Sorry, but I don't see any such implication, certainly not clearly.

> along the lines of rfc5280 section 6.1 and ITU-T X.509 08/2005 Section 10.

No, just to Section 6.1 of RFC 5280. As you have been told (repeatedly) on the PKIX WG mailing list, X.509 is not PKIX. If you insist that it is, you are in a different reality than the one shared in the IETF, so discussion is fruitless.

> anchor, I'll be glad about a reference to this description.

See below.

> path validation.  

As we are well aware of here, "common" does not mean "correct".

> rfc5280 section 6.1 contains this description:
> 
> rfc5280, section 6.1:
> 

Read that quoted text again: the self-signed cert is not included *as part of the prospective certification path*. It is the terminus. The fact that it is "often implemented" wrong does not mean that your repeated assertions are right, just that you are asserting what bad implementations do.

>      Recommendation | International Standard.

Again: that's not PKIX.

> been exempted by ITU-T X.509.

They are not "exempted", they are outside the scope. Note the huge difference there. PKIX *profiles* X.509 by changing it, yes?

> the installed base, there exists only implementation-defined behaviour.

There are plenty of implementations that get this right, and plenty that get it wrong. You are choosing the latter to support your assertions.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Jan 2012 06:15:14 +0100 (MET)

> As we are well aware of here, "common" does not mean "correct".

OK, let's say I use rfc5280, section 6.1
 and supply as self-signed cert as prospective certification path
 and supply as trust anchor only the tbsCertificate of the self-signed cert

so that sentence no longer applies.

> 
> Read that quoted text again: the self-signed cert is not included
> *as part of the prospective certification path*. It is the terminus.
> The fact that it is "often implemented" wrong does not mean that your
> repeated assertions are right, just that you are asserting what bad
> implementations do.

Now I am throughly confused about what you would like implementations
of dane-protocol to do exactly where it currently says that
for TLSA usage type 2 "MUST pass PKIX validation",
in case that the TLSA usage type 2 record identifies
the server's certificate.

   *  which algorithm you are refering to by this term
      "pass PKIX validation" if it is _not_ rfc5280 section 6.1
      plus optionally section 6.3

   *  in case the algorithm should be rfc5280 section 6.1,
      please specify the contents of the two required input parameters
      to that algorithm:
        (1) prospective certification path
        (2) trust anchor

> No, just to Section 6.1 of RFC 5280. As you have been told (repeatedly)
> on the PKIX WG mailing list, X.509 is not PKIX. If you insist that it is,
> you are in a different reality than the one shared in the IETF,
> so discussion is fruitless.

I would strongly recommend that you look at PKIX/rfc5280 section 6.1
and how it describes it's own relation to X.509:

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

   6.1. Basic Path Validation

   This text describes an algorithm for X.509 path processing.  A
   conforming implementation MUST include an X.509 path processing
   procedure that is functionally equivalent to the external behavior of
   this algorithm.  

     [...]

   While the certificate and CRL profiles specified in Sections 4 and 5
   of this document specify values for certificate and CRL fields and
   extensions that are considered to be appropriate for the Internet
   PKI, the algorithm presented in this section is not limited to
   accepting certificates and CRLs that conform to these profiles.
!! Therefore, the algorithm only includes checks to verify that the
!! certification path is valid according to X.509 and does not include
!! checks to verify that the certificates and CRLs conform to this
!! profile.  While the algorithm could be extended to include checks for
!! conformance to the profiles in Sections 4 and 5, this profile
!! RECOMMENDS against including such checks.

My copy of PKIX/rfc5280 recommends X.509 certificate path validation
over checks suggested in sections 4 and 5.

-Martin

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 23 Jan 2012 22:35:32 -0800

> The certificate usage types map exactly to the three major use cases in the document.

So what?  Why is it desirable that different "use cases" be supported
via different certificate usage values?  The argument that a single
usage can support both Sections 3.1 and 3.2 of RFC 6394 is exactly the
same one you are making that usage 2 supports positive-and-restrictive
assertions of both CA certificates and server certificates.

On the other side, Paul Wouters claimed
(https://www.ietf.org/mail-archive/web/dane/current/msg03520.html) that
the use cases document declined to address positive-and-restrictive
assertion of a server certificate with the understanding that that level
of detail would be considered in the protocol document.  If that is
true, it rather belies your point.  (Paul, if you could provide the
actual reference, I would be very grateful.)

-- 
Matt

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 23 Jan 2012 22:40:59 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Martin Rex
> Sent: Monday, January 23, 2012 5:50 PM
> To: Ondrej Mikle
> Cc: [email-masked]
> Subject: Re: [dane] Opening Issue #37.
> 
> Ondrej Mikle wrote:
> >
> > > I think it is not DANE's job to fix this mess, and we should drop
> > > the phrase "PKIX validation" entirely from the spec, replacing it
> > > with something like
> > >
> > > # DANE clients SHOULD perform the same validation steps on the #
> > > certificate chain that they would have in the absence of TLSA #
> > > records, except that they MUST defer deciding whether the chain #
> > > terminates in an acceptable root until TLSA information has been #
> > > taken into account.
> > >
> > I agree with your description of the issue, but I don't think the
> > proposed replacement of "PKIX validation" will solve it. The real
> > issue is in "non-deterministic" way how clients build trust paths
> > presently (and with caching of intermediate certs, it's non-trivial to
> reproduce).
> rfc4158 is informative, and I am not aware of any reference from PKIX
> (rfc5280) to rfc4158.

It appears to reference RFC 3280 in the introduction, I have not looked
father

> from arbitrary untrusted URLs supplied by an attacker.  I'm aware that Web
> Browsers do lots of folly things all the time, but a PKIX implementation
> should not try to reproduce each and every security vulnerability of a
> browser that displays a plain-http resource.

There is a possible attack in terms of tracking what the client is doing,
but since the data download will be validated the issue is privacy not
security.

Jim

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 23 Jan 2012 23:05:23 -0800

> Trust anchors in PKIX (RFC 5280) are keys, not certificates.

The spec is easily fixed:

2 -- The target certificate MUST pass PKIX validation, with any SPKI of
a certificate matching the TLSA record considered to be a trust anchor
for this validation

I still suspect Martin is right.  Let me try to spell out the scenario.

Suppose that for my TLS service, I wish to use a certificate C signed by
a traditional public CA (for the benefit of legacy clients), but I want
DANE clients to accept the certificate irrespective of whether they
choose to include the CA in their traditional trust anchor list.  To
reduce my exposure to malfeasance by the CA, I want to make a
restrictive assertion of the certificate C, not the CA certificate.
Under these circumstances, I would use an association of usage 2
containing C.

Let K be the SPKI of C.  The DANE client would attempt to PKIX-validate
C, with K considered to be a trust anchor for this validation.  If the
validation were to succeed, it could only be by virtue of the fact that
C itself contains the trust anchor K (because the signature on C is by
another, unrelated key).  The path for C would contain zero(!)
certificates followed by the trust anchor K; in particular, it would not
contain the certificate C being validated.  I find this hard to believe,
but I will let those more familiar with the arcana of PKIX resolve the
question.

-- 
Matt

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 24 Jan 2012 01:11:38 -0800

> Matt McCutchen
> Sent: Monday, January 23, 2012 11:05 PM
> To: Paul Hoffman; Martin Rex
> Cc: IETF DANE WG list
> 2 -- The target certificate MUST pass PKIX validation, with any SPKI of a
> certificate matching the TLSA record considered to be a trust anchor for
this
> validation
> Suppose that for my TLS service, I wish to use a certificate C signed by a
> traditional public CA (for the benefit of legacy clients), but I want DANE
> clients to accept the certificate irrespective of whether they choose to
> include the CA in their traditional trust anchor list.  To reduce my
exposure to
> malfeasance by the CA, I want to make a restrictive assertion of the
> certificate C, not the CA certificate.
containing
> C.
> 
> Let K be the SPKI of C.  The DANE client would attempt to PKIX-validate C,
> with K considered to be a trust anchor for this validation.  If the
validation
> were to succeed, it could only be by virtue of the fact that C itself
contains
> the trust anchor K (because the signature on C is by another, unrelated
key).
> The path for C would contain zero(!) certificates followed by the trust
anchor
> K; in particular, it would not contain the certificate C being validated.
I find
> this hard to believe, but I will let those more familiar with the arcana
of PKIX
> resolve the question.

That is exactly what I would expect to happen.  The PKIX code is undefined
for a chain length of zero, so your implementation of the code may vary.
Some implementations (I think the msft one) would require that the actual
certificate C be in the trusted store rather than any arbitrary certificate
B which happened to have the same public key K.  I would imagine that other
implementations may or may not deal with this case correctly.

Jim

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Jan 2012 09:19:30 -0800

> a certificate matching the TLSA record considered to be a trust anchor

I think I see where you are going, but I think you might have gotten the text wrong. Is the following what you meant?

2 -- The target certificate MUST pass PKIX validation, with the SPKI of
the TLSA record considered to be a trust anchor
for this validation

If so, it might satisfy Martin's concern as well.

--Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 24 Jan 2012 09:38:02 -0800

> Yep, just like RFC 2818 says you have to implement PKIX if you want to implement TLS.

RFC 2818 [HTTP over TLS] says you have to check the hostname in the
URL against the hostname in the end-entity certificate, but says
nothing about validation to be performed on the certificate chain
itself.  Were you possibly thinking of RFC 2246 [TLS 1.0]?  This is
what that says:

# D.3. Certificates and authentication
#
#    Implementations are responsible for verifying the integrity of
#    certificates and should generally support certificate revocation
#    messages. Certificates should always be verified to ensure proper
#    signing by a trusted Certificate Authority (CA). The selection and
#    addition of trusted CAs should be done very carefully. Users should
#    be able to view information about the certificate and root CA.

I read this as "you are required to validate certificates, but *how*
you validate certificates is unspecified."

> Errr, how are they doing TLS now without PKIX validation?

They use ad-hoc validation algorithms which generally include some
subset of the checks defined in RFC 5280 plus possibly other stuff.
They claim conformance with TLS 1.0.

zw

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 24 Jan 2012 09:46:50 -0800

This argument underlines my contention that DANE should _not_ attempt
to define how clients construct or validate the certificate chain.

It should be enough to say that the client does _whatever it does
now_, and then (for types 0 and 1) applies an additional constraint
that a matching certificate must appear at a certain position in the
chain, or (for type 2) temporarily considers a matching certificate to
be an additional trust anchor.

ANY attempt to specify client validation in more detail than "whatever
the client would have done in the absence of TLSA information" will
require some clients to change how they do path construction or
validation when TLSA records are present, and implementors will prefer
to ignore DANE if it requires that change.

Yes, path construction is nondeterministic and not consistent across
clients.  DANE should not attempt to fix that en passant; it will only
make deployment harder.

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Jan 2012 19:59:56 +0100 (MET)

> If so, it might satisfy Martin's concern as well.

That is only a partial solution.

Usage case 2 covers three different variants:

  (1) Server uses self-signed cert, TLSA identifies self-signed cert

  (2) Server uses CA-issued cert from private CA, TLSA identifies
      a CA-certificate from the Server's certifcation path

  (3) Server uses CA-issued cert from private CA, TLSA identifies
      the server's CA-issued cert directly

Only for (1) and (2) a PKIX (certificate path) validation could be
specified, it is *IMPOSSIBLE* to perform a PKIX validation for (3).

I would also appreciate if PKIX validation and rfc-2818 server endpoint
identification would not be conflated by dane-protocol.

rfc-2818 server endpoint identification makes sense for traditional
PKIX-based server identification, because this is how the CA asserts
for which DNS domain name the server certificate was issued.

For DANE, the existence of the TLSA record already provides the binding
to the DNS domain name.  So this WG is in principle free to specify
whether or not the DANE-part of the validation looks at name attributes
of the server certificate.

But for usage types 0 and 1 a PKIX-based endpoint identification should
be performed for consistency with the existing endpoint identification,
which narrows this down to usage type 2.

doing name matching makes DANE-only scenarios (usage type 2)
more difficult to configure (usability), and may require additional
TLS features to be available and employed for multihoming and virtual
hosting.  If name-matching is required for the DANE part as well,
then it would later be easier to switch a productive setup from
usage type 2 to usage type 0 or 1.

An additional check in the DANE-part adds complexity (more code,
more cpu cycles) and requires some amount of synchronization between
potentially independent software modules (the part that performs
server endpoint identification in the PKIX world and the part
that performs server endpoint identification in the DANE part).

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Jan 2012 11:37:40 -0800

> identification would not be conflated by dane-protocol.

Fully agree. I apologize for doing that the other day. The current spec only mentions 2818 in passing, not tied to the DANE processing protocol.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Jan 2012 11:43:32 -0800

> specified, it is *IMPOSSIBLE* to perform a PKIX validation for (3).

With the proposed wording above, I agree that #3 would not work. In such a case, the server would publish a type 0 cert instead.

With the current wording in the draft, #3 would work fine if you believe (as many of us do) that a chain of zero length is fine. Others believe that a chain of zero length would not be correct PKIX validation, so #1 would not work, but #2 and #3 would.

So, using my propose wording above, you (Martin) still get what you want as long as the server doesn't do #3 as usage type 2, but instead does it as usage type 0, yes?

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Jan 2012 22:03:25 +0100 (MET)

Paul Hoffman wrote:
> With the proposed wording above, I agree that #3 would not work.
> In such a case, the server would publish a type 0 cert instead.
> 
> With the current wording in the draft, #3 would work fine if you believe
> (as many of us do) that a chain of zero length is fine. Others believe
> that a chain of zero length would not be correct PKIX validation,
> so #1 would not work, but #2 and #3 would.
> 
> So, using my propose wording above, you (Martin) still get what you want
> as long as the server doesn't do #3 as usage type 2, but instead does
> it as usage type 0, yes?

I still disagree.

I believe we've been around here before  ;-)
  http://www.ietf.org/mail-archive/web/dane/current/msg04160.html

Making case #1 work with rfc5280 section 6.1 is easy -- passing
the cert in as both, chain and trust anchor (and for the latter only
the tbsCertificate part if you want to be anal about that one sentence).

But I don't see how you could specify (3) to provide the necessary
arguments to the average certificate path validation function and
come out with the result "passed PKIX validation".

-Martin

---

From: Scott Schmit <[email-masked]>
Date: Tue, 24 Jan 2012 23:34:58 -0500

On Tue, Jan 24, 2012 at 11:43:32AM -0800, Paul Hoffman wrote:
> So, using my propose wording above, you (Martin) still get what you
> want as long as the server doesn't do #3 as usage type 2, but instead
> does it as usage type 0, yes?

Actually, usage 0 can't work if the CA is a *private* CA (i.e., not
signed by any of the client's TAs).

-- 
Scott Schmit

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 24 Jan 2012 21:40:04 -0800

> the TLSA record considered to be a trust anchor

No: if the TLSA record has matching type other than 0, "the SPKI of the
TLSA record" doesn't mean much.

> If so, it might satisfy Martin's concern as well.

This difference does not affect Martin's concern, which is about whether
PKIX validation succeeds after the intended key is set as a trust
anchor.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 24 Jan 2012 21:56:41 -0800

On Tue, 2012-01-24 at 11:43 -0800, Paul Hoffman wrote:
> With the current wording in the draft, #3 would work fine if you
> believe (as many of us do) that a chain of zero length is fine.

What?  You yourself pointed out
(https://www.ietf.org/mail-archive/web/dane/current/msg04148.html) that
trust anchors are keys, not certificates.  Hence, the meaning of the
current wording is not well defined, and your wording above (or mine; it
doesn't matter in this context) is the nearest possible correction.  So
I don't see how you can derive a definite outcome for the current
wording that differs from the outcome for your wording at the top.

> Others believe that a chain of zero length would not be correct PKIX
> validation, so #1 would not work, but #2 and #3 would.

How did you come to this conclusion?

Letting C be the server cert and K be its SPKI, in #1, there is
(arguably) a valid chain of length 1 from C to K, while in #3, there is
only the zero-length chain consisting of K.  So if anything, #1 is in
better shape than #3.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 24 Jan 2012 22:50:36 -0800

On Tue, 2012-01-24 at 11:43 -0800, Paul Hoffman wrote:
> With the current wording in the draft, #3 would work fine if you believe (as many of us do) that a chain of zero length is fine.

So, I looked in RFC 5280, and a path of zero length is not valid.
Section 6 states:

"Valid paths begin with certificates issued by a trust anchor."

A path that contains no certificates at all does not begin with a
certificate issued by a trust anchor, hence it is not valid.  I hope
this settles the matter.

-- 
Matt

---

From: Pieter Lexis <[email-masked]>
Date: Wed, 25 Jan 2012 11:49:20 +0100

Disclaimer: I'm no PKIX/X509 expert.

> to define how clients construct or validate the certificate chain.

I agree with Zack here, I believe this is out of scope for the DANE WG
and attempting to specify this will hamper DANE deployment in the real
world.

> be an additional trust anchor.

+1, this is the definition I used when creating 'swede' as it feels the
most logical thing to do. Usage 0 and 1 'just' add a fairly easy
additional constraint to the status quo (the CA or EE cert must match
and chain to an accepted CA cert in the end-application certificate store).

Whereas usage 2, in my opinion, can be described as (non-ietf text up
ahead) 'If the EE cert matches the TLSA record or if it chains to a
certificate that matches the TLSA record, accept it without consulting
the local certificate store'. This assumes the certificates in the
(eventual) certificate-chain are valid (except for them not being in the
local certificate store).

If these (perhaps over-simplified) definitions are used, in my opinion
there is no big hurdle for TLS implementations to (correctly) implement
DANE, which in turn will make server-operators more likely to start
offering TLSA records for their services (because there is no
chicken-and-egg problem).

Just my 2 cents.

- --
Pieter Lexis

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 26 Jan 2012 09:26:55 +0100

> Yes: leave the current text as-is. If someone is not going to conform to PKIX today, we are not telling them to do it any differently with DANE.

+1

Let's not standardize "status quo" here.

O.
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 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: Thu, 26 Jan 2012 09:36:33 +0100

> too expensive and/or complicated.

Zack are you saying we should consider various projects internal
politics when constructing the protocol?  I disagree with that.

And I really believe that if something like that would stop
the implementation it doesn't really matter if we put your proposed
degree of freedom into the protocol or not.

In another words - if the project/people doesn't care about conformance
to PKIX, why it would suddenly start when implementing DANE?

O.

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 26 Jan 2012 19:28:59 -0800

> politics when constructing the protocol?  I disagree with that.

Maybe (do you *want* to write a spec that nobody will implement?) but
that's not really the point so let's leave it aside.

My position is that we should not require RFC 5280 (or any other
standardized definition of "PKIX validation") as part of DANE.

My justifications for that position are:

1. Real implementations of TLS don't do RFC 5280 today; they do
various ad-hoc things instead.  Turning on DANE for a domain should
not change that, because that's a gigantic, surprising, and
inappropriate-for-this-WG-to-require side effect.

2. It is unclear -- see the big long argument in this very thread --
whether the intended behavior of type 2 TLSA records is implementable
on top of RFC 5280 validation; the easiest way out of the hole is to
not specify validation.  (The ad-hoc things that real implementations
do will be able to handle type 2 records Just Fine.)

zw

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 31 Jan 2012 10:07:01 +0100

<chair hat on>
IETF is a standardization organization and should work on top
of existing standards.  I fully understand your position, but
we need to keep a level of consistency within IETF.  If that
will be used as an argument against implementing DANE, it will
be sad, but I don't really think it will be the main showstopper.

It's joint wish of chairs to not loosen the requirements for PKIX
validation in the draft.  If the rest of the WG care, you should
speak now.
</chair hat off>

Ondrej
P.S.: It seems that we have a different directions in this thread
and I'm going to handle them case by case.  So expect more emails
in a minute.  This is only part where I handle Zack's request to
drop PKIX validation.

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 31 Jan 2012 10:21:32 +0100

Martin, Matt,

it seems this thread is either unimportant or very hard to understand
to the rest of the working group (and I must admit it's very hard for
me to understand the underlying problem).

Would you be willing to accept this partial solution, so we can move
on with the draft?  If not would you be willing to propose a specific
text we can work on?  It would also help for clarity of the issue to
have a text which can be incorporated into the draft.

From the chair viewpoint I think it's more important to stick to existing
standards than to cover every possible use case.  If there's one working
way how to deploy EE-certificate without using existing CAs (trust anchors)
I am perfectly happy even if it's not the easiest way possible.  Writing
a good step-by-step HOWTO is a perfect way how to solve this.

I think we have discussed this issue long enough and haven't gotten anywhere,
so I am inclined to close this issue and leave the draft as is.  If other WG
members has some opinion please speak now, I'll leave some time to Martin
and Matt to propose a specific text and call for consensus in a few days.
Ideally I would like to see this issue closed at the end of this week.

Ondrej

---

From: Tom Ritter <[email-masked]>
Date: Tue, 31 Jan 2012 10:24:09 -0500

> me to understand the underlying problem).

Put a mark in the 'very hard to understand, but important to' column for me.

> If there's one working

I am most interested in deploying EE certificates without using
existing CAs (trust anchors).  I also am okay with a more-complicated
but existing mechanism.  And I would greatly appreciate a HOWTO.

As I read section 4.3 of -14 - I was *not confused*, and thought I
would just drop the self-signed cert or public key of the self-signed
cert in the TLSA record, return only my self-signed cert (1 cert, no
chain), and be good to go.  This discussion implies to me that this is
not the case, and therefore what I thought was not confusing, must be
so confusing I don't even know enough to be confused.

My confusion may center around passing "PKIX Validation" - I confess
I'm not certain of what that all entails.  -14 does not define it
explicitly, and I'm not sure if its use is colloquial[1] or
specific[2].  I'm sure the specific version states that it must chain
to a trust anchor without specifying standards for trust anchors, in
which case section 4.3 of -14 would work (because it would add the
TLSA record as a trust anchor).  Colloquially, I fear implementors
would interpret "PKIX Validation" to also include chaining to one of
the root certs in a machine/device/software repository, and Section
4.3 of -14 would not work.

[1] Colloquial being the approximation that vendors have deployed, and
what 'most people' would say off the top of their heads if you asked
them: Must chain to a root cert in a repository, checking
basicConstraints, etc
[2] Specific being I'm-still-not-sure but maybe RFC 5280 Section 6?

If everyone else is having the same problem I'm having, adding a HOWTO
and defining 'PKIX validation' would help.

-tom

---

From: James Cloos <[email-masked]>
Date: Tue, 31 Jan 2012 12:45:53 -0500

>>>>> "TR" == Tom Ritter <[email-masked]> writes:

TR> thought I would just drop the self-signed cert or public key of the
TR> self-signed cert in the TLSA record, return only my self-signed cert
TR> (1 cert, no chain), and be good to go.

This is exaclty the use case to which type 2 SHOULD cater.

TR> My confusion may center around passing "PKIX Validation" - I confess
TR> I'm not certain of what that all entails.

And the best way for type 2 to cater to it would be to avoid demanding
"PKIX Validation".

It should be possible to configure a tls server to offer a chain of one
or more certs, any one of which matches the dane type 2 certification,
and expect dane-aware tls clients to accept that as a valid and secure
association.

One might want the tls server to send a chain of more than one cert to
support non-dane tls clients (in which case the chain likely also would
be signed by an otherwise-trusted root cert).  Or one might want to use
a dane type2 rr to trust one's own, private root cert.  The latter case,
of course, facilitates publishing the same TLSA RR on multiple paths,
just like a tlsa type 1 does.

So, what wording says that, "iff there are multiple tls certs in the
chain from the cert which matches the tls server's private key through
to the tls cert matching the TLSA type 2 RR, then that chain MUST,
*internally*, be a valid chain as described in the tls standard(s)",
without requiring that said chain be rooted anywhere?  Or be constrained
by anything other than TLSA?  And without confusing anyone?

[ Hoping that my above wording is clear :) ]

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

---

From: Martin Rex <[email-masked]>
Date: Tue, 31 Jan 2012 23:08:07 -0000

> have a text which can be incorporated into the draft.

Asking for proposed text is fair an reasonable.  I'll try to come up
with something.

The issue with "PKIX validation" is that this is probably the most
fuzzy thing that exists within the IETF.  But rfc5280 itself RECOMMENDs
to be laissez-faire about a number of things it specifies:

   Quoting from rfc5280, section 6.1 Basic Path validation (3rd paragraph):

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

   While the certificate and CRL profiles specified in Sections 4 and 5
   of this document specify values for certificate and CRL fields and
   extensions that are considered to be appropriate for the Internet
   PKI, the algorithm presented in this section is not limited to
   accepting certificates and CRLs that conform to these profiles.
   Therefore, the algorithm only includes checks to verify that the
   certification path is valid according to X.509 and does not include
   checks to verify that the certificates and CRLs conform to this
   profile.  While the algorithm could be extended to include checks for
   conformance to the profiles in Sections 4 and 5, this profile
   RECOMMENDS against including such checks.

> a good step-by-step HOWTO is a perfect way how to solve this.

Iff we want usage (2) in the protocol document (the situation where a
server certificate is not signed under a trust anchor from TLS X.509 PKI),
then we need to define it in a fashion that it can be indepedently
implemented in an interoperable fashion.

Iff we refer to PKIX (rfc5280) certificate path validation, then
we MUST specify which parameters to supply as input to the algorithm
described in rfc5280 section 6.1.  Even if many implementations
of PKIX actually use a different algorithm,
like one where you pass a set of trust anchors and the algorithm
will look for a match of the prospective path to any of the trust
anchors by itself, or an algorithm which performs certificate revocation
checking concurrently with basic path validation.

-Martin