Subject: [dane] I-D Action: draft-ietf-dane-protocol-16.txt

From: [email-masked]
Date: Wed, 08 Feb 2012 06:55:49 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

	Title           : Using Secure DNS to Associate Certificates with Domain Names For TLS
	Author(s)       : Paul Hoffman
                          Jakob Schlyter
	Filename        : draft-ietf-dane-protocol-16.txt
	Pages           : 27
	Date            : 2012-02-08

   TLS and DTLS use PKIX certificates for authenticating the server.
   Users want their applications to verify that the certificate provided
   by the TLS server is in fact associated with the domain name they
   expect.  TLSA provides bindings of keys to domains that are asserted
   not by external entities, but by the entities that operate the DNS.
   This document describes how to use secure DNS to associate the TLS
   server's certificate with the intended domain name.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-16.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-protocol-16.txt

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Feb 2012 07:03:38 -0800

While we are waiting to see if the WG chairs want to move the document to WG LC, y'all have been prolific with your editorial reviews. Here's a new draft with those editorial fixes.

--Paul Hoffman

---

From: Peter Palfrader <[email-masked]>
Date: Wed, 8 Feb 2012 17:00:03 +0100

On Wed, 08 Feb 2012, Paul Hoffman wrote:

> While we are waiting to see if the WG chairs want to move the document
> to WG LC, y'all have been prolific with your editorial reviews. Here's
> a new draft with those editorial fixes.

Just two or three nits:

| 1.1.  Certificate Associations
| 
|    A certificate association is formed from a piece of information
|    identifying a certificate with the domain name where the data is
|    found.

I'm not a native speaker, but should this be s/with/and/?  An
association is something that combines two things.  Therfore, you form
an association from A _and_ B, thereby associating A _with_ B.

Should it be 'a domain name' instead of 'the domain name'?

Which data is found at the domain name?

|            The data used to identify the certificate consists of either
|    a PKIX certificate or a hash of a PKIX certificate.

The data used to identify a certificate can be other things too, like a hash
of its public key, as we later specify.  How about:

} The data used to identify the certificate can be for example a PKIX
} certificate or a hash of a PKIX certificate.

| 4.3.  Pass PKIX Validation and Use Trust Anchor
| 
|    Certificate usage 2 is used to specify a certificate, or the public
|    key of such a certificate, that must be used as a trust anchor when
|    validating the end entity certificate given by the server in TLS.

|    This usage is sometimes referred to as "trust anchor assertion" and
|    allows a domain name administrator to specify a new trust anchor,
|    such as if the domain issues its own certificates under its own CA
|    that is not expected to be in the end users collection of trust
|    anchors.

I stumbled over the "such as if".  Maybe replace with something else like
"for example if" or "useful when".

Also, "the end users collection" is missing a possessive apostrophe.

| 9.  Security Considerations
[ssl proxy mitm]
|                           The client, seeing the proxy's new certificate
|    for the supposed destination will not set up a TLS session.  Thus,
|    such proxies might choose to aggressively block TLSA requests and/or
|    responses, even though this is not a recommended practice.

That last sentences doesn't make any sense.  If the proxy blocks TLSA
requests then the dnssec status will be bogus, preventing TLS entirely.
(Now that I mention this, I realize this has already been pointed out by
Bill Owens recently.)

Cheers,
-- 
                           |  .''`.       ** Debian **
      Peter Palfrader      | : :' :      The  universal
 http://www.palfrader.org/ | `. `'      Operating System
                           |   `-    http://www.debian.org/

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Feb 2012 09:24:55 -0800

>> a new draft with those editorial fixes.

But good ones!

> | 1.1.  Certificate Associations

Man, this whole paragraph has gotten stale without anyone noticing.

> an association from A _and_ B, thereby associating A _with_ B.

Yes, "and".

> Should it be 'a domain name' instead of 'the domain name'?

"The" is correct because it the data is found at one domain name.

> Which data is found at the domain name?

Good catch.

> } certificate or a hash of a PKIX certificate.

Actually, I'd rather just remove the sentence; it doesn't add anything to this introductory text. In fact, neither does the next one. Really, all we want to be describing is the high-level idea of a certificate association; the real definition is in the body. How about:

A certificate association is formed from a piece of information identifying a
certificate (such as the contents of the certificate or a trust anchor to
which the certificate chains) and the domain name where the data is found.
This document only applies to PKIX <xref target="RFC5280"/> certificates, not
certificates of other formats.

> Also, "the end users collection" is missing a possessive apostrophe.

Yep.

> (Now that I mention this, I realize this has already been pointed out by

This is a substantiative issue, one that should be dealt with in WG LC.

--Paul Hoffman

---

From: James Cloos <[email-masked]>
Date: Wed, 08 Feb 2012 14:39:56 -0500

nits (based on a diff -U1 15 16):

> [RFC6394] lists the ones that the protocol in this document is
> meant to apply to.

Don't dangle prepositions.  Make it:

  [RFC6394] lists the ones to which the protocol in this document
  is meant to apply.

The earlier post was correct that "such as if" needs revision.

I beleive that:

> Clients that validate the DNSSEC signatures themselves

should be:

  Clients which validate the DNSSEC signatures themselves

(These are /nits/ after all. :)

While:

> The client may not have an associated root certificate in its
> trust store

is properly grammatical (is that redundant?), I wonder whether some
readers will confuse "may" and "MAY"?  If so, s/may/might/ ought to
avoid that confusion.  (Notice ought instead of should. :)

(A recent thread on another ietf list grew out of a complaint about
using miniscule may/should/shall et al.)

> certificate I1 that directly signed end entity certificate S1
> of server

s/of server/of the server/, yes?

And in the same paragraph:

> Such association would not suffer

s/Such association/Such an association/

Given that §A.2.2.  Provisioning with NS Records still says "THIS
SECTION NEEDS TO BE WRITTEN OR REMOVED.", what exactly is it supposed
to be about?  "Provisioning with NS Records" doesn't say much.  Unless
it was to be about putting TLSA RRs in the parent zone with the NS and
DS RRs???

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Feb 2012 12:26:58 -0800

> it was to be about putting TLSA RRs in the parent zone with the NS and

To be honest, I don't remember. If the person who suggested this section can refresh our memory, that would be great. It would be even better if they proposed text for it.

--Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Wed, 8 Feb 2012 12:39:49 -0800

>  [RFC6394] lists the ones to which the protocol in this document

This is the sort of nonsense up with which one should not put.

"Don't end a sentence with a preposition" is a completely bogus rule,
made up in the 19th century by grammarians who thought Latin was the
acme of languages, so if you couldn't do something in Latin it ought
not be allowed in English either.  Actual writers of actual English
have been using sentence-final prepositions all the way back to
_Beowulf_.

Forcing prepositions to precede something often ruins the flow of the
sentence, and your revision is an excellent example of that.

zw

---

From: Pieter Lexis <[email-masked]>
Date: Thu, 09 Feb 2012 10:31:05 +0100

Hi,

On 02/08/2012 03:55 PM, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the DNS-based
> Authentication of Named Entities Working Group of the IETF.

I was hoping that the term "Pass PKIX Validation" would have some
clarification (hopefully I'm not kicking the hornets' nest here).

When I google the term[0], I get some 300 results. When I search for the
phrase without the word 'DANE'[1] I get 1 result (a comment in a
shibboleth source file).

I suggest adding something like the following text to section 2.1.1.:
======
The term 'to pass PKIX validation' in this document refers to the
successful building (or traversing) of the PKIX certificate chain using
the algorithm described in [RFC 5280]
======

This way there is imho no question about what it means.

- --
Pieter

0 - https://encrypted.google.com/search?q=%22Pass%20PKIX%20validation%22
1 -
https://encrypted.google.com/search?q=%22Pass%20PKIX%20validation%22+-DANE

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Feb 2012 07:02:52 -0800

> clarification (hopefully I'm not kicking the hornets' nest here).

I believe it is a hornets' nest that was already kicked by many, yes.

> https://encrypted.google.com/search?q=%22Pass%20PKIX%20validation%22+-DANE

Are others happy with this formulation?

--Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 09 Feb 2012 07:50:31 -0800

> Are others happy with this formulation?

No, but you knew that.

I promised to file an issue on this and I really will get to it either 
today or tomorrow.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Feb 2012 08:37:40 -0800

> No, but you knew that.

We should not assume anything.

> I promised to file an issue on this and I really will get to it either today or tomorrow.

Instead of filing an issue, consider sending proposed alternate text that says exactly what you want the document to say.

--Paul Hoffman

---

From: Bill Owens <[email-masked]>
Date: Fri, 10 Feb 2012 15:51:07 -0500

> This is a substantiative issue, one that should be dealt with in WG LC.

So, now that we're officially in WGLC, how should this be dealt with?
Or is it the case that only Peter and I care about this language, and
everyone else is satisfied with the current statement?

If the discussion would be helped by looking at alternative language,
I would suggest something along these lines:

Proxies are sometimes configured to permit inspection of HTTPS
sessions by acting as a man-in-the-middle between the TLS client and
server. In this scenario, the client must first be configured with a
new trust anchor whose private key is kept on the proxy. When the
proxy receives an HTTPS request, it creates a new TLS session with the
server, and sets up another TLS session with the client using a
self-signed certificate. Since that certificate chains to the trust
anchor installed in the client, the HTTPS session acts normally from
the user's perspective. However, a TLSA-aware client would get a
certificate association from the DNS that does not match the
self-signed certificate from the SSL proxy and would abort the TLS
connection. Blocking TLSA queries or responses in order to mount a
downgrade attack on the TLSA protocol would be detected by the DNSSEC
validator as a failure of authenticated denial of existence and result
in the TLSA query being marked bogus, again leading the client to
abort the TLS connection. Someone employing such a system might
therefore choose to prevent the deployment of TLSA-aware clients.
Developers who add TLSA capabilities to their clients might also
choose to perform PKIX validation using locally-configured trust
anchors first, and skip the TLSA process if the validation succeeds.

The only part I'm concerned about is the assertion that the DNSSEC
validation will come back bogus; I think that's true, and some simple
tests in my sandbox environment seem to confirm it, but I'd like
someone with more expertise to confirm it. . .

Bill.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 Feb 2012 23:32:16 +0200

> someone with more expertise to confirm it. . .

Assume you don't have signing keys for the target domain
nor to any parent domain:

You can't generate valid signature with the right key
because you don't have it.

You can't send fake signature because it would be bogus.

You can't substitute the key because it would not match
the DS from parent or the TA for root and thus be bogus.

You can't strip the DNSSEC data because the parent says it
should be there. If you strip that, you need to apply this
whole argument to the parent. And the root can't be
stripped because it would be bogus due to presence of
TA but not DNSSEC data.

Thus given assumptions, there is no way to tamper with
secure data without causing it to be regarded as bogus.

-Ilari

---

From: Bill Owens <[email-masked]>
Date: Fri, 10 Feb 2012 16:41:24 -0500

> stripped because it would be bogus due to presence of

And you can't block or modify the response containing the TLSA record
because the NSEC/NSEC3 record for that name includes TLSA in the type
bitmap, and therefore the denial of existence fails, right? Likewise
if you block both the TLSA and NSEC/3 records, because every record in
a signed zone has to have an NSEC/3 or be proven not to exist?

Bill.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Feb 2012 13:56:30 -0800

> So, now that we're officially in WGLC, how should this be dealt with?

Yes, maybe even with an appropriate change to the subject line. :-)

> everyone else is satisfied with the current statement?

Not the case: Jakob and I care as well.

--Paul Hoffman

---

From: James Cloos <[email-masked]>
Date: Fri, 10 Feb 2012 17:11:08 -0500

It seems that those who want to use TLS proxies and also support
DANE-aware clients which are compliant with our drafts will need to
fully proxy DNS, too.

Just like they have to provide the inside clients with a cert to act as
a root tls trust anchor, they will need to provide a DS RR for . which
they control, verify the outside sigs, and re-sign everything before
passing it on to the inside clients.

This is, really, no different than what they already do to TLS.

They also would need to do that for CMS and OpenPGP, should they care
about encrypted email, too.  Et cetera, und so weiter, and so on.

-JimC

---

From: Zack Weinberg <[email-masked]>
Date: Fri, 10 Feb 2012 15:20:41 -0800

> Instead of filing an issue, consider sending proposed alternate text that says exactly what you want the document to say.

It is a substantive change, but sure, why not.

Add to the end of section 1.1:  "Three of the four types of
association defined in this document ("usages") make use of a
_certificate chain_, beginning with the target certificate from the
TLS handshake, and ending with a _trust anchor_. This document does
not specify how a DANE client constructs this chain; however, one
algorithm for doing so is in [RFC5280].  Chain construction may
include 'validation' checks for certificates that are ill-formed or
contrary to client policy; again, this document does not specify any
such checks."

In section 2.1.1, change all four usage definitions to read:

  0 -- The certificate chain MUST include a CA certificate which
matches the TLSA record, and MUST terminate in a trust anchor already
known to the client.
  1 -- The target certificate MUST match the TLSA record, and the
certificate chain MUST terminate in a trust anchor already known to
the client.
  2 -- The certificate chain MUST include a CA certificate which
matches the TLSA record. This certificate MUST be treated as a valid
trust anchor for that chain, for this TLS handshake only, whether or
not it was already known to the client.
  3 -- The target certificate MUST match the TLSA record.  The client
MUST accept this certificate regardless of the contents of the chain.

Replace sections 4.1 through 4.4 inclusive with this text:

4.1. Chain Through CA

   Certificate usage 0 specifies a CA certificate, or the public key
   of such a certificate, that must appear in the certificate chain
   that the client has constructed from the target certificate in the
   TLS handshake.  This usage is sometimes referred to as "CA
   constraint", because it limits which CAs may issue certificates for
   a given host name.

4.2. Chain From Target

   Certificate usage 1 specifies an end-entity certificate, or the
   public key of such a certificate, that must begin the certificate
   chain that the client constructs.  This usage is sometimes referred
   to as "service certificate constraints", because it limits which
   end entity certificate may be used by a given host name.

4.3. Chain To Novel Trust Anchor

   Certificate usage 2 specifies a CA certificate, or the public key
   of such a certificate, that must appear in the certificate chain
   that the client constructs, and is to be treated as the trust
   anchor for that chain.This usage is sometimes referred to as "trust
   anchor assertion", because it allows a domain name administrator to
   specify use of a trust anchor that may not already be known to the
   client.

4.4. Match Target Certificate, Skip Chain Construction

   Certificate usage 3 specifies a certificate that must appear as the
   target certificate in the TLS handshake, and requires the client to
   accept this certificate without going through the normal process of
   chain construction and location of a trust anchor.  However, the client
   SHOULD still perform any validation checks that apply to the certificate
   itself, rather than the chain (such as for improper name information,
   insufficiently large keys, or insecure hash algorithms). This usage is
   sometimes referred to as "domain-issued certificate", because it
   allows for a domain name administrator to issue certificates for a
   domain without involving a third-party CA.

In appendix B, delete all occurrences of the string "pass PKIX
validation and", change all occurrences of the string "PKIX validation
chain H" to "certificate chain H".  Change the first two occurrences
of the string "C passes PKIX validation in H" to "H is a valid chain
from C to a known trust anchor".  Change the third occurrence of that
string to "H is a valid chain from C to R".

zw

---

From: Tom Ritter <[email-masked]>
Date: Fri, 10 Feb 2012 19:39:31 -0500

Chrome has key pinning working already, such that it will hard fail if
the cert for gmail (for example) doesn't match what it has pinned.
Same problem: the proxy shows a different cert.  Chrome solves this by
making any user installed cert override a pin.[1]

If a TLSA-aware client _has_ a trust store, and certs can be added to
it, then perhaps it can do the same: a cert that was installed
manually (such as by the user for a proxy tool or a network admin for
corporate use) will not hard-fail on a DANE failure.  It may fail, but
it must be allowed to be overridden.

If a TLSA-aware client does not have a trust store, or certs may not
be added to, then it's (probably) currently hard failing for the proxy
in question already.  If it hard fails for the cert vs DANE, not much
different.

-tom

[1] http://www.imperialviolet.org/2011/05/04/pinning.html

---

From: Tom Ritter <[email-masked]>
Date: Fri, 10 Feb 2012 20:09:09 -0500

> not it was already known to the client.

I think "CA certificate" is the wrong phrase to use, because people
will interpret it to mean "A certificate, for a CA I've heard of",
rather than its intended definition of "A certificate that will act as
a trust anchor in a chain."  I propose simply removing 'CA'.

> MUST accept this certificate regardless of the contents of the chain.

I'm nervous about that extra statement.  What if the certificate is a
384-bit RSA certificate?  MUST the client accept it?  4.4 clarifies
this question, noting such checks, but I still prefer the simpler "The
target certificate MUST match the TLSA record."

>   constraint", because it limits which CAs may issue certificates for

I'd like to highlight we've changed "validation chains for the end
entity certificate given by the server in TLS" to "certificate chain
that the client has constructed from the target certificate in the TLS
handshake".  That may have repercussions, I'm not sure what they would
be.

I'll add the following changes in Section 8.2

   Value    Short description
   ----------------------------------------------------------
   0        Chain through & match trusted CA
   1        Chain through trusted CA & match EE
   2        Chain through & match certificate
   3        Match certificate

I'm in favor of clarifying 'Pass PKIX Validation', and I think this is
a reasonable way to do it.

-tom

---

From: Zack Weinberg <[email-masked]>
Date: Fri, 10 Feb 2012 17:19:24 -0800

> a trust anchor in a chain."  I propose simply removing 'CA'.

The intent there is "CA certificate" as opposed to "end-entity
certificate" in PKIXese - this is a distinction based solely on the
contents of the certificate, not its position in the constructed
chain.  I am open to better ways to phrase this, but I think we do
need the qualifier.

> target certificate MUST match the TLSA record."

Good point, but with your one-sentence version I'm worried that the
difference from usage 1 is insufficiently clear.  How about

  3 -- The target certificate MUST match the TLSA record.  The client
  MUST skip chain construction in this case, but SHOULD still validate
  the certificate itself (for instance, checking for unacceptably weak
  keys and hash algorithms).

which is a more precise cut-down of what I put in 4.4.

> handshake".  That may have repercussions, I'm not sure what they would

That was the intended consequence of this proposal, except that I
didn't mean to convert plural to singular.  How does "one of the
certificate chains that the client has constructed ..." sound?

zw

---

From: Tom Ritter <[email-masked]>
Date: Fri, 10 Feb 2012 21:25:10 -0500

> which is a more precise cut-down of what I put in 4.4.

Fine by me.

> certificate chains that the client has constructed ..." sound?

That's fine.  The other was fine with me to, I was just pointing out
changing it from a chain sent by the server to a chain the client
constructed. I'm not sure if that's strictly part of the 'PKIX
Validaiton' removal, just point it out.

-tom

---

From: Zack Weinberg <[email-masked]>
Date: Fri, 10 Feb 2012 18:37:47 -0800

On Fri, Feb 10, 2012 at 6:25 PM, Tom Ritter <[email-masked]> wrote:
> constructed.

Ah.  Yes, that's necessary - one of the many ways "PKIX validation" is
an underspecified term is that some clients will take the chain
provided by the server more-or-less as is, and some clients will
rewrite it.

zw

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 10 Feb 2012 20:58:00 -0800

> algorithm for doing so is in [RFC5280].  

Could you clarify this citation?  AFAICT, RFC 5280 defines an algorithm for validating a certification path, not constructing one (although it does provide some constraints).  

In general, I do not find the modifications in the proposed text helpful.  On the contrary, ISTM that they open up the possibility of alternative behaviors to RFC 5280 validation without specifying what those alternatives are, which would be bad for interoperability.

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 10 Feb 2012 21:00:56 -0800

> in question already.  If it hard fails for the cert vs DANE, not much

This seems like a good point.  The document already says the following: 
"
   o  A TLSA RRset whose DNSSEC validation state is secure MUST be used
      as a certificate association for TLS unless a local policy would
      prohibit the use of the specific certificate association in the
      secure TLSA RRset.
"

Your proposal above seems like a local policy that would override TLSA.  Do you think we need to spell things out more?

--Richard

---

From: Zack Weinberg <[email-masked]>
Date: Fri, 10 Feb 2012 21:51:31 -0800

On Fri, Feb 10, 2012 at 8:58 PM, Richard L. Barnes <[email-masked]> wrote:
> Could you clarify this citation?  AFAICT, RFC 5280 defines an algorithm
> for validating a certification path, not constructing one (although it does
> provide some constraints).

You are correct; I confess I did not make it all the way through RFC 5280.

Unfortunately, if RFC 5280 doesn't define path construction, I am not
aware of _any_ specification that does.  The easiest way forward would
be to make the sentence read "This document does not specify how a
DANE client constructs or validates this chain" and not give a
reference.

> ISTM that [the proposed modifications] open up the possibility of
> alternative behaviors to RFC 5280 validation[,] without specifying
> what those alternatives are[.]

Yes. That is precisely the point of the change.

> which would be bad for interoperability.

On the contrary, it is for interoperability's sake that DANE must
*not* attempt to specify chain construction or validation.  No two
existing clients use exactly the same algorithm; as far as I know
*nobody* claims complete conformance to RFC 5280 path validation, and
as we've just discovered, path _construction_ may not even be
specified at all.

Thus, what may have seemed like a perfectly sensible, uncontroversial,
minor detail -- define a peripheral piece of the DANE algorithm by
reference to the standard in which it is central -- is in fact the
imposition of a major, compatibility-breaking, out-of-scope change
requirement on basically every TLS client in the world.  It has to go.

zw

---

From: Zack Weinberg <[email-masked]>
Date: Fri, 10 Feb 2012 21:55:29 -0800

Addendum: I found a PKI Forum white paper on path construction.  It's
old (2002), but there doesn't seem to be anything more recent.  Note
sentence 2 of the abstract: "The certification path construction
process has not been standardized."

http://www.oasis-pki.org/pdfs/Understanding_Path_construction-DS2.pdf

---

From: Martin Rex <[email-masked]>
Date: Sat, 11 Feb 2012 08:03:41 +0100 (MET)

There is an informational(!) document published as RFC:

  http://tools.ietf.org/html/rfc4158

Internet X.509 Public Key Infrastructure:
Certification Path Building

but it is not a "standard" of any kind.

btw. I could not find "4158" in PKIX (rfc5280).

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 11 Feb 2012 09:37:07 -0800

> contrary to client policy; again, this document does not specify any

Letting a client decide to make a chain in a way that is different than RFC5280 will lead to unexpected security consequences, probably all bad. Although I commiserate with you that parts of the PKIX path rules are obtuse and obscure, in essence saying "you can skip them" will lead to clients making chains that should not be made, thus reducing the security of the protocol.

--Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Sat, 11 Feb 2012 10:10:52 -0800

On Sat, Feb 11, 2012 at 9:37 AM, Paul Hoffman <[email-masked]> wrote:
> Letting a client decide to make a chain in a way that is different
> than RFC5280 will lead to unexpected security consequences,
> probably all bad.

THEY ALREADY DO (make/validate chains in a different way, that is).

The sky has not fallen, and it is inappropriate for DANE to mandate
that clients change.

zw

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 11 Feb 2012 19:01:44 +0000

On 02/11/2012 05:51 AM, Zack Weinberg wrote:
> On Fri, Feb 10, 2012 at 8:58 PM, Richard L. Barnes<[email-masked]>  wrote:

> You are correct; I confess I did not make it all the way through RFC 5280.

Hang on. Are you saying that you're being highly critical
of a document you've not actually read?

That makes your argument bogus hearsay doesn't it?

Apologies if I've misinterpreted you.

Please do go read it if you're going to complain about it
like this.

 From my p-o-v *informed* criticism of 5280 or anything
else is welcome, Hearsay is not.

S

---

From: Zack Weinberg <[email-masked]>
Date: Sat, 11 Feb 2012 11:34:52 -0800

> of a document you've not actually read?

I am not being critical of RFC 5280 itself.

I am objecting to the inclusion in DANE of a *requirement to comply
with* RFC 5280, RFC 4158, or any other published standard for path
construction or validation that may be found, because I know that many
existing TLS clients do not comply with any such standard -- see for
example http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/b13773e6df6927bf?fwc=1
-- and I see it as out-of-scope for this WG and likely to hinder
adoption.

zw

---

From: Sean Leonard <[email-masked]>
Date: Sat, 11 Feb 2012 13:10:37 -0800

> -- and I see it as out-of-scope for this WG and likely to hinder

This comment, I fear, is out of line.

I wrote a detailed comparison in the follow-up to the thread you cited, 
detailing point-by-point how libpkix stacks up against RFC 5280, citing 
the actual source code. See "Re: libpkix maintenance plan" and the 
Google Spreadsheet "RFC 5280 vs. CERT_PKIXVerifyCert" 
<http://goo.gl/r2sT3>. libpkix does, in fact, fully comply with RFC 
5280. (I cited several deficiencies in CERT_PKIXVerifyCert, but those do 
not affect RFC 5280 compliance--they only affect the flexibility of 
specifying optional inputs and outputs that RFC 5280 suggests.) The 
general opinion of Mozilla and the NSS maintainers and users is to move 
to the libpkix validation path for all applications.

-Sean

---

From: Bill Owens <[email-masked]>
Date: Sat, 11 Feb 2012 16:49:53 -0500

>      prohibit the use of the specific certificate association in the

On the one hand, there are a number of characteristics that I'd like
to have in any DANE-aware browser that I use, especially if it mirrors
the Chrome behavior. But those seem like implementation choices, and I
don't think they'd be appropriate in the protocol definition. And as
much as I'd like to say that DANE compliance is absolute, with no
option to override, the choices that have already been made in
existing software and network designs seem to make that an untenable
position.

In the end, I think our best bet for obtaining sensible behavior will
be lobbying the browser authors, not mandating it in the spec.

Bill.

---

From: John Gilmore <[email-masked]>
Date: Sat, 11 Feb 2012 15:10:36 -0800

> > anchors first, and skip the TLSA process if the validation succeeds.

I agree that this paragraph needs work.  But what's the purpose of the
paragraph?  To recommend to developers how they can code to subvert
the end-to-end privacy that we claim to offer?  I believe that's
counterproductive to the entire purpose of the DANE committee.  I
would say something closer to:

  The privacy of clients that use TLSA cannot be circumvented by
  traditional TLS proxies.  By design, the most that such proxies can
  do is to prevent TLSA-protected connections from succeeding.

The "use locally-configured trust anchors first and skip TLSA"
approach would return us to the bad old (current) days in which
untrustworthy CA trust anchors can subvert any TLS connection.  I
thought we'd purged that concept from the draft, but apparently this
Gorgon has more ugly heads.  It's a straightforward downgrade attack
against TLSA -- and the draft is recommending that we make it
*succeed*?!

Of course, the real way to subvert TLSA is to subvert DNSSEC, e.g. by
subverting the "root keys" in the DNS software in all the clients.  I
sincerely hope that we aren't going to suggest that in the RFC.

	John

---

From: Bill Owens <[email-masked]>
Date: Sat, 11 Feb 2012 19:13:33 -0500

> against TLSA -- and the draft is recommending that we make it

First, a locally-configured trust anchor is by definition not
'untrustworthy', although we can debate the wisdom and ethical
ramifications of using them to enable MITM proxies. We can imagine a
scenario in which a piece of malware installs its own trust anchor,
though I haven't heard of such a thing; I would certainly use that
threat as an argument for better behavior on the part of the client
(flagging TLS connections when a local trust anchor has trumped TLSA,
for example) but I wouldn't expect that this risk would change
anyone's mind about allowing or prohibiting locally-configured
anchors.

Second, the draft isn't recommending anything. The text addresses a
legitimate security consideration, an impact that DANE will certainly
have on the network as it exists today, and moreover an interaction
that ought to be considered when someone is implementing the protocol.
>From what I can see, that is precisely what we're supposed to put in
that section.

> sincerely hope that we aren't going to suggest that in the RFC.

There are any number of ways to subvert TLSA, of which the simplest is
to decree that TLSA-capable clients cannot be used within the network.
I think it's safe to assume that the authors of those clients would
rather see their software used in as many places as possible, and
won't want their support of TLSA to automatically disqualify them from
environments that use proxies. Certainly that seems to be Google's
opinion, as in the text that I quoted a few days ago. I would note
that they have allowed local anchors to override their own pins -
designed to protect their business, not anyone else - and that says to
me they know they don't have any other choice.

There is perhaps one small bright spot in this distasteful situation.
Those 'enterprise customers' who have managed to purchase unrestricted
subordinate CAs from foolish providers will no longer be able to have
their proxies be invisible. They'll either have to prevent the
deployment of TLSA or fall back to locally-installed trust anchors,
either one of which will require that they reveal themselves. Even if
it takes some time to reach that state, I think it's a win.

Bill.

---

From: Ondrej Mikle <[email-masked]>
Date: Sun, 12 Feb 2012 02:43:43 +0100

> That makes your argument bogus hearsay doesn't it?

While I don't condone not reading the specs before raising criticism, it should
be noted that there is not a *single one* TLS client that adheres to RFC 5280.

This is likely out of scope of DANE WG, but in case anyone is interested, look here:

https://github.com/hiviah/pyx509

I've noticed some "oddities" (like accept an unknown X.509v3 extension marked as
critical) while debugging the code above and comparing to common TLS clients and
ASN.1 parsers. I noted few certs that various TLS clients see differently (look
at complete certchain sent by server):

Bad Certificate Policies
 1256481 | www.koscom.co.kr   | 2011-09-23 20:29:33.875519-04 | 2011-11-11
03:49:58.552574-05
 1084745 | www.check.co.kr    | 2011-09-23 20:01:42.251445-04 | 2011-11-11
03:17:40.602504-05
   88122 | bill.signkorea.com | 2011-09-23 17:24:22.871876-04 | 2011-11-11
00:16:39.087095-05

Bad CRL dist points, empty octet string (commerzbank.fr), bad certificate
policies (multicert.com) - bmpString in cpsUri instead of ia5String
  551047 | ocsp.teste.multicert.com | 2011-09-23 18:37:21.16381-04  | 2011-10-12
03:27:13.25224-04
   75915 | banking.commerzbank.fr   | 2011-09-23 17:22:28.884534-04 | 2011-11-11
00:14:25.335163-05
  509059 | mon.teste.multicert.com  | 2011-09-23 18:30:43.734521-04 | 2011-11-11
01:30:22.560218-05
 1641032 | ocsp.teste.multicert.com | 2011-10-13 03:28:48.592789-04 | 2011-11-11
01:38:26.453528-05

Ondrej Mikle

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 12 Feb 2012 02:12:21 +0000

> be noted that there is not a *single one* TLS client that adheres to RFC 5280.

That'd possibly be a fine thing to raise on the TLS list
and/or the PKIX list but not really here.

> This is likely out of scope of DANE WG, but in case anyone is interested, look here:

Yes, as above.

> https://github.com/hiviah/pyx509

That URL above points at someone's (yours?) *alpha* code from
this month. I think its great that you're writing code and
making that available, but its not relevant as backing for
what seems to be a "don't really do what 5280 says" argument,
which some seem to be making here.

I also see no evidence there about other TLS codebase support
for 5280. I'd be quite interested to see such evidence, which
I guess does exist but hasn't been collected in a presentable
format, other than as an occasional anecdote, and I'd like to
see that raised on the TLS and/or PKIX lists as appropriate.
As you said yourself, its not really on topic here. (But
nonetheless worthwhile gathering and then properly publishing
somewhere, or sending a URL around if its been done but not
noticed so much.)

But back on topic: as I think I said before, if you have
trouble with TLS, go there. If you've a peeve with PKIX,
then go there. This list is for doing DANE which is not
in the business of re-defining the minutiae of either PKIX
or TLS. All of our lists are equally open so there's no
barrier to entry.

That's why I'm jumping in here, things would go quite
funny if we had concurrent IETF WG's stomping on one another
like that, saying "do RFC XXX, except not this bit and not
that bit and do this other thing instead of section foo"
etc. Sorry if I'm maybe over-reacting but I do get a sense
that there's that desire here and, especially if not based
on reading the actual documents, doing that seems like a
bad plan.

S

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

---

From: Zack Weinberg <[email-masked]>
Date: Sat, 11 Feb 2012 18:24:55 -0800

> or TLS. All of our lists are equally open so there's no

But this is exactly what I've been saying!

Existing clients do not consistently follow any particular chain
construction or validation algorithm.  That's bad, but it's not DANE
(the WG)'s job to fix. Therefore, DANE (the spec) must not require any
particular chain construction or validation algorithm!

zw

---

From: Ondrej Mikle <[email-masked]>
Date: Sun, 12 Feb 2012 04:02:47 +0100

On 02/12/2012 03:12 AM, Stephen Farrell wrote:
> but its not relevant as backing for

FWIW, I was aiming more for a "be aware that real-world implementations do all
kinds of non-RFC-5280 stuff" argument (that's what the most of A.1 section is
about).

> on reading the actual documents, doing that seems like a

Sorry about the interruption. I'm still learning to get the "feeling" about
what's appropriate for which WG.

Ondrej

---

From: Paul Wouters <[email-masked]>
Date: Sun, 12 Feb 2012 00:06:37 -0500 (EST)

On Sat, 11 Feb 2012, John Gilmore wrote:

> counterproductive to the entire purpose of the DANE committee.

Agreed. At most I would say that TLS proxies need to be integrated more
closely with DNSSEC and DANE and overriding locally installed policy is
required to ensure the user and their software know when to bypass the
the security offered by DANE that would mark this as an attack.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sun, 12 Feb 2012 00:11:01 -0500 (EST)

> it takes some time to reach that state, I think it's a win.

They'll just go back to forcing their users to use a SOCKS proxy :/
Then the local client does not do any DNS lookups or IP connections, it
only connects to the SOCKS proxy and receives its MITMed data.

Note that "good" MITM SOCKS proxies exist too, such as "tor".

Paul

---

From: John Gilmore <[email-masked]>
Date: Mon, 13 Feb 2012 15:57:40 -0800

> be lobbying the browser authors, not mandating it in the spec.

RFC 2119 is where words like MUST and SHOULD are defined.  It says:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

7. Security Considerations

   These terms are frequently used to specify behavior with security
   implications.  The effects on security of not implementing a MUST or
   SHOULD, or doing something the specification says MUST NOT or SHOULD
   NOT be done may be very subtle. Document authors should take the time
   to elaborate the security implications of not following
   recommendations or requirements as most implementors will not have
   had the benefit of the experience and discussion that produced the
   specification.

Indeed, that's the situation here.  If the implementer ignores the
MUST here, the security of the whole protocol disappears (along with
the entire reason we bothered defining the protocol).

So I think we should retain the MUST, but should also "take the time
to elaborate the security implications of not following" it, in
the subsequent sentence or paragraph in the draft.

If your code run TLS and makes DNS TLSA queries, while ignoring
validated TLSA records, then you have a TLS implementation (with some
extra useless DNS overhead), not a TLSA implementation.  A TLSA
implementation has to give effect to the TLSA records that it sees.
To use the preferred wording, it MUST give effect to those records.

If your program isn't sure it wants to always use TLSA,
then it should have a configuration flag or checkbox for "Use TLSA"
or "Don't use TLSA".  If the user ticks the "Use TLSA" flag
and the TLSA records don't match the cert, the program should abort
the TLS connection.

	John

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 13 Feb 2012 19:07:24 -0500

> as we've just discovered, path _construction_ may not even be

The current DANE spec doesn't say anything about path construction algorithms.  It just specifies constraints on which chains are valid (however they are constructed). 

W.r.t. validation: This document is about PKIX certificates.  PKIX certificates are defined by RFC 5280, including how they are validated.  There is nothing new here.  

Sorry to be so brief.  Not feeling well.

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 13 Feb 2012 19:09:28 -0500

> particular chain construction or validation algorithm!

Construction: There's nothing in this document about that.
Validation: We inherit that by using PKIX certs.  

(See other message.)

--Richard

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 13 Feb 2012 16:24:03 -0800

> Construction: There's nothing in this document about that.

I think it is nonetheless useful to state explicitly that DANE does
not require any particular path construction algorithm.

> Validation: We inherit that by using PKIX certs.

And that's wrong.  Have I been insufficiently clear about what the
problem is?  Many existing clients are *not* conformant to that aspect
of RFC 5280 (as pointed out upthread, some of them do plan to change
that in the future, but it will be quite some time).

It is therefore necessary for DANE to contain an explicit statement
that it does not require clients to implement any particular path
validation algorithm.

zw

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Feb 2012 16:39:38 -0800

> not require any particular path construction algorithm.

-1. There are lots of things that the document does not contain.

> problem is?  

We might agree on the problem and disagree on your propsed solution.

--Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 13 Feb 2012 18:33:32 -0800

> -1. There are lots of things that the document does not contain.

Why is it important to you that the document not contain this statement?

> We might agree on the problem and disagree on your propsed solution.

Just to make sure we actually agree on the problem, would you mind 
saying what you think it is, in your own words?

zw

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 13 Feb 2012 22:29:35 -0500

> that it does not require clients to implement any particular path

If the document doesn't say anything about path validation, then what the are DANE records talking about in the first place?

Suppose there's a client that validates cert chains by checking whether each cert in the chain contains more octets than the prior cert.  Or whether the serial numbers are in ascending order.  Or whether the signatures are valid, but regardless of, say, the CA bit?  What does DANE tell these guys?

I think I agree with Paul here: There are some implementors that think they're doing good path validation, which may or may not be RFC 5280 compliant.  I don't see the benefit of giving those implementors a warm fuzzy here, most obviously because (1) they evidently don't care whether they're doing compliant validation or not, and (2) blindly opening the door to non-standard validation algorithms is just nihilism (see above).  

--Richard

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 13 Feb 2012 19:51:03 -0800

On Mon, Feb 13, 2012 at 7:29 PM, Richard L. Barnes <[email-masked]> wrote:
> If the document doesn't say anything about path validation, then what the are
> DANE records talking about in the first place?

They're talking about whatever the client's chain construction
algorithm produced, and they modify the behavior of its validation
algorithm.  This can be defined without having to require any
particular construction or validation algorithms.

> Suppose there's a client that validates cert chains by checking whether each cert
> in the chain contains more octets than the prior cert. Or whether the serial numbers
> are in ascending order. Or whether the signatures are valid, but regardless of, say,
> the CA bit? What does DANE tell these guys?

It is not for DANE to tell them that they are doing validation wrong.

> I think I agree with Paul here: There are some implementors that think they're
> doing good path validation, which may or may not be RFC 5280 compliant.
> I don't see the benefit of giving those implementors a warm fuzzy here

It's not about giving implementors warm fuzzies; it's about removing
an out-of-scope requirement from a specification where it does not
belong (and incidentally helping adoption and interoperability).

zw

---

From: Sean Leonard <[email-masked]>
Date: Mon, 13 Feb 2012 22:12:02 -0800

On 2/11/2012 1:10 PM, Sean Leonard wrote:
> See "Re: libpkix maintenance plan" and the Google Spreadsheet "RFC 
> 5280 vs. CERT_PKIXVerifyCert" <http://goo.gl/r2sT3>. libpkix does, in 
> fact, fully comply with RFC 5280.

For those who cannot read Google Spreadsheets or have an aversion to 
doing so, here is the CSV version:
http://www.seantek.com/rfc5280/RFC5280vCERT_PKIXVerifyCert.csv

No promises of it being updated.

-Sean

---

From: Sean Leonard <[email-masked]>
Date: Mon, 13 Feb 2012 22:43:51 -0800

On 2/13/2012 7:51 PM, Zack Weinberg wrote:
> On Mon, Feb 13, 2012 at 7:29 PM, Richard L. Barnes<[email-masked]>  
> wrote:

Uh, what you are suggesting might help adoption but will definitely 
hinder interoperability.

Implementation 1 interprets validating the certificate in the sentence: 
"Currently, the client must extract the domain name from the 
certificate, must trust a trust anchor upon which the server's 
certificate is rooted, and must successfully validate the certificate." 
in Section 1 of the DANE draft, as requiring that each certificate has 
ascending serial numbers.

Implementation 2 interprets the same language, as requiring that each 
certificate has descending serial numbers.

Interoperability NOT achieved!

If you define validation to an objective standard (PKIX validation = RFC 
5280 validation), then as long as:
a) Implementation 1 implements the required features of the standard,
b) Implementation 2 implements the required features of the standard, and
c) the DANE record identifies a certificate chain that only exhibits 
features limited to the required features of the standard, THEN:

Implementation 1 and Implementation 2 will achieve the same result 
(valid/not valid). Interoperability achieved!

If the DANE record identifies a certificate chain that exhibits exotic 
features not pinned down by the standard, then one should not expect 
interoperability. That is life. That is why DANE record creators should 
limit themselves to certificate chains that exhibit only that subset of 
features that are pinned down by the standard. If you don't have a 
standard, you have no pins. And if you have no pins, you have an empty 
interoperability set.

-Sean

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Feb 2012 07:14:17 -0800

On Feb 13, 2012, at 10:43 PM, Sean Leonard wrote:

> Uh, what you are suggesting might help adoption but will definitely hinder interoperability.

Zack hasn't even shown that it will help adoption. As he says, some PKIX implementations do not follow the path validation given in 5280. This would lead one to believe that those developers don't care what we say about path validation.

--Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 14 Feb 2012 15:20:22 -0800

> Zack hasn't even shown that it will help adoption. As he says, some PKIX implementations do not follow the path validation given in 5280. This would lead one to believe that those developers don't…

I think this thread has gotten wound up to the point where we are just
throwing strawmen at each other.  Also I have a deadline for an
unrelated project in two days, so I need to let this go for now.

I will come back next week with specific examples of how real
implementations differ from 5280 and/or 4158; I think that will put
this particular conversation on much sounder footing.

For right now, though, I want to say that the scenario I think most
likely if the existing wording survives into the final draft is that
TLSA records will have the side effect of *switching* clients into
5280 compliance mode, and that there are concrete ways in which that
would be Bad (can't go into detail now, search for "transvalidity").

zw

---

From: Martin Rex <[email-masked]>
Date: Wed, 15 Feb 2012 00:36:37 +0100 (MET)

Zack Weinberg wrote:
>Stephen Farrell wrote:

You must be kidding.  ;-)

A document the size of PKIX (rfc5280) that could only be understood
if read in its entirety would definitely belong to the garbage bin.
And PKIX in particular is so pretty confusing and contains a number
of inconsistencies and defects that I believe no one in the IETF
has thoroughly review it, including WG chairs and document authors.

If "having read" would mean anything, then we would be done
with assigning authorship, any kind of review would be redundant.

> construction or validation that may be found, because I know that many

Neither TLS client nor TLS servers should use RFC-4158 *AT ALL*.
A sensible implementation of TLS will restrict itself to pure
certificate path validation and require the CA that issued the
PKI credential to provide a complete and well-formed certification
path.  So an end entity would verify that path on import of the PKI
credential and store it, send it in a TLS certificate message to
the communication peer in a TLS handshake, and the TLS peer would
also simply verify the well-formed certification path when receiving
the Certificate handshake message.

The mess that we're seeing in the installed base is due to

 - serious lack of sensible credential management (verify on import!)
   of PKI credentials in TLS implementations

 - many flawed attempts of TLS peers to cover up for the failure of
   their peer to perform sensible PKI credential management,
   including clear violations of the TLS protocol spec.

-Martin

---

From: Richard Barnes <[email-masked]>
Date: Tue, 14 Feb 2012 18:41:47 -0500

> would be Bad (can't go into detail now, search for "transvalidity").

To save people the googling:
"
# Some certs WOULD be valid if they had the appropriate intermediate certs
# attached to them.  We could ignore that, except that Firefox (and maybe
# other browsers) actually cache intermediate certs, causing these certs to
# become valid if you've been surfing for a while!  So this code attempts to
# compute whether there are any such certs about!
"
<https://github.com/radii/observatory/blob/master/transvalid.py>

To head off this argument: 
This is not an RFC 5280 thing.  This is about path construction.  If a browser caches intermediate certs, then it will construct different certification paths than one that doesn't.  Both types of browsers *validate* certification paths in the same way, namely following RFC 5280 (section 6, fwiw).  As we've agreed before, DANE doesn't have anything to do with path construction, so transvalidity has nothing to do with DANE. 

I think the likely scenario is where we differ: IMO, the most likely thing is that people leave their validation code exactly as-is (5280 or not, regardless of what we say), and add DANE checks on top of it.  So it doesn't matter for these people what we say, so we should say the right thing.

--Richard

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 20 Feb 2012 16:19:05 +0100

> about encrypted email, too.  Et cetera, und so weiter, and so on.

+1

I am not encouraging this, but writing a simple validating DNS proxy which will (re)sign validated DNS records with own private keys should be simple with (lib)unbound.

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: Martin Rex <[email-masked]>
Date: Tue, 21 Feb 2012 19:07:08 +0100 (MET)

Ondrej Sury wrote:
> James Cloos wrote:
> I am not encouraging this, but writing a simple validating DNS proxy
> which will (re)sign validated DNS records with own private keys should
> be simple with (lib)unbound.

I am violently opposed to the extending that nonsense that MITM TLS Proxies
are currently doing (totally subverting PKI) to DNSSEC.

If anything, then there should be a *NEW* Proxy-Protocol, where the browser
is fully aware of the MITM proxy and authenticates that proxy as proxy
and clearly shows to the user that it is talking securely _to_the_proxy_
rather than trying to fake identity assertions of the fly.

There are a number of things that MITM proxies break protocol-wise
including TLS client certs and TLS channel bindings.

If there is a desire for a protocol for a specific purpose, then one
should design a protocol for this particular pupose, rather than
completely subvert and break an existing security protocol and
deceive the end user and consumer about what the technology is
actually doing.

-Martin

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 23 Feb 2012 16:38:25 +0100

Dear WG members,

I have read and re-read this thread (and sorry I havn't been available in last week(s), I've caught some nasty bug) and didn't find any support for Zack's proposal.

Since this have generated a lot of (heated) discussion, I would like to hear simple +1/-1 if we should pursue this discussion further.  I.e. I am asking if there is anybody else supporting Zack's proposal or if there is consensus in WG (which I feel) to not pursue this further?

I think I have already stated this before, that I don't support this idea (as a no-hatted person and as a chair).

Please speak now or never :).

Thanks,
O.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 23 Feb 2012 16:43:49 +0100

> are currently doing (totally subverting PKI) to DNSSEC.

Martin, and I was not saying we should put anything like that in DANE.  I was just stating that it should not stop us.

O.

---

From: Bill Owens <[email-masked]>
Date: Thu, 23 Feb 2012 10:55:05 -0500

> Please speak now or never :).

-1 

I am unqualified to judge whether existing implementations are following the PKIX standards or not; however, I don't buy the argument that requiring the standard as part of DANE is going to prevent adoption. If someone is already ignoring the PKIX standard (for good reason, or not) they're not going to be put off by our reference to it. Philosophically, IETF standards ought to reference each other, and as has already been suggested any objections to PKIX should be taken up with that WG, or perhaps on the new 'therightkey' list.

Bill.

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 23 Feb 2012 08:05:50 -0800

>> Since this have generated a lot of (heated) discussion, I would like to hear simple +1/-1 if we should pursue this discussion further.  I.e. I am asking if there is anybody else supporting Zack's…

I request that instead of calling for consensus on this now,
discussion be suspended for another week.  It is clear to me that I
did not make an adequate case for the change I want, but due to
deadlines on an unrelated project, I have not had time to do any
research with which to make a better case.

zw

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Feb 2012 09:05:11 -0800

On Feb 23, 2012, at 8:05 AM, Zack Weinberg wrote:

> discussion be suspended for another week.  

-1

> It is clear to me that I

If the WG does not support you now, you can still make this argument in IETF Last Call.

--Paul Hoffman

---

From: Stephen Kent <[email-masked]>
Date: Thu, 23 Feb 2012 13:06:21 -0500

At 4:38 PM +0100 2/23/12, OndÞej Sur˜ wrote:
>Dear WG members,
>
>I have read and re-read this thread (and sorry I 
>havn't been available in last week(s), I've 
>caught some nasty bug) and didn't find any 
>support for Zack's proposal.
>
>Since this have generated a lot of (heated) 
>discussion, I would like to hear simple +1/-1 if 
>we should pursue this discussion further.  I.e. 
>I am asking if there is anybody else supporting 
>Zack's proposal or if there is consensus in WG 
>(which I feel) to not pursue this further?
>
>I think I have already stated this before, that 
>I don't support this idea (as a no-hatted person 
>and as a chair).
>

-1 (i.e., I do not support Zack's proposal)

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 23 Feb 2012 15:35:49 -0500

-1

---

From: Tom Ritter <[email-masked]>
Date: Thu, 23 Feb 2012 18:01:08 -0500

> I think I have already stated this before, that I don't support this idea (as a no-hatted person and as a chair).

Sorry it's not a + or -1, but I have to reiterate my earliest
statements from Jan 31.

Since there isn't a -17 for me to work off of, and I have to assume
thing with regards to this has changed - then I remain confused about
the phrase "Pass PKIX Validation" and as far as I can tell, it is not
defined in the document.  I think it should be.

It seems most (?) people think that statement means being compliant
with all of/a section of 5280.  If so, I think it should be clarified
as such.

The following point is good: if clients do non-standard validation
now, requiring compliant validation with DANE will likewise be
ignored, and probably won't slow implementation.

I remain +1 towards clarifying it _somehow_.

-tom

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Feb 2012 00:46:24 +0100

Tom,

just to clarify, since you have stripped Zack's proposal.  (I have reordered paragraphs in your mail a little bit.)

>> I think I have already stated this before, that I don't support this idea (as a no-hatted person and as a chair).

I have asked if you support or not the proposal to drop PKIX validation completely.

> Sorry it's not a + or -1, but I have to reiterate my earliest

----

> with all of/a section of 5280.  If so, I think it should be clarified

This is separate issue from what I have asked.

> I remain +1 towards clarifying it _somehow_.

I am fine with clarifying what 'PKIX Validation' means in our document.

O.

---

From: Tom Ritter <[email-masked]>
Date: Thu, 23 Feb 2012 19:01:33 -0500

Now I'm confused =P I mostly meant "Sorry I'm not giving a 2 character
response and actually making you read stuff."

I am strongly for clarifying what 'PKIX Validation' means.

I'm not against Zack's proposal, I'm not strongly for it.  Consider me
a 0.  I was marginally for it originally, because I considered it a
reasonable attempt to somehow clarify PKIX Validation. I understand
Zack's point, and agree with it somewhat, but I think the point I
repeated is also reasonable.

I put forward the idea of clarifying it to mean "being compliant with
all of/a section of 5280" since that was what *I* thought the
consensus of the group was.  I'm not against defining it as 5280, I'm
marginally for it, because I think it's also a reasonable approach to
clarify PKIX Validation.

I typed more than a + or -1 because I wasn't sure if you were saying
'Last Call on Zack's proposal' or 'Last Call on what we have for the
PKIX Validation terminology.'

-tom.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Feb 2012 17:11:45 -0800

> with all of/a section of 5280.  If so, I think it should be clarified

Good catch. We mean "path validation", which is defined in RFC 5280. We will make the following change (and similar throughout):

0 -- Certificate usage 0 is used to specify a CA certificate, or the public
key of such a certificate, that must be found in any of the PKIX validation
chains for the end entity certificate given by the server in TLS. This usage
is sometimes referred to as "CA constraint" because it limits which CA can be
used to issue certificates for a given host name, port, and protocol. The
target certificate MUST pass PKIX path validation and MUST chain through a CA
certificate (which might be the root of the chain) that matches the TLSA
record.

--Paul Hoffman

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Feb 2012 10:35:18 +0100

RFC 5280 uses "certification path validation" (RFC 5280 Section 6) and "validation chains" are called "certification chains" (RFC 5280 Section 3.2), i.e. this would be:

> key of such a certificate, that must be found in any of the PKIX certification
> paths for the end entity certificate given by the server in TLS. This usage
> target certificate MUST pass PKIX certification path validation and CA certificate
> that matches the TLSA record MUST be included as part of valid certification path.

O.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Feb 2012 06:50:39 -0800

>> that matches the TLSA record MUST be included as part of valid certification path.

Yes, that is more precise. I have changed "validation chain" to "certification path", and "path validation" to "certificate path validation", throughout the document (including in the pseudocode). The main place affected is shown here; let Jakob and I know if there are more changes to be made.

      0 -- Certificate usage 0 is used to specify a CA certificate, or
      the public key of such a certificate, that must be found in any of
      the PKIX certification paths for the end entity certificate given
      by the server in TLS.  This usage is sometimes referred to as "CA
      constraint" because it limits which CA can be used to issue
      certificates for a given host name, port, and protocol.  The
      target certificate MUST pass PKIX certification path validation
      and a CA certificate that matches the TLSA record MUST be included
      as part of a valid certification path.

      1 -- Certificate usage 1 is used to specify an end entity
      certificate, or the public key of such a certificate, that must be
      matched with the end entity certificate given by the server in
      TLS.  This usage is sometimes referred to as "service certificate
      constraints" because it limits which end entity certificate may be
      used by a given host name, port, and protocol.  The target
      certificate MUST pass PKIX certification path validation and MUST
      match the TLSA record.

      2 -- Certificate usage 2 is used to specify a certificate, or the
      public key of such a certificate, that must be used as a trust
      anchor when validating the end entity certificate given by the
      server in TLS.  This usage is sometimes referred to as "trust
      anchor assertion" and allows a domain name administrator to
      specify a new trust anchor, for example if the domain issues its
      own certificates under its own CA that is not expected to be in
      the end users' collection of trust anchors.  The target
      certificate MUST pass PKIX certification path validation, with any
      certificate matching the TLSA record considered to be a trust
      anchor for this certification path validation.

      3 -- Certificate usage 3 is used to specify a certificate, or the
      public key of such a certificate, that must match the end entity
      certificate given by the server in TLS.  This usage is sometimes
      referred to as "domain-issued certificate" because it allows for a
      domain name administrator to issue certificates for a domain
      without involving a third-party CA.  The target certificate MUST
      match the TLSA record.

--Paul Hoffman

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Feb 2012 16:52:22 +0100

Does anybody else have anything to say?

I have one objection to the text suggested by Bill below.  As we don't specify how the DNSSEC validation will be done, we really don't know how this will be implemented.

Thus I suggest just to remove last sentence from existing paragraph:

   SSL proxies can sometimes act as a man-in-the-middle for TLS clients.
   In these scenarios, the clients add a new trust anchor whose private
   key is kept on the SSL proxy; the proxy intercepts TLS requests,
   creates a new TLS session with the intended host, and sets up a TLS
   session with the client using a certificate that chains to the trust
   anchor installed in the client by the proxy.  In such environments,
   the TLSA protocol will prevent the SSL proxy from functioning as
   expected because the TLS client will get a certificate association
   from the DNS that will not match the certificate that the SSL proxy
   uses with the client.  The application that complies with this document,
   seeing the proxy's new certificate for the supposed destination will not
   set up a TLS session.

Specifying a solution for SSL proxies is outside our WG.

O.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 24 Feb 2012 08:01:02 -0800

> Specifying a solution for SSL proxies is outside our WG.

How about something like:

  "SSL proxies operate by requiring the client to contain an additional root certificate belonging to the proxy.  If such functionality is desired for DANE-protected names, the network operator will also need to create a DNSSEC proxy with its alternate root keys stored on the client.  Specifying such a configuration is outside the scope of this document."

---

From: Bill Owens <[email-masked]>
Date: Fri, 24 Feb 2012 11:06:51 -0500

>   "SSL proxies operate by requiring the client to contain an additional root certificate belonging to the proxy.  If such functionality is desired for DANE-protected names, the network operator wil…

I prefer to stick with the narrow interpretation of 'security considerations'; things to consider when implementing and deploying the protocol. Not 'security recommendations' or 'security roadmaps', but 'if you implement DANE, this might happen'.

Bill.

---

From: Tom Ritter <[email-masked]>
Date: Fri, 24 Feb 2012 11:54:55 -0500

+1

On 24 February 2012 10:52, Ondřej Surý <[email-masked]> wrote:
> Thus I suggest just to remove last sentence from existing paragraph

+1

-tom

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Feb 2012 21:02:42 +0100

On 24. 2. 2012, at 15:50, Paul Hoffman wrote:
> Yes, that is more precise. I have changed "validation chain" to "certification path", and "path validation" to "certificate path validation", throughout the

Really minor nit: it's "certification path validation", but as you have it correctly below I assume it's just a typo here (it's very easy to slip, I did have to correct myself too).

> document (including in the pseudocode). The main place affected is shown here; let Jakob and I know if there are more changes to be made.

2.1.1 will be merged to 4, so just make sure you don't forget to update it there when merging the text.

Section 9) Security considerations might be updated to the RFC 5280 terminology as well since it's part of the standard.

I think it would be better to update Appendices A and B too to be aligned with the protocol documentation.

Would I would suggest is to search for word 'chain' and replace it with correct terminology.  If you send me current working draft, I can help and send you back the patch.

>      without involving a third-party CA.  The target certificate MUST

LGTM, thank you very much.

And +1 from me to.

O.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Feb 2012 21:07:08 +0100

Minor nit here:

>      constraints" because it limits which end entity certificate may be

You use singulars in 0,2,3 and here you use plural form "... constraints".

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 25 Feb 2012 16:15:32 -0800

> Really minor nit: it's "certification path validation", but as you have it correctly below I assume it's just a typo here (it's very easy to slip, I did have to correct myself too).

Yep, my typo.

> 2.1.1 will be merged to 4, so just make sure you don't forget to update it there when merging the text.

Errr, I thought that the consensus was to merge 4 into 2.1.1, and then remove 4. If this is not right, let us know and I will unwind those changes from our internal version.

> Section 9) Security considerations might be updated to the RFC 5280 terminology as well since it's part of the standard.

Did that.

> I think it would be better to update Appendices A and B too to be aligned with the protocol documentation.

Can you be specific?

> Would I would suggest is to search for word 'chain' and replace it with correct terminology.  If you send me current working draft, I can help and send you back the patch.

I don't understand this request: "chain" is correct terminology from RFC 5280. It is used throughout that document.

--Paul Hoffman

---

From: Ondřej Surý <[email-masked]>
Date: Sun, 26 Feb 2012 10:37:51 +0100

Well, the last thread I have read was:

>>>> ZW: I support removing the duplication, but I'd prefer to keep the section
>>>> 4 text and lose the section 2.1.1 text -- it's longer, but it's
>>>> clearer IMHO.
>>> 
>>> MM: +1 for that.
>> 
>> PH: It seems like there is a fair amount of support for this editorial change. Are there any objections?
> 
> RB: I do like the fact that 2.1.1 has RFC 2119 language.  But perhaps the single sentences from 2.1.1 could be used as first sentences for the paragraphs in section 4 ?

But I don't really care about where the text goes.

>> I think it would be better to update Appendices A and B too to be aligned with the protocol documentation.

Ok, I'll recheck and send suggestion if I have any.

> I don't understand this request: "chain" is correct terminology from RFC 5280. It is used throughout that document.

You're right.  I have somehow missed that when checking RFC 5280.

O.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 26 Feb 2012 07:25:02 -0800

> But I don't really care about where the text goes.

Good, we'll leave it in 2.1.1 then.

--Paul Hoffman