Subject: Re: [dane] 1: Q for 1.3

From: Ondřej Surý <[email-masked]>
Date: Fri, 6 Apr 2012 09:32:12 +0200

On 20. 3. 2012, at 14:48, Paul Hoffman wrote:

> On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote:
>> 1. What does this, in 1.3, mean? "This document does not specify how
>> DNSSEC validation occurs because there are many different proposals for
>> how a client might get validated DNSSEC results." We've just said that
>> DNSSEC signatures MUST be validated and referenced DNSSEC RFCs, so what
>> "different proposals" do you mean and why have they no references?

This means that you can get DNSSEC validated results either:

a) from the DNSSEC-aware resolver coded in the application
b) from trusted localhost DNSSEC resolver
c) from trusted DNSSEC resolver over a secured channel (TSIG, SIG0, IPSEC)
d) from trusted DNSSEC resolver over a secured network (802.11x networks)

We may add an reference to RFC4033 Section 7 here.

Ondrej
--
 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: Fri, 6 Apr 2012 09:34:42 +0200

On 20. 3. 2012, at 14:49, Paul Hoffman wrote:

>> 2. Is usage 0 clear enough? For example, a CA cert that's not a trust
>> anchor will have a basicConstraints extension with cA set, but a trust
>> anchor need not have that, so should usage 0 mean "CA certificate or
>> trust anchor" or is it just worth noting that the associated certificate
>> in this usage can be either?

I have no strong opinion on this (or rather I am inclined to "CA certificate or
trust anchor" because that's what I think we originally meant).

What the WG think?

O.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 6 Apr 2012 09:40:58 +0200

On 20. 3. 2012, at 16:36, Paul Hoffman wrote:

> On Mar 20, 2012, at 7:55 AM, Jim Schaad wrote:
> 
>> The length of the field is well known because it is every left in the TLSA
>> RDATA record.  The more interesting question is what happens if there are
>> extra bytes on the end of the data block.  This should probably be an error.
>> But the length of the data field is computed from the TLSA RDATA record and
>> not from the contents of the record.
> 
> Agree. I'm pretty sure this is an error that would be caught in the software signing the zone. I don't see what we can say in 2.1.4 that would not just be confusing, but am open to suggestions.

+1

Section 2.1.4 says:

   The "certificate association data" to be matched.  This field
   contains the data to be matched.  [...]

I just cannot think of any sentence which would not be superfluous (anything like "the data must match exactly" is superfluous in my view).

I am inclined to let this be, but if somebody has better suggestion then hey go ahead and send the text.

O.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 6 Apr 2012 09:42:19 +0200

On 20. 3. 2012, at 16:39, Paul Hoffman wrote:

> On Mar 20, 2012, at 7:59 AM, Jim Schaad wrote:
> 
>> Fair enough comment.
>> Suggested text
>> 
>> If an application fails to match any certificate association, then the TLS
>> session is aborted or never started.
> 
> I think that is OK, but would rather be clearer:
> 
> During the TLS handshake, if none of the certificate associations matches the certificate given by the TLS server, the TLS client MUST abort the handshake.

LGTM, unless I hear any objections from WG, I will ask our authors to implement this.

O.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 6 Apr 2012 09:50:32 +0200

On 20. 3. 2012, at 14:54, Paul Hoffman wrote:

>> 7. Section 8, 2nd para - usage #3 is particularly vulnerable here
>> right? I think that'd be worth calling out, or am I wrong?

Usage #2 is exactly same in this regard...

and since he has control of MX records of the zone, he is also able to receive emails for hostmaster@<zone> and so Usage #0 and Usage #1 is also vulnerable for domain-issued certificates.

E.g. usage #3 is only fastest (and together with usage #2 cheapest), but the difference is counted only in minutes.  And we already say that:

   That administrator could probably get a certificate
   issued anyway, so this is not an additional threat.

But I am open to hear any suggestions how to improve the text.

O.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 6 Apr 2012 09:55:46 +0200

I take it that this was resolved and we don't need code point for sha-384.

Thanks John for the nice argument.

O.

On 21. 3. 2012, at 2:05, Stephen Farrell wrote:

> 
> 
> On 03/21/2012 12:59 AM, John Gilmore wrote:
>>>> 3. In another context the fact that sha-384 is part of the US' suite-B
>>>> (see e.g. RFC 5430) was brought up recently.  Should there be a
>>>> code-point for sha-384?  I don't care, but I don't recall if that was
>>>> considered in the WG discussion.
>> 
>> TLSA does not need a code point for sha-384.
> 
> FWIW, I've no problem with the argument below.
> 
> S
> 
> > The only use that TLSA
>> makes of the specified hash function is for matching the hash in the
>> TLSA record with the certificate or its SubjectPublicKeyInfo.  This
>> matching is independent of the use of hashes within the TLS protocol
>> itself (where sha-384 is mandatory among products designed for US
>> government TOP SECRET use under NSA's "Suite B" program).  The
>> presence of TLSA record(s) do not interfere with the use of sha-384 in
>> TLS itself.
>> 
>> A Suite B server operator who wishes to use TLSA to associate their
>> domain name with a certificate or a public key, without using an
>> unapproved hash function, need only supply the entire
>> SubjectPublicKeyInfo, or the entire certificate, in their TLSA record.
>> They can simply avoid the use of hashes in their TLSA records.
>> This option is fully supported by the draft as it stands, and
>> provides better security than any hash they could have picked.
>> 
>> In addition, I suspect that NSA would, upon reflection, also approve
>> the use of SHA-512 in cases where SHA-384 is not available, such as
>> this one.  (If they wouldn't, then we'd like to know why they trust
>> SHA-384 but don't trust SHA-512!)
>> 
>> We do recommend in 2.1.3 that if the host operator uses a hash in the
>> TLSA record, the record "SHOULD" use the same hash that was used in
>> the signature in the certificate, to assist clients that support a
>> small number of hash algorithms.  This SHOULD does not come into play
>> if the operator does not use a hash, as recommended above.  Also,
>> it's a SHOULD, not a MUST, and given the ready availability of free
>> software that implements it, most clients that support any SHA-xxx
>> algorithm will support all three SHA-256, -384, and -512 algorithms.
>> 
>> 	John
>> _______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
>> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 6 Apr 2012 10:01:41 +0200

Paul,

are you and Jakob able to cook something into Security Considerations
or do you need more guidance from the WG on the text?

O.

On 20. 3. 2012, at 23:24, Jim Fenton wrote:

> But a given DANE client is likely to trust only one (or a small number)
> of DNSSEC validators, as compared with the 100+ root CAs that usually
> need to be trusted. Or looking at it another way, compromise of a given
> DNSSEC validator is likely to impact a smaller number of clients than
> compromise of a given root CA.
> 
> And a client has the choice whether to use an external DNSSEC validator
> at all, which isn't really practical with public CAs.
> 
> I would say that both of these factors mitigate the risk.

On 20. 3. 2012, at 18:13, Paul Hoffman wrote:

> On Mar 20, 2012, at 9:46 AM, Stephen Farrell wrote:
> 
>> It was probably a mistake for me to use disrepute
>> here. (I had a separate comment on the editorial
>> aspect I think.) Its a question about comparing
>> the risk today for TLS clients vs. the risk for
>> DANE clients using external DNSSEC validators.
>> 
>> It seems to me that a DANE client trusting an external
>> DNSSEC validator is as vulnerable as a current TLS
>> client trusting a set of CAs in that any CA or any
>> external validator can assert any key for any domain.
>> 
>> If that's true, and if we're less likely to hear about
>> DNSSEC validators being hacked (compared to public CA
>> compromises) then a DANE client with an external
>> validator could be worse off than a current TLS client
>> depending on the current public CAs.
>> 
>> The counter-argument is probably that a random DNSSEC
>> validator is a less interesting target than a public
>> CA which may affect the probability of a problem
>> occurring that affects a given DANE client. OTOH,
>> public CAs ought to have more defenses compared to
>> that random DNSSEC validator, and some external
>> DNSSEC validators will be attractive targets, so
>> its not clear to me how the overall risk for a
>> client pans out, when comparing the status quo
>> (today's TLS client) vs. a DANE client with an
>> external DNSSEC validator.
>> 
>> But the impact on the client is the same, its
>> vulnerable to being presented with the wrong key
>> for any domain and accepting that.
>> 
>> So my question might be better phrased as: is the
>> above correct, and if so, is text needed to call
>> that out in the draft?
>> 
> 
> I would say "yes", this seems like a reasonable security consideration that isn't covered in the security considerations in the DNSSEC specs.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 6 Apr 2012 10:11:17 +0200

Stephen,

did you meant this text:

On 21. 3. 2012, at 19:34, Stephen Kent wrote:

> What I would say is:
> 
> The public CA model upon which browsers and OS's depend is fundamentally vulnerable, not because it is PKI-based, but because it allows any of these CAs to issue any certificate, with no constraints. Business models adopted by browser and OS vendors, and by the public CAs, have allowed this model to be exploited, with predictable consequences. Recent experiences with compromises of CAs or RAs have lead to very serious security problems that undermine confidence in this system.
> 
> DANE is envisioned as a preferable basis for binding public keys to DNS names (a subset of what PKIs can do in general) because the entities that vouch for the binding of public key data to DNS names are the entities responsible to managing the DNS names in question. While the resulting system still has residual security vulnerabilities, it restricts the scope of assertions that can be made by any entity, consistent with the naming scope imposed by the DNS hierarchy. As a result, DANE embodies the security "principle of least privilege" that is lacking in the current public CA model.

as a general statement in the discussion or a kind of replacement for paragraph in 1.1:

   This solution has gradually broken down because some CAs have become
   untrustworthy.  A single trusted CA that betrays its trust, either
   voluntarily or by providing less-than-vigorous protection for its
   secrets and capabilities, can compromise any other certificate that
   TLS uses by signing a replacement certificate that contains a bogus
   key.  Several real-world occurrances that have exploited such CAs for
   subversion of major web sites (presumably to abet wiretapping and
   large-scale fraud) have brought TLS's CA model into disrepute.

I don't think this is really an ideological statement, but I think it could be worded little bit better to not stir emotions.

O.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 6 Apr 2012 09:24:46 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ondrej Surý
> Sent: Friday, April 06, 2012 12:35 AM
> To: Paul Hoffman
> Cc: dane
> Subject: Re: [dane] 2: Usage 0 clarity
> 
> 
> >> anchor will have a basicConstraints extension with cA set, but a
> >> trust anchor need not have that, so should usage 0 mean "CA
> >> certificate or trust anchor" or is it just worth noting that the
> >> associated certificate in this usage can be either?
> 
> 

I am ambivalent about this in either direction.

To say that it includes the trust anchor may cause problems if the full certificate comparison is used as not all trust anchors are stored on all machines in the certificate format.  

To say that it cannot include the trust anchor may cause problems because the server has no way to know which certificates I have chosen for the trust anchor.

I would say that
1.  This SHOULD NOT be the certificate that the server is using as the trust anchor as in that case the certificate use of 2 would be more appropriate
2.  This MAY be the certificate that the client is using as the TA assuming that the client is using certificates as trust anchor certificates.

Jim

> 
> O.
> --
>  Ondrej Sur
>  vedouc  v zkumu/Head of R&D department
>  CZ.NIC, z.s.p.o.    --    Laboratore CZ.NIC

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 6 Apr 2012 09:26:13 -0700

+1

> Sent: Friday, April 06, 2012 12:42 AM
> To: Paul Hoffman
> Cc: dane list
> Subject: Re: [dane] 6: No matching associations
> 
> >> If an application fails to match any certificate association, then
> >> the TLS session is aborted or never started.
> >
> > During the TLS handshake, if none of the certificate associations matches
> the certificate given by the TLS server, the TLS client MUST abort the
> handshake.
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Apr 2012 10:22:14 -0700

> trust anchor" because that's what I think we originally meant).

Zero people commented earlier, and so far only Jim has. So I think that the WG doesn't care.

Having said that, I disagree with part of Jim's analysis, but would want to hear more from others.

> 2.  This MAY be the certificate that the client is using as the TA assuming that the client is using certificates as trust anchor certificates.

I don't like #1 because it says that usage type 0 and type 2 cannot overlap, but I don't think we need to make that restriction. I think #2 is fine.

However, to answer's Stephen's original question, I think we can clarify simply by adding "Because this usage allows both trust anchors and CA certificates, the certificate might or might not have the basicConstraints extension is present.".

--Paul Hoffman

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 6 Apr 2012 10:32:58 -0700

> Paul Hoffman
> Sent: Friday, April 06, 2012 10:22 AM
> To: dane list
> On Apr 6, 2012, at 12:34 AM, Ondrej Sur  wrote:
> 
> >>> 2. Is usage 0 clear enough? For example, a CA cert that's not a
> >>> trust anchor will have a basicConstraints extension with cA set, but
> >>> a trust anchor need not have that, so should usage 0 mean "CA
> > I have no strong opinion on this (or rather I am inclined to "CA
> > certificate or trust anchor" because that's what I think we originally meant).
> >
> > What the WG think?
> 
> 
> > To say that it includes the trust anchor may cause problems if the full
> certificate comparison is used as not all trust anchors are stored on all
> machines in the certificate format.
> >
> > To say that it cannot include the trust anchor may cause problems because
> the server has no way to know which certificates I have chosen for the trust
> anchor.
> >
> > I would say that
> > 1.  This SHOULD NOT be the certificate that the server is using as the
> > trust anchor as in that case the certificate use of 2 would be more
> appropriate 2.  This MAY be the certificate that the client is using as the TA
> assuming that the client is using certificates as trust anchor certificates.
> 
> I don't like #1 because it says that usage type 0 and type 2 cannot overlap,
> but I don't think we need to make that restriction. I think #2 is fine.
> 
> However, to answer's Stephen's original question, I think we can clarify
> simply by adding "Because this usage allows both trust anchors and CA
> certificates, the certificate might or might not have the basicConstraints
> extension is present.".

This does not give me any major heartache.   And this is probably the type of thing lots of implementation experience should get us a much better idea of what works and what fails

Jim

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Apr 2012 10:45:04 -0700

> or do you need more guidance from the WG on the text?

Looking over the responses on this thread, we can answer Stephen's concern with a new sub-section in the Security Considerations.

--Paul Hoffman

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 6 Apr 2012 20:14:10 +0200

> This does not give me any major heartache.   And this is probably the type of thing lots of implementation experience should get us a much better idea of what works and what fails

Also works for me.  (nit: remove last 'is')

O.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Apr 2012 21:08:20 -0400

At 10:11 AM +0200 4/6/12, OndÞej Sur˜ wrote:
>>  The public CA model upon which browsers and 
>>OS's depend is fundamentally vulnerable, not 
>>because it is PKI-based, but because it allows 
>>any of these CAs to issue any certificate, with 
>>no constraints. Business models adopted by 
>>browser and OS vendors, and by the public CAs, 
>>have allowed this model to be exploited, with 
>>predictable consequences. Recent experiences 
>>with compromises of CAs or RAs have lead to 
>>very serious security problems that undermine 
>>confidence in this system.
>>
>>  DANE is envisioned as a preferable basis for 
>>binding public keys to DNS names (a subset of 
>>what PKIs can do in general) because the 
>>entities that vouch for the binding of public 
>>key data to DNS names are the entities 
>>responsible to managing the DNS names in 
>>question. While the resulting system still has 
>>residual security vulnerabilities, it restricts 
>>the scope of assertions that can be made by any 
>>entity, consistent with the naming scope 
>>imposed by the DNS hierarchy. As a result, DANE 
>>embodies the security "principle of least 
>>privilege" that is lacking in the current 
>>public CA model.
>
>
>as a general statement in the discussion or a 
>kind of replacement for paragraph in 1.1:
>
>I don't think this is really an ideological 
>statement, but I think it could be worded little 
>bit better to not stir emotions.
>
>O.

I was responding to on-list comments re the 
subject text. Ido find the wording of 1.1 to be 
awkward and potentially vague. I think my text is 
clear (but wordier :-)) and provides a technical 
security rationale for why the DANE approach is 
preferred over the current browser trust model. 
(I prefer that wording to "TLS's CA model" since 
I see no TLS specs that embody the model we're 
discussing.)

Steve

---

From: John Gilmore <[email-masked]>
Date: Tue, 10 Apr 2012 16:32:01 -0700

>[seeking a] replacement for paragraph in 1.1:
>

I agree.  That was preliminary text that was part of my initial attempt
to write an introduction describing what motivates the RFC.  I'm happy
to help revise it.

> >>privilege" that is lacking in the current 

I am in agreement with Stephen.  I've tried to adapt his text to fit
directly as a replacement for the too-ideological paragraph from
section 1.1:

    The public CA model upon which TLS has depended is
    fundamentally vulnerable, because it allows any of these CAs to
    issue a certificate for any domain name.  A single trusted CA that
    betrays its trust, either voluntarily or by providing
    less-than-vigorous protection for its secrets and capabilities,
    can compromise any other certificate that TLS uses, by signing a
    replacement certificate that contains a bogus key.  Recent
    experiences with compromises of CAs or their trusted partners have
    lead to very serious security problems, such as the subversion of
    major web sites trusted by millions of users.

Then follow that with the existing final paragraph from the draft
(beginning "The DNS Security Extensions (DNSSEC) provides a similar
model...").  This explains how DNSSEC restricts signing ability solely
to subdomains.  Then finish section 1.1 with this new paragraph,
largely from Stephen:

    DANE [we may need to define the acronym here, since we only
    defined it in the title before now] offers the option to use the
    DNSSEC infrastructure to store and sign keys for use by TLS.  DANE
    is envisioned as a preferable basis for binding public keys to DNS
    names, because the entities that vouch for the binding of public
    key data to DNS names are the same entities responsible for
    managing the DNS names in question.  While the resulting system
    still has residual security vulnerabilities, it restricts the
    scope of assertions that can be made by any entity, consistent
    with the naming scope imposed by the DNS hierarchy.  As a result,
    DANE embodies the security "principle of least privilege" that is
    lacking in the current public CA model.

The draft would then begin section 1.2 which describes how a TLS
client uses DANE.

Is this suitable?

	John

---

From: John Gilmore <[email-masked]>
Date: Tue, 10 Apr 2012 16:44:42 -0700

> > On Mar 20, 2012, at 7:55 AM, Jim Schaad wrote:> >> The length of the field is well known because it is every left in the TLSA>> RDATA record.  The more interesting question is what happens if there are>> extra bytes on the end of the data block.  This should probably be an error.>> But the length of the data field is computed from the TLSA RDATA record and>> not from the contents of the record.> > Agree. I'm pretty sure this is an error that would be caught in the software signing the zone. I don't see what we can say in 2.1.4 that would not just be confusing, but am open to suggestions.

I suggest adding to the end of section 2.1.4 a new paragraph:

  This field occupies the entire RDATA field after the initial usage,
  selector, and matching type fields.  It is an error for this field
  to contain more or fewer bytes than required by its matching type
  and selector; for example, if it is a SHA-256 hash, it must be
  exactly 32 bytes long; if it contains a SubjectPublicKeyInfo, it
  must not contain any extra bytes before or after the ASN.1
  representation of the included key.

	John

---

From: Paul Wouters <[email-masked]>
Date: Tue, 10 Apr 2012 21:26:28 -0400 (EDT)

> directly as a replacement for the too-ideological paragraph from

[...]

> to subdomains.  Then finish section 1.1 with this new paragraph,

[...]

> The draft would then begin section 1.2 which describes how a TLS

I agree and like the suggested texts by John and Stephen. It also
clearly states that DANE limits itself to validating a domain name.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Apr 2012 20:19:39 -0700

Can we get a final wording for this so Jakob and I can turn in a new draft?

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Apr 2012 20:23:08 -0700

>  representation of the included key.

While this sentence it technically true, it is also probably not helpful to implementers. It is true for every format that uses hashes, and yet doesn't appear in many (or any) of those specifications.

--Paul Hoffman

---

From: John Gilmore <[email-masked]>
Date: Tue, 10 Apr 2012 23:19:21 -0700

> While this sentence it technically true, it is also probably not helpful to implementers. It is true for every format that uses hashes, and yet doesn't appear in many (or any) of those specificatio…

Perhaps the Area Director also noticed that trend, and in response is
encouraging working groups to be more specific.  I don't know.  We
could decide to ignore the AD's comment about this aspect of the
draft.  But I thought I'd take a stab at addressing it.

As a programmer, I'm happy to see statements in a spec like "It is an
error for this field to contain..." since it tells me whether I should
be loose and allow sloppy stuff through here (Jon-Postel-style being
liberal in what you accept), or whether I should validate everything
here (because having extra ignored bytes is so useful in attacking
protocols).  Does anyone else have an opinion on whether we should
suggest validation or liberality here?

I'm not wedded to the wording; I'm happy if anybody takes a crack at
it.

	John

---

From: Warren Kumari <[email-masked]>
Date: Wed, 11 Apr 2012 10:42:11 -0400

> Can we get a final wording for this so Jakob and I can turn in a new draft?

We seem to have settled on the text in: 
http://www.ietf.org/mail-archive/web/dane/current/msg04605.html

If the authors could incorporate this, that would be great...

W

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Apr 2012 08:57:34 -0700

> If the authors could incorporate this, that would be great...

Done. 'Twill be in the next rev, which should be out soon.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 Apr 2012 22:47:28 +0200 (MEST)

O. wrote:
> I have no strong opinion on this (or rather I am inclined to
> "CA certificate or trust anchor" because that's what I think we
> originally meant).
> 
> What the WG think?

To me, that discussion about CA certs, their attributes and
(an ALWAYS local concept of) trust anchors is pretty confusing
-- and IMO unnecessary.

This is about the text here, right?

  http://tools.ietf.org/html/draft-ietf-dane-protocol-18#section-2.1.1

      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 service on a host.  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
      constraint" because it limits which end entity certificate may be
      used by a given service on a host.  The target certificate MUST
      pass PKIX certification path validation and MUST match the TLSA
      record.

Since this is explicitly referencing TLS(!), I would find it much
clearer if it would refer to the protocol bits of TLS that are meant
to be used/affected, rather than about some fuzzy theoretical concepts
of CAs and trust anchors -- details that should be left to PKIX
(in its entirety for usage 0 and 1).

The TLS PDU this is about is the "(Server) Certificate" handshake message
described here:

   http://tools.ietf.org/html/rfc5246#section-7.4.2

   [...]

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

As you can see, the TLS handshake message can contain ONLY 1 PATH,
therefore the "that must be found in any of the PKIX certification paths"
in -18 IMO does not make sense, there is exactly ONE path conveyed
by TLS, and there is exactly ONE path that results from a successful
PKIX certificate path validation.  And DANE-protocol should better not try
to discuss in section 2.1.1. the black magic art that some fancy
TLS clients perform between parsing Server Certificate and
completing PKIX certificate path validation.

(for populating a UI with "I accept the risk, continue anyway", those
details might be relevant, but IMO that should go into a seperate section,
potentially into security considerations).

Usage 1 always refers to the VERY FIRST cert in the Server's Certificate
handshake message, "the sender certificate", which must always be present
in that handshake message, even when the server is using a self-signed
cert, and independent of whether that self-signed cert is an
X.509v1, X.509v3 BC:cA=TRUE or X.509v3 BC:cA=FALSE cert.

Usage 0 should refer to any other but_the first cert in that message,
i.e. one of the certs _following_ the sender's cert.  For Usage 0 the
check of whether that cert is a valid CA cert or permissible TrustAnchor
(i.e. has the correct attributes for that) will be provided by the
PKIX path validation function.  DANE does not (and IMHO SHOULD NOT) try
to check certs attributes for usage 0, but leave this entirely up
to the PKIX path validation function.

Complication is created by TLS clients that perform a full-blown
certificate path discovery for the very first certificate,
the "sender's certificate", and use all other certs as mere "hints"
for that discovery.  A full-blown certificate path discovery might
cause not only correct certs conveyed by the server to be substituted,
but arbitrary stray certs, except for the "sender's certificate" itself,
to be entirely ignored during the PKIX certificate path validation
following the certificate path discovery.

So it will be essential that the DANE implementation verifies that the
cert (or SPKI) identified through TLSA usage 0 is part of the
VALIDATED certification path, not just that the TLSA referenced cert
was conveyed in the Server's Certificate handshake message
(which by itself, for some fancy clients, can be entirely meaningless).

The additional question, of whether to allow the specification
of a trust anchor in TLSA usage 0, is even more difficult to answer.
First of all, the question is misleading, because "trust anchor" is
always a local notion, and potentially even a situation specific
notion even though a lot of PKI software treats trust anchors as
global&omnipotent and lumps all of them into one single store. 

Also, whether or not an implementation of TLS includes a self-signed
rootCA as the final cert (n>1) in the Server's Certificate handshake
message is an implementation detail of the TLS implemenation and
may or may not be configurable.  But as the excerpt quote from TLS
above shows, the _receiver_ of the Certificate handshake message
will usually _ignore_ such a self-signed RootCA cert at the end
of the chain during certificate path validation.  The trust
anchor information used by the receiver will not necessarily
match the self-signed RootCA cert in the server's PKI credential,
and the receiver (client in our case) might additionally
store&process trust anchor information in non-cert format
internally, so that matching by cert or by cert-hash may not be
possible for a TLSA record that identifies a trust anchor by
cert or cert-hash.  But it is even more complicated
than that, because the peer/client might use entirely different
certs as trust anchors than the server.

A typical problem for usage 0 and differing notions of trust
anchors is created by cross-certification.  What some might be
unaware of, this is actively used in today's TLS X.509 PKI!

Most (if not all) of the public CAs in the TLS X.509 PKI have
created 2048-bit RSA root certs by now.  But these root certs
are pre-configured as trust anchors only in new software
installations or updates, and not known to old installations.
In order to become acceptable to the old installed base as
well, many CAs have created additonal cross-certs for their
new 2048-bit roots, signed by their older 1024-bit roots.

For best interop, one would configure the server with the
forward chain to the old 1024-bit root, so that it sends
the 2048-bit cross-cert in the Server's Certificate handshake
message, and new clients would substitute that cross-cert
with their new 2048-bit trust anchor during certificate path
discovery or certificate path validation rather than verifying
the server-supplied cross-cert with the old 1024-bit trust anchor.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Apr 2012 20:56:51 -0400

>If the authors could incorporate this, that would be great...

I have a couple of minor problems with some of the text John  provided.

   ... A single trusted CA that
     betrays its trust, either voluntarily or by providing
     less-than-vigorous protection for its secrets and capabilities,
     can compromise any other certificate that TLS uses, by signing a
     replacement certificate that contains a bogus key.

The key is not "bogus." It is the binding of the key to the name that is bogus.

How about:

Any of the CAs accepted as trust anchors can issue a certificate 
representing any web site. Thus a compromised CA can issue a 
certificate that claims to represent a targeted web site, essentially 
replacing the legitimate certificate for the web site (for affected 
users).

Recent experiences with compromises of CAs or their trusted partners 
have lead to very serious security problems, such as the subversion 
of major web sites trusted by millions of users.

The web sites may not have been subverted. What happened was that 
users were no longer able to verify that they were connecting to the 
web sites they indicated via the URLs that the users employed.

Steve

---

From: John Gilmore <[email-masked]>
Date: Thu, 12 Apr 2012 13:32:32 -0700

> I have a couple of minor problems with some of the text John  provided.

OK.

> The key is not "bogus." It is the binding of the key to the name that is bogus.

I agree that "bogus key" was shorthand.  Yes, the binding is not
appropriate.  Yes, the key is valid in the sense that it has the
proper bits set to operate with the encryption algorithm.  But the key
*is* bogus, false, insecure, inappropriate, malevolent,
untrustworthy...  because its private key is known to the attacker,
not to the true owner of the site.  But we haven't mentioned the
attacker, and shouldn't; this is an introduction.

The draft also uses the term "bogus keys" earlier in the introduction,
in a context where it's clear what makes them false ("If secret keys
are revealed, or if public keys can be replaced by bogus keys, these
systems provide little or no security.")

> web sites they indicated via the URLs that the users employed.

I presume you were quoting the first sentence and commenting on it in
the second.  

You're being way too technical here.  The web sites were subverted in
the strong sense that many users' interactions and credentials (login
names and passwords) were recorded by the man-in-the-middle and then
used against the interests of those users.  I believe that some
governments used those credentials by changing the account passwords
or deleting the accounts from the service, so the relevant activists
could no longer communicate, but just now I'm having trouble finding a
public reference that supports that belief.

The users were indeed "connecting to the web sites they indicated via
the URLs that the users employed".  Users could even verify that they
were talking to the intended web site.  The problem was that that
connection was being observed in the clear by a malevolent third party
who acted as a man in the middle of their encrypted connection.

See for example:

  https://www.eff.org/deeplinks/2011/08/iranian-man-middle-attack-against-google
  https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack
  http://www.rijksoverheid.nl/bestanden/documenten-en-publicaties/rapporten/2011/09/05/diginotar-public-report-version-1/rapport-fox-it-operation-black-tulip-v1-0.pdf
  https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-https
  https://www.freedom-to-tinker.com/blog/sjs/web-browsers-and-comodo-disclose-successful-certificate-authority-attack-perhaps-iran
  http://www.thetechherald.com/articles/CAs-respond-to-EFF-report-on-problems-with-SSL-certificates/13265/
  http://www.zdnet.com.au/eff-finds-evidence-of-more-cas-breached-339325136.htm
  http://www.appfail.com/read/304/Comodo-SSL-Certificate-Authority-Breach/
  http://www.metafilter.com/106990/DigiNotar-SSL-certificate-compromise
  http://blog.thoughtcrime.org/ssl-and-the-future-of-authenticity
  http://files.cloudprivacy.net/ssl-mitm.pdf
  https://www.f-secure.com/weblog/archives/00002231.html
  http://www.wired.com/threatlevel/2011/03/comodo-compromise/
  http://news.techworld.com/security/3336205/trustwave-issued-digital-certificate-allowing-ssl-spying/
  
	John

---

From: John Gilmore <[email-masked]>
Date: Sat, 14 Apr 2012 17:03:46 -0700

> ...                               The web sites were subverted in

EFF staffers helped me find the reference.  A Javascript injection
attack was done by the Tunisian Internet Agency in January 2011,
during the "Arab Spring".  This attack captured login and password
information when Gmail, Yahoo, and Facebook users logged in from
Tunisia.  The government (or someone!) then logged into those
accounts, possibly downloaded information from them, and deleted the
accounts so that the users no longer had access to their accounts.
They also apparently used information from the accounts to locate and
arrest or detain the users, who were reporting on the government
shooting unarmed citizens.  See:

  https://www.eff.org/deeplinks/2011/01/eff-calls-immediate-action-defend-tunisian
  http://www.thetechherald.com/articles/Tunisian-government-harvesting-usernames-and-passwords/12429/
  http://www.techdirt.com/articles/20110126/04453512834/how-facebook-dealt-with-tunisian-government-trying-to-steal-every-users-passwords.shtml
  http://www.theatlantic.com/technology/archive/2011/01/the-inside-story-of-how-facebook-responded-to-tunisian-hacks/70044/

This attack was NOT done on sites accessed via SSL/TLS; it was done on
plaintext accesses to the sites.  At that time, more than a year ago,
most major sites still didn't offer TLS-protected access to their
sites by default, and many didn't offer it at all.  (This incident
pushed Facebook into forcing TLS access all across Tunisia, and
improving their TLS capacity worldwide.  Other companies such as
Google also vastly improved their TLS support after seeing this kind
of attack.  Google also "pinned" a key in their Chrome browser, which
helped them to detect the later Iranian MITM attack that used a bogus
certificate signed by DigiNotar.)

So, the statement that I drafted:

is not supported by the Tunisian incident, which was unencrypted.
However, subsequent attacks throughout 2011 did include attacks on the
TLS CA infrastructure.  See the dozen or so references in my earlier
message:

  https://www.ietf.org/mail-archive/web/dane/current/msg04643.html

many of which describe the same few incidents from different angles.
Also note an independent Syrian MITM attack.  This Syrian attack
injected an invalid certificate that caused browsers to pop up
certificate warnings, relying on users to click right through them:

  https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook

In summary, we have seen three successful country-sponsored MITM
attacks (Tunisia in plaintext in January, Syria with a bogus cert in
May, Iran with a trusted-but-bogus cert in July and August).  We have
seen another successful attempt to create bogus certificates that
would be useful in a country-sponsored MITM attack (Comodo).  We have
also seen some "subordinate root" certificates, useful for the same
purposes, issued to companies that make MITM equipment or that deploy
it against their own employees (Trustwave acknowledged issuing one
such cert, and commenters said "this is a common industry practice").

We don't yet have a smoking gun of an inappropriately issued cert that
produced a documented series of account breakins or deletions.  Nor
even a documented series of government plaintext recordings of
SSL-protected traffic, since documenting wiretapping is usually much
harder than documenting account cancellations.  However, we strongly
suspect that Iran was wiretapping SSL-protected traffic, since their
attempt to MITM Chrome in Iran is how they were first caught, and
since about 300,000 people, mostly in Iran, used the same
trusted-but-bogus "*.google.com" cert to access the DigiNotar OSCP
server from August 4 thru the cert's revocation on August 29).

So here's the current paragraph from Section 1 of draft-19:

   The public CA model upon which TLS has depended is fundamentally
   vulnerable because it allows any of these CAs to issue a certificate
   for any domain name.  A single trusted CA that betrays its trust,
   either voluntarily or by providing less-than-vigorous protection for
   its secrets and capabilities, can compromise any other certificate
   that TLS uses, by signing a replacement certificate that contains a
   bogus key.  Recent experiences with compromises of CAs or their
   trusted partners have lead to very serious security problems, such as
   the subversion of major web sites trusted by millions of users.

I propose modifying the last sentence to say:

               Recent experiences with compromises of CAs or their
   trusted partners have lead to very serious security problems, such
   as the governments of multiple countries attempting to wiretap and/or
   subvert major TLS-protected web sites trusted by millions of users.

Steve, does this make you happy?  If not, please make more suggestions
about how to finish editing this introduction.

If the RFC should include informational references to some of the more
technical or reputable analyses of these incidents, please select
those references from among the ones I've provided (or others), and
add their [foobar] citations after that new final sentence.

	John

---

From: Pieter Lexis <[email-masked]>
Date: Mon, 16 Apr 2012 12:11:24 +0200

Hi John,

On 04/15/2012 02:03 AM, John Gilmore wrote:
> Recent experiences with compromises of CAs or their trusted
> partners have lead to very serious security problems, such as the
> governments of multiple countries attempting to wiretap and/or 

I fully agree with the rationale behind this proposed text. I do,
however, believe that a political statement (about governments) does
not belong in the document.

I propose changing it to:

                 Recent experiences with compromises of CAs or their
   trusted partners have lead to very serious security problems, such
   as wiretapping and/or subvertion of major TLS-protected web
   sites trusted by millions of users.

- --
Pieter

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Apr 2012 13:07:58 -0400

John,

I like the revised final sentence.  I do think we could be a bit more precise
in the earlier text. How about:

    The public CA model upon which TLS has depended is fundamentally
    vulnerable because it allows any of these CAs to issue a certificate
    for any domain name.  A single trusted CA that betrays its trust,
    either voluntarily or by providing less-than-vigorous protection for
    its secrets and capabilities, can undermine the secruity offered
by any certificates employed with TLS. This problem arises because a
compromised CA can issue a replacement certificate that contains a
    bogus key (i.e., a key not corresponding to the entity identified in the
certificate). Recent experiences with compromises of CAs or their
    trusted partners have lead to very serious security problems, such
    as the governments of multiple countries attempting to wiretap and/or
    subvert major TLS-protected web sites trusted by millions of users.

---

From: John Gilmore <[email-masked]>
Date: Mon, 16 Apr 2012 13:12:36 -0700

>     subvert major TLS-protected web sites trusted by millions of users.

I agree with this text, with a minor typo fix (s/secruity/security/).

	John

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 17 Apr 2012 01:12:20 +0200

> I agree with this text, with a minor typo fix (s/secruity/security/).

Also works for me.