Subject: RE: Last Call: <draft-ietf-dane-protocol-19.txt> (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 12 Apr 2012 05:33:13 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of The IESG
> Sent: Wednesday, April 11, 2012 6:41 PM
> To: IETF-Announce
> Cc: [email-masked]
> Subject: Last Call: <draft-ietf-dane-protocol-19.txt> (The DNS-Based
> Authentication of Named Entities (DANE) Protocol for Transport Layer
> Security (TLS)) to Proposed Standard
> 
> The IESG has received a request from the DNS-based Authentication of
> Named Entities WG (dane) to consider the following document:
> - 'The DNS-Based Authentication of Named Entities (DANE) Protocol for
>    Transport Layer Security (TLS)'
>   <draft-ietf-dane-protocol-19.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2012-04-25. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

I reviewed this for the Applications Area Directorate when it was -18.  The document was in good shape then, and they've fixed up all concerns I had in the -19 version so it's even better now.

I support publication on the Standards Track.

-MSK

---

From: SM <[email-masked]>
Date: Thu, 12 Apr 2012 00:11:43 -0700

At 18:41 11-04-2012, The IESG wrote:
>[email-masked] mailing lists by 2012-04-25. Exceptionally, comments may be

In Section 1.2:

  "This document applies to both TLS [RFC5246]"

Does this mean that DANE is not applicable for TLS 1.1?

In Section 1.3:

   "A DNS query can return multiple certificate associations, such as in
    the case of a server is changing from one certificate to another."

The sentence seems incorrect.

In Section 2.1.1:

   "The certificate usages defined in this document explicitly only apply
    to PKIX-formatted certificates in DER encoding."

I suggest adding a reference to X.690.

In Section 2.1.3:

   "If the TLSA record's matching type is a hash, having the record use
    the same hash algorithm that was used in the signature in the
    certificate (if possible) will assist clients that support a small
    number of hash algorithms."

As a comment that does not argue for any change, having SHA-256 hash 
as the "lowest" hash excludes SHA-1, a widely deployed hash 
algorithm.  I gather that the WG has made a tradeoff between 
perceived security and ease of deployment.

In Section 3:

   'For example, to request a TLSA resource record for an HTTP server
    running TLS on port 443 at "www.example.com",
    "_443._tcp.www.example.com" is used in the request.  To request a
    TLSA resource record for an SMTP server running the STARTTLS protocol
    on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is
    used.'

HTTPS for www.example.com is a straight-forward example.  In the case 
of a SMTP server, it is not as easy.  Once the target host is 
located, mail.example.com in this case, one might assume that the 
server would advertise that hostname or the domain name used to 
locate the target host as an identity.  That's rarely the case due to 
issues outside the scope of DANE.  It's easier not to use the 
STARTTLS protocol as an example.

In Section 7.2, 7.3 and 7.4:

  "Applications to the registry can request specific values that have
   yet to be assigned."

What is the meaning of "can request specific values" in that sentence?

In Section 8.1:

   "If it is less likely that a user will hear about its trusted DNSSEC
    validators being hacked that it is of a public CA being compromised"

I suggest using "compromised" instead of "hacked".

Regards,
-sm

---

From: Dave Cridland <[email-masked]>
Date: Thu, 12 Apr 2012 09:26:01 +0100

> The sentence seems incorrect.
No, this seems correct, in as much as multiple TLSA records can be  
returned. A forward reference to §A.4 would be handy here.

> HTTPS for www.example.com is a straight-forward example.  In the  
> case of a SMTP server, it is not as easy.  Once the target host is  
> locate the target host as an identity.  That's rarely the case due  
> to issues outside the scope of DANE.  It's easier not to use the  

To expand on this, it's not wholly clear what one might do for SRV  
(or MX) records in general. It's not clear whether a client needs to  
access records for every SRV returned. Moreover, protocols such as  
XMPP do allow a server to use a different certificate depending on  
the called domain, and existant servers do implement this - this  
means that acting upon TLSA records found against purely A/AAAA  
records pointed to in turn by SRV.

It seems to me that, unfortunately, there is a requirement here to  
add a further case, by allowing TLSA records against the SRV-style  
name, such as:

_xmpp-server._tcp.example.com IN TLSA 1 1 1  DEADBEEFCAFE

The above comments about SRV are unfortunate, because I'm already  
concerned with the number of options available. In particular, given  
the relative ease of certificate/key rollover, I think the  
SubjectKeyInfo match could be removed. Moreover, I think it  
absolutely should be for CA certificates - it seems to broaden the  
attack surface (and moreover, broaden the opportunities for confusion  
and failure).

In addition, it's not clear to me that having hashes in lieu of  
complete data is particularly helpful - I do appreciate that it  
removes a not inconsiderable number of octets from the wire, but I'd  
also note that if a full certificate is in DANE, then it's possible  
for a client to check revocation status without connecting to the  
service. This seems to me as potentially useful, and I'd note that  
although the certificates are indeed quite large, they ought to be  
readily cached as well.

Touching on revocation leads on to a further comment - there's only  
very brief mention of how clients should handle revocation status  
checks, and it appears to suggest that a "type 2" certificate should  
not, or even must not, be checked. I'd suggest that at minimum, this  
ought to be clarified. In particular, the security considerations  
refer to type 2, but not type 3, certificates.

Note, incidentally, that §8 refers to "type 2", but §2.1.1 refers to  
"[Certificate] usage 2" - consistency might be preferable here.

As a final comment, I'd presonally like to see some comments about  
how, and when, extended validation information should be checked and  
trusted. It seems to me that such information  should be ignored when  
handling type 2 or type 3 certificates; or at best it should be  
validated independantly using the traditional methods - that is, it  
should be treated as a type 0 or type 1 certificate for the purposes  
of extended validation.

Oh, and one more nit, why not. I can't be the only person who notes  
that the certificate type is a bitfield of "Suppress 5280 validation"  
and "End Entity Cert" flags. I wonder if this might lead to risk if  
new cert types were assigned that did not match this? Is it  
worthwhile making a comment that it's explicitly not a bitfield? I  
may be being overly paranoid, here.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Dave Cridland <[email-masked]>
Date: Thu, 12 Apr 2012 13:18:43 +0100

On Thu Apr 12 12:03:37 2012, Ondřej Surý wrote:
> Please see http://trac.tools.ietf.org/wg/dane/trac/ticket/28 before  
> discussing SRV records
> further.  We have left SRV records on purpose and we expect that  
> this will be solved in
> separate document (for each affected protocol).
> 
> 
Foolish me, I must have missed the reference to that ticket in the  
draft.

Really, if this is out of scope, declare it as such - but then don't  
use SMTP either, given that's very close in spirit to SRV.

But certainly for XMPP, DANE is currently insufficient, which is a  
real shame.

> The hashes are very useful since any UDP DNS packet not able to fit  
> into MTU will cause
> truncation and reconnection to DNS server via TCP.  So almost any  
> full certificate will
> cause two serialized connections anyway UDP and TCP.  If you  
> connect to the service and
> to DNS server, you can make those connections in parallel, which  
> considerably speeds up
> this (because you will need that connection to the service anyway).

Yes, I do follow; perhaps I'm expecting this to be swallowed during  
the DNS phase rather than the service connection phase anyway.

Also, I thought - possibly erroneously - that at least some operating  
systems were using TCP for the connection to the resolver anyway,  
which'd lessen this effect.

In any case, I'm not going to demand that hashes are outlawed, I'm  
mostly moaning about the number of permutations here - testing all  
these is going to drive me spotty.

> > As a final comment, I'd presonally like to see some comments  
> about how, and when, extended validation information should be  
> checked and trusted. It seems to me that such information  should  
> be ignored when handling type 2 or type 3 certificates; or at best  
> it should be validated independantly using the traditional methods  
> - that is, it should be treated as a type 0 or type 1 certificate  
> for the purposes of extended validation.
> 
> I think that Extended Validation is out of the scope of this  
> document.  And if I am not
> mistaken the CA which are able to issue EV certificates are  
> hardcoded in the browsers.
> Thus I think that DANE-aware applications can use standard rules  
> for EV certificates.

I think this needs calling out. EV seems like a very good argument  
for the existence of CAs in a DANE world; I think it would be  
beneficial to touch on the subject if possible.

Dave.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 12 Apr 2012 12:48:51 +0200

> Does this mean that DANE is not applicable for TLS 1.1?

RFC4346 (TLS 1.1) has been obsoleted by RFC5246.  We cannot make references
to obsoleted documents.  As a side note, we don't say "to both TLS 1.2", but
just TLS.

> The sentence seems incorrect.

Dave already commented on this.  I also don't see anything wrong with the
sentence.

> I suggest adding a reference to X.690.

Seems reasonable.

> As a comment that does not argue for any change, having SHA-256 hash as the "lowest" hash excludes SHA-1, a widely deployed hash algorithm.  I gather that the WG has made a tradeoff between perceived security and ease of deployment.

SHA-2 was first published 11 years ago and I don't really think that
applications which will decide to implement DANE will not have support
for SHA-2 family.

The quoted sentence just says: Use closest available algorithm to help
clients (e.g. please don't use SHA-3 if the certificate signature is SHA-256).

> HTTPS for www.example.com is a straight-forward example.  In the case of a SMTP server, it is not as easy.  Once the target host is located, mail.example.com in this case, one might assume that the server would advertise that hostname or the domain name used to locate the target host as an identity.  That's rarely the case due to issues outside the scope of DANE.  It's easier not to use the STARTTLS protocol as an example.

Here the rules from RFC3207 can be applied:

   The decision of whether or not to believe the authenticity of the
   other party in a TLS negotiation is a local matter.  However, some
   general rules for the decisions are:

   -  A SMTP client would probably only want to authenticate an SMTP
      server whose server certificate has a domain name that is the
      domain name that the client thought it was connecting to.

Similar logic applies to DANE, but it's not the DANE which decides the
name, but TLS capable client, which already know which name to expect.

> What is the meaning of "can request specific values" in that sentence?

It's just a note, that we expect that future standards would be able
to assign new values (f.e. new hash algorithms when SHA-3 is out).

> I suggest using "compromised" instead of "hacked".

lgtm

O.
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 12 Apr 2012 13:03:37 +0200

On 12. 4. 2012, at 10:26, Dave Cridland wrote:
> To expand on this, it's not wholly clear what one might do for SRV (or MX) records in general. It's not clear whether a client needs to access records for every SRV returned. Moreover, protocols such as XMPP do allow a server to use a different certificate depending on the called domain, and existant servers do implement this - this means that acting upon TLSA records found against purely A/AAAA records pointed to in turn by SRV.
> 
> It seems to me that, unfortunately, there is a requirement here to add a further case, by allowing TLSA records against the SRV-style name, such as:
> 
> The above comments about SRV are unfortunate, because I'm already concerned with the number of options available. In particular, given the relative ease of certificate/key rollover, I think the SubjectKeyInfo match could be removed. Moreover, I think it absolutely should be for CA certificates - it seems to broaden the attack surface (and moreover, broaden the opportunities for confusion and failure).

Please see http://trac.tools.ietf.org/wg/dane/trac/ticket/28 before discussing SRV records
further.  We have left SRV records on purpose and we expect that this will be solved in
separate document (for each affected protocol).

> In addition, it's not clear to me that having hashes in lieu of complete data is particularly helpful - I do appreciate that it removes a not inconsiderable number of octets from the wire, but I'd also note that if a full certificate is in DANE, then it's possible for a client to check revocation status without connecting to the service. This seems to me as potentially useful, and I'd note that although the certificates are indeed quite large, they ought to be readily cached as well.

The hashes are very useful since any UDP DNS packet not able to fit into MTU will cause
truncation and reconnection to DNS server via TCP.  So almost any full certificate will
cause two serialized connections anyway UDP and TCP.  If you connect to the service and
to DNS server, you can make those connections in parallel, which considerably speeds up
this (because you will need that connection to the service anyway).

> Touching on revocation leads on to a further comment - there's only very brief mention of how clients should handle revocation status checks, and it appears to suggest that a "type 2" certificate should not, or even must not, be checked. I'd suggest that at minimum, this ought to be clarified. In particular, the security considerations refer to type 2, but not type 3, certificates.

True, I think we need to expand Security Considerations for type 3 as well, since PKIX
validation is not performed for Type 3 at all.

> Note, incidentally, that §8 refers to "type 2", but §2.1.1 refers to "[Certificate] usage 2" - consistency might be preferable here.

Good catch.

> As a final comment, I'd presonally like to see some comments about how, and when, extended validation information should be checked and trusted. It seems to me that such information  should be ignored when handling type 2 or type 3 certificates; or at best it should be validated independantly using the traditional methods - that is, it should be treated as a type 0 or type 1 certificate for the purposes of extended validation.

I think that Extended Validation is out of the scope of this document.  And if I am not
mistaken the CA which are able to issue EV certificates are hardcoded in the browsers.
Thus I think that DANE-aware applications can use standard rules for EV certificates.

> Oh, and one more nit, why not. I can't be the only person who notes that the certificate type is a bitfield of "Suppress 5280 validation" and "End Entity Cert" flags. I wonder if this might lead to risk if new cert types were assigned that did not match this? Is it worthwhile making a comment that it's explicitly not a bitfield? I may be being overly paranoid, here.

I think you might be overly paranoid :), but on the other hand a simple note would hurt either.  I am leaving this up to our editors discretion.

O.

---

From: Peter Palfrader <[email-masked]>
Date: Thu, 12 Apr 2012 13:34:59 +0200

> Dave already commented on this.  I also don't see anything wrong with the

It's probably a language nit, not a factual issue.  Maybe the sentence
would read better as follows:

| A DNS query can return multiple certificate associations, such as in
| the case of a server which is changing from one certificate to another."
                       ^^^^^

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

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 12 Apr 2012 13:36:45 +0200

> | the case of a server which is changing from one certificate to another."

Ah, true.  I am almost blind to these kind of issues after reading this
document too many times.

Thanks go to both of you.

O.

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 12 Apr 2012 14:33:22 +0200

On 12. 4. 2012, at 14:18, Dave Cridland wrote:

> Foolish me, I must have missed the reference to that ticket in the draft.
> 
> Really, if this is out of scope, declare it as such - but then don't use SMTP either, given that's very close in spirit to SRV.
> 
> But certainly for XMPP, DANE is currently insufficient, which is a real shame.

We would certainly welcome new document defining interaction of XMPP and DANE.  But I think
that this needs to be crafted in the XMPP working group.

> I think this needs calling out. EV seems like a very good argument for the existence of CAs in a DANE world; I think it would be beneficial to touch on the subject if possible.

Alright point taken.  I have opened http://trac.tools.ietf.org/wg/dane/trac/ticket/39

O.

---

From: [email-masked]
Date: Thu, 12 Apr 2012 14:03:57 -0700 (PDT)

> to obsoleted documents.  As a side note, we don't say "to both TLS 1.2", but

I have no involvement with DANE or the rest of this debate, but I wanted to
point out that this simply isn't true. IDNits warnings to the contrary
notwithstanding, references to obsoleted specifications are not only allowed,
but in some cases absolutely required. 

It all depends on what the reference is for. If you're making a normative
reference to some protocol element that's supposed to interoperate with
current versions, you need to reference the latest version.

If, however, as in this case, you're talking about interoperating with multiple
versions of TLS, you really need to reference the specifications you intend to
support. Because otherwise readers are going to assume that you only mean TLS
1.2 here, irrespective of whether or not you omit the specific version in
prose.

				Ned

---

From: Martin Rex <[email-masked]>
Date: Thu, 12 Apr 2012 23:35:34 +0200 (MEST)

> I suggest using "compromised" instead of "hacked".

Similar to what John complains about, comparing trusted DNSSEC validators
to public CAs is comparing apples and oranges.

The equivalent of a trusted DNSSEC validator in the PKIX world would
be an SCVP server/service!

The compromise of the DNSSEC zone data for DANE is probably equivalent to
the compromise of an organizational CA signed by a public CA with
name constraints to that DNS zone.

The compromise of an unconstrained public CA in the PKIX world would
be equivalent to a compromise of the root DNSSEC zone data in the DANE world.

-Martin

---

From: SM <[email-masked]>
Date: Thu, 12 Apr 2012 15:30:19 -0700

>to obsoleted documents.  As a side note, we don't say "to both TLS 1.2", but

Not really.

On an unrelated note, 
draft-ietf-mile-rfc6046-bis-09 should reference 
RFC 4346 normatively instead of the informative 
reference.  The was a discussion about a protocol 
where the argument was MUST implement TLS 1.1 and SHOULD implement TLS 1.1.

>applications which will decide to implement DANE will not have support

The date of publication of a specification 
doesn't materially affect what's available out there.

>clients (e.g. please don't use SHA-3 if the certificate signature is SHA-256).

I'm ok with SHA-2 btw.

>name, but TLS capable client, which already know which name to expect.

I have read the rules from RFC 3207.  You could 
use the above the declare the issue as out of 
scope.  However, if you take that path, it's 
better to drop the example as well.

>to assign new values (f.e. new hash algorithms when SHA-3 is out).

This is IANA paperwork.  You don't really have to 
fix it.  Someone reading that text literally 
might presume that you can request a "specific" 
value.  It seems to me that the objective is not 
about having to deal with applications for lucky numbers.

This draft faces problems which are similar to 
what RFC 6125 tried to tackle.  RFC 6125 does not 
fix the Application protocols mess.  There was a 
mention of deployment on the DANE mailing 
list.  DANE is conditional on DNSSEC 
deployment.  It is conditional on applications 
using it.  Although it's not up to the working 
group to tackle all that, you'll end up with half 
a solution as long as you don't tackle issues relating to RFC 6125.

Section 1 of the draft is well-written.  There 
were some comments by other participants about Section 8.  For example:

   "Current public CAs are assumed to have better defenses than current
    DNSSEC validators, but that perception cannot be proven one way or
    another.  Similarly, if DNSSEC validation becomes more common after
    the release of this document, it cannot be predicted whether or not
    that will increase the level of security of DNSSEC validators more or
    less than the security of public CAs.  Thus, it is difficult to
    foresee which system has a higher risk."

I would not make the assumption mentions in the 
first sentence of that paragraph.  I don't mind 
if the working group decides that it is appropriate to make that assumption.

Parts of Section 8.2 about DNS caching could be 
moved outside the Security Consideration 
section.  It is more useful as guidance for 
application implementations of the protocol.

Regards,
-sm

---

From: Martin Rex <[email-masked]>
Date: Fri, 13 Apr 2012 05:59:47 +0200 (MEST)

> but in some cases absolutely required. 

Since the question keeps coming up again and again and again...

I firmly believe all three Obsoletion markers in the meta-data
of rfc5246 to be factually incorrect, so I filed an errata for this.

https://www.ietf.org/mail-archive/web/tls/current/msg08595.html

-Martin

---

From: [email-masked]
Date: Fri, 13 Apr 2012 00:24:03 -0700 (PDT)

> https://www.ietf.org/mail-archive/web/tls/current/msg08595.html

An entirely reasonable position to take IMO, but even if it weren't it doesn't
mean references to obsolete specifications aren't allowed.

				Ned

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 Apr 2012 15:21:38 -0400 (EDT)

> applications which will decide to implement DANE will not have support

Using SHA1 at this point is actually more of a risk then using SHA2. If
you want to run your OS or device in FIPS mode, you may not use SHA1 for
anything. I am seeing a lot of breakage in fips mode where apps just
assume a sha1 call never fails. That's long past us now. Don't count
on sha1 being available.

Paul

---

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

> returned. A forward reference to §A.4 would be handy here.

I think he was referring to the grammar.  Shouldn't it say:

 "A DNS query can return multiple certificate associations, such as in
 the case of a server that is changing from one certificate to
 another."

["that" inserted.]

	John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Apr 2012 09:52:39 -0400

I have raised these comments in the WG numerous times, I am raising
them here as I do not believe that anyone is going to implement the
specification as currently described.

As currently written, the specification attempts to mandate client
behavior when DANE records are encountered in ways that are outside
the scope of interoperability. While the objective of the authors is
to mandate certain behavior they consider necessary for security
reasons, what they end up doing is attempting to substitute their own
judgement for that of the security experts who advise the client
providers.

Client providers already ignore significant parts of the PKIX
specification because they do not meet their performance criteria. In
particular virtually all browsers treat inability to obtain OCSP
certificate status as being equivalent to 'good'. This is a terrible
security design, one that every CA would like to see change. But it is
also a fact that we have been trying to get this changed for ten years
without success.

The browser providers do not hard fail on OCSP because doing so would
require them to wait for the OCSP response within the TLS handshake
and this is considered an unacceptable performance degradation. I do
not like this situation, but I can either play Canute and tell the
tide to turn or I can consider it to be a fact and try to work round
it.

DANE attempts to fix PKI with another mandate that is certain to be
ignored. In this case the mandate is to establish a critical
dependency on the DNSSEC trust chain despite the easily observed fact
that less than 97% of DNS resolvers will pass anything other than
A/AAAA and CNAME records.

Section 4 of the draft mandates a client hardfail if the DNSSEC trust
chain cannot be obtained. This is essential if the client is going to
use DNSSEC to establish certificate constraints just as certificate
revocation is an essential part of the PKIX model. But no browser
provider can expect to succeed with a product that simply stops
working when the user tries to surf the Web from a coffee shop.

Since the coffee shop problem is not intentional we might imagine that
it will eventually go away. But this puts DANE in a deployment
deadlock bind. Nobody is going to fix their coffee shop routers until
there is a need to and that need won't exist until the coffee shop
routers are fixed.

It is not just coffee shops that are the problem either. It might seem
really easy to put an SSL cert on a server and keep it up to date but
IETF participants represent the 1% of network admins. We all know from
experience how successful protocols that require two sets of records
to be kept in sync are. A protocol that requires a network admin to
remember to update their DNS with each cert change or suffer a
hardfail is going to have a very high administrative error rate.

Rather than mandating hardfail or any particular client behavior, the
specification should simply state that the client MUST conclude that
the DANE status of the certificate is invalid and then leave the
client to decide on what course of action to take. This will depend on
the circumstances of the particular user and the client provider's
assessment of the reliability of the DANE data and might range from do
nothing to send a security policy violation notification somewhere to
hardfail.

Contrary to the assumptions of the specification authors, hard fail is
not the best option. It is not even the best option in the case that
the users are dissidents.

To understand the logic of the dissident case it is important to have
a change of perspective. The objective of the authorities is not to
intimidate a single protester, it is to intimidate a whole country.
Being a protester carries inevitable risks. No security protocol is
going to eliminate those risks for the individual. What is important
is to minimize the risk for the population as a whole.

The Google cert pinning code did not provide much direct protection to
the Iranian dissidents because it only covered one site. But it proved
critical in exposing the Diginotar situation because it provided the
first evidence of the breach. Had the client been designed slightly
differently the breach might have become evident earlier.

The coffee shop issue is unintended but there are also parties that
are going to intentionally sabotage any infrastructure that looks like
DANE. We are not in the 1990s any longer, people in authority no
longer expect OSI to replace the Internet. The result is that it is
much harder to get away with no infrastructure. At present there is no
point in blocking DNSSEC records. But you can be sure that Iran,
Russia and China will be doing so the minute any client started to
make use of DANE. These countries can (and will) make use of a client
hard fail to ensure that people don't use browsers that might be used
for 'information terrorism' or freedom of speech as the rest of us
call it.

And don't think that out own governments necessarily mean what they
say. In public Thatcher was a stalwart champion of freedom. In private
she was begging Gorbachev to send in the tanks to stop the fall of the
Berlin wall. Her own foundation has materials that report this
exchange:

http://www.margaretthatcher.org/document/112006

The last thing I want to do is to hand the authorities another tool
that can be used to selectively shut down the network at the critical
moment in a crisis. Completely shutting off the Internet is one thing,
it probably worked in our favor in Egypt as the 101st keyboarders lost
their Internet connection and were forced to find out what was going
on in the streets. It was a visceral sign of panic on the part of the
regime.

DANE is really a form of security policy information and so far there
is no case where we have succeeded in applying raw security policy
information at the client end. DKIM policies are a success because
they are filtered and interpreted by the anti-spam services. There is
a huge infrastructure in place that is working to apply the data from
the DKIM records intelligently and equally importantly provides
feedback to publishers of inconsistent records.

DANE is proposed on the basis of a mistaken interpretation of how DKIM
security policies work in practice and the result is a protocol that
is deeply flawed and likely to fail.

It would be a pity if the lack of success of a group that has
steadfastly worked to ignore and discourage outside advice became a
precedent to avoid future security policy efforts. Security policy is
a very powerful tool, one that we can and must use if we are going to
make the insecure Internet secure. But the DANE approach is too
dogmatic to succeed.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 25 Apr 2012 11:15:18 -0400

> A/AAAA and CNAME records.

I'm having a hard time understanding that sentence.  Could you
clarify, please:

A.  Fewer than 97% of DNS resolvers can pass anything other than
A/AAAA and CNAME, which means something more than 3% of resolvers pass
only A/AAAA and CNAME.  

    This is what I _think_ you mean, which means that n% > broken
    resolvers > 3%, right?  If so, I'd like a citation, though it
    doesn't sound wrong to me.  That we'd have something on the order
    of 3% of the software deployed everywhere on the Internet be
    broken ought to be completely unsurprising.

B.  97% of the DNS resolvers is the most that has ever been observed
working according to specification, and the number may be much lower.

    This is the rhetorical point I think might be read in.  In this
    case, I think a citation is in order.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 25 Apr 2012 11:47:53 -0400 (EDT)

On Wed, 25 Apr 2012, Phillip Hallam-Baker wrote:

> and this is considered an unacceptable performance degradation.

And with the current ocsp.entrust.net issue, that would be a two day
performance degradation? There is also the privacy issue. But all of
this is off-topic.

> working when the user tries to surf the Web from a coffee shop.

hotspot detection for temporal DNS failure/spoofing mode is what
browsers need to support/implement. It is no different then the fix
they needed when we opened our browser at a coffee shop and all
tabs destroyed themselves reloading into hotspot login pages.

> there is a need to and that need won't exist until the coffee shop

I suggest you run with dnssec-trigger software for a while and then
come back to this assertion. We do not need coffeeshops to fix anything,
we need better DNSSEC integration on our laptops and phones.

> nothing to send a security policy violation notification somewhere to

In all IETF protocols, there is the "local policy overrides", yet we
don't add it specifically to every MUST in the protocol documents.
Additionally, the browser can fail the connection and terminate the TLS
and provide the user some feedback with a local policy override, and
then the brower complies to both the hard fail requirement, and your
'too big too fail' argument.

> the users are dissidents.

Tell that to the chrome users in Iraq that are still alive and not in
jail getting tortured. If anyone is going to sacrifice the one for the
many, I sure as hell hope it won't be protocol designers.

> But you can be sure that Iran,

Sure. Any data can be blocked. You work around the block with tunneling
and then use the actual DANE information for your own protection and
safety within the tunnel. Suggesting the block means you might as well
not add security in case there is no block, or you can break through it,
is wrong.

> But the DANE approach is too dogmatic to succeed.

All your arguments against dane are equally valid/invalid for OCSP with
hard fail, which you seem to be a proponent of. I fail to see the
consistency in your reasoning.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Apr 2012 14:33:06 -0400

>    broken ought to be completely unsurprising.

That was what two independent studies that were input to the CABForum
revocation Workshop found. One was by Comodo, the other I am not sure
what the citability status would be.

The Comodo study was obtained by hooking the OCSP validation call in a
very large number of browsers for over a week. I will see if it could
be submitted as a draft as such studies can be useful.

>    case, I think a citation is in order.

Unfortunately this is also the case since we were merely looking for
support for TXT records. So I would expect to see an even higher rate
of stripping for DNSSEC records.

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Apr 2012 14:53:19 -0400

> 'too big too fail' argument.

So you are saying that this MUST does not matter because MUSTs can
always be overridden?

My view is that the correct approach in this case is to use a SHOULD.
That is also what it says in 2119:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

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.

I think that 'causing harm' needs to be considered very narrowly here
as it seems pretty clear that the original context is talking about
harm to network operations.

If we think that local security policy is going to override then we
really have no choice but to use a SHOULD if we are taking 2119
literally.

> many, I sure as hell hope it won't be protocol designers.

That is unfair on many levels, not least because 1) the Chrome guys
were the people who found the issue and 2) this was not a case where
revocation could have helped since the CA had no idea which certs had
been issued.

As I explained in the following discussion, what was most important
was to detect and report the security policy anomaly even if it was
not going to be sufficiently reliable to hard fail on. Of course what
would be the best case would be an Internet that didn't have such a
high degree of inherent unreliability. But that is not an option at
present.

Proposing to mandate behavior in the expectation of being ignored is
irresponsible.

> not add security in case there is no block, or you can break through it,

No, it means that you cannot address this particular problem with a
reductionist approach. We have already deployed a technology that
provides a partial fix to this problem.

> consistency in your reasoning.

That is true. What I am arguing here is to not build a second
infrastructure that is going to fail in exactly the same way that OCSP
is failing.

If you subscribe to the right key you will have my omnibroker proposal
which proposes a way to use both DANE and OCSP without the current
failure modes. Otherwise I can send you the PDF.