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

From: [email-masked]
Date: Sat, 04 Feb 2012 00:19:08 -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-15.txt
	Pages           : 27
	Date            : 2012-02-04

   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-15.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-15.txt

---

From: Jakob Schlyter <[email-masked]>
Date: Sat, 4 Feb 2012 09:36:33 +0100

> 	Filename        : draft-ietf-dane-protocol-15.txt

The new version includes, in addition to minor editorial changes, the following updates:

- "Certificate for Association" is now "Certificate Association Data"
- Added usage type 3; "The target certificate MUST match the TLSA record"
- Text regarding on how to handle weak algorithms
- Text regarding protocol-specific specifications
- Expanded "TLSA and DANE Use Cases and Requirements"
- Updated "Operational Considerations for Deploying TLSA Records"
- New sections on "Securing the Last Hop" and "Handling Certificate Rollover"
- Updated psuedo-code

With these changes, we believe the draft is ready for WGLC.

	Jakob & Paul

---

From: Pieter Lexis <[email-masked]>
Date: Sat, 04 Feb 2012 12:19:36 +0100

Hi,

> With these changes, we believe the draft is ready for WGLC.

I had a quick read, looks good. I'll give a more thorough reading today.
But I did notice a mistake in the examples in section A.2.1.:

   sub6.example.com.            IN AAAA 2001:db8::1/32

One does not note the subnet of an IPv6 address in the AAAA record. As
per RFC 3596:

2.4 Textual format of AAAA records

   The textual representation of the data portion of the AAAA resource
   record used in a master database file is the textual representation
   of an IPv6 address as defined in [3].

Reference 3 leads to RFC 3513 this is obsoleted by RFC 4291, this RFC
does not (section 2.2) add prefixes to the text representation of an
IPv6 address.

Could you strip off the /32's from all the examples?

Regards,

Pieter Lexis

---

From: Jakob Schlyter <[email-masked]>
Date: Sat, 4 Feb 2012 13:22:16 +0100

>   sub6.example.com.            IN AAAA 2001:db8::1/32

'svn blame' tells me this was my bad, apparently a copy'n'paste problem - fixed in the next rev. Thanks!

	jakob

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 4 Feb 2012 07:06:56 -0800

> With these changes, we believe the draft is ready for WGLC.

Indeed. We think that all the closed issues have at least been addressed. It is up to the chairs to decide which issues get reopened in WG LC, but Jakob and I are happy to continue to make the changes that the WG wants.

Because there were a bunch of issues closed in this round, we would appreciate people taking a good look at what we changed. Jakob gave the descriptive list, I'll just do the mechanical and point to the diffs: <http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-protocol-15>.

--Paul Hoffman

---

From: Peter Palfrader <[email-masked]>
Date: Sat, 4 Feb 2012 22:03:48 +0100

> > 	Filename        : draft-ietf-dane-protocol-15.txt

| 2.1.2.  The Selector Field
| 
|    A one-octet value, called "selector", specifying what the association
|    data will be matched against from the TLS certificate presented by
|    the server.

I'm not sure that sentence is very readable or clear.  I'm also a bit
confused about what it selects from where.  It seems, from reading the
pseudo code, that it selects from the cert (chains) provided by the
server.  It doesn't select from the association data.

If so, how about this:

} A one-octet value, called "selector", specifying what data of a
} TLS certificate in the chain presented by the server will be matched
} against the certificate association data field.

Also:

| 2.1.4.  The Certificate Association Data Field
| 
|    The "certificate association data" to be matched.  The field contains
|    the bytes to be matched or the hash of the bytes to be matched.  The
|    field contains the bytes to be matched: the raw data, for matching
|    type 0, or the hash of the raw data, for matching types 1 and 2.  The
|    data refers to the certificate in the association, not to the TLS
|    ASN.1 Certificate object.

The second and third sentences here might be a bit confusing.  Maybe:

} The "certificate association data" to be matched.  This field contains
} the data to be matched. These bytes are either raw data (e.g full
} certificate or its SubjectPublicKeyInfo depending on selector) for
} matching type 0, or the hash of the raw data for matching types 1 and 2.
} The data refers to [..]

This also spells out that the matching data contains the raw
SubjectPublicKeyInfo for selector type 0.

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

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 4 Feb 2012 13:55:05 -0800

On Feb 4, 2012, at 1:03 PM, Peter Palfrader wrote:

> I'm not sure that sentence is very readable or clear.  

Jakob took responsibility for the last one, I'll take it for this one. It's not clear. New text:

A one-octet value, called "selector", specifying which part of the association data
and the TLS certificate presented by the server will be matched.

> SubjectPublicKeyInfo for selector type 0.

That is clearer, yes. Thanks!

--Paul Hoffman

---

From: Pieter Lexis <[email-masked]>
Date: Sat, 04 Feb 2012 23:07:47 +0100

Hi

> and the TLS certificate presented by the server will be matched.

I think the following is clearer:
====
A one-octet value, called "selector", specifying which part of the TLS
certificate presented by the server will be matched against the
association data.
====

This eliminates the word 'part' in relation to the association data. As
the full association data must be matched against a part of the certificate.

- --
Pieter

---

From: James Cloos <[email-masked]>
Date: Sat, 04 Feb 2012 17:06:00 -0500

>>>>> "PP" == Peter Palfrader <[email-masked]> writes:

Grammar nits:

PP> } specifying what data of a TLS certificate

If that is accepted, s/what data/which data/.

PP> The second and third sentences here might be a bit confusing.  Maybe:

PP> } (e.g full certificate or its SubjectPublicKeyInfo

And that should have an article:  s/full/the full/.

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

---

From: Bill Owens <[email-masked]>
Date: Sun, 5 Feb 2012 10:58:15 -0500

I see that there's an addition to the second paragraph in Section 9,
Security Considerations; the last sentence now reads:

    Thus, such proxies might choose to aggressively block TLSA
requests and/or responses, even though this is not a recommended
practice.

I'm still not sure that makes sense. Given the scenario that paragraph
describes: a combination of an SSL-interrupting proxy, a filter that
blocks TLSA requests or responses, and a DANE-aware, DNSSEC-validating
client; I think that one of two things could happen. The blocker
(whether it is the proxy server, or a firewall, or a local forwarder)
could decide to simply suppress any query or response with a TLSA
RRTYPE. Or it could recognize TLSA and return a fake NXDOMAIN.

In the latter case, the client would be unable to authenticate the
NXDOMAIN since there would be no NSEC/NSEC3 records, so the result
would be marked bogus and TLS would stop. In the former case, the
client would retry until its timer expired. I'm not entirely sure how
that case would be handled; it isn't explicit in the draft as far as I
can tell, but it certainly seems as though the effect should be to
stop TLS. If not, such a simple filter would enable a downgrade
attack.

If that's all correct, the last sentence probably should be removed
entirely from that paragraph; it should simply state that SSL proxies
will no longer work in the presence of TLSA-aware clients.

One additional observation might be that entities who rely on such
proxies, either with self-generated or public subordinate CAs, may
choose to suppress TLSA and/or DNSSEC capabilities for all devices
behind the proxy in order to maintain the current mode of operation.
That would be an unhappy side effect, but not an unreasonable choice
from the perspective of someone who is willing to implement an SSL
proxy in the first place.

Bill.

---

From: Scott Schmit <[email-masked]>
Date: Sun, 5 Feb 2012 23:49:25 -0500

On Sat, Feb 04, 2012 at 09:36:33AM +0100, Jakob Schlyter 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.
> 

In section 2.1.3:
]  Because a client support for multiple hash algorithms might be
]  limited, ...

Grammar: s/a client/client/ or s/a client/a client's/

> - Text regarding protocol-specific specifications

In section 3:
]  Unless there is an protocol-specific specification that is different
]  than this one, TLSA resource records are stored at a prefixed DNS
]  domain name.  The prefix is prepared in the following manner:

Grammar: s/an protocol/a protocol/

Unless I misread the stated consensus, this draft doesn't address the
result of Issue 28 at all. Warren stated this was the consensus: "use
the first name that has a TLSA record".

If I understand the called consensus correctly, the client should first
do a lookup at the name provided to the client and if the TLSA record
isn't there, check at the hostname on the right-hand side of the SRV
record it's trying to connect to.  Draft -15 doesn't say that at all.

Assuming I'm not totally off-base in my reading of the stated consensus,
here's some proposed text:

|  TLSA resource records are stored at a DNS domain name of the form:
|
|      _<port>._<protocol>.<name>
|
|  <port>:
|      The decimal representation of the port number on which a TLS-
|      based service is assumed to exist.  This number has no leading
|      zeros.
|
|  <protocol>:
|      The protocol name of the transport on which a TLS-based service
|      is assumed to exist.  The transport names defined for this
|      protocol are "tcp", "udp" and "sctp".
|
|  <name>:
|      The DNS domain name the TLSA resource record belongs to.
|
|  The name and port to use to look up the TLSA resource record depends
|  on whether the protocol in use by the client uses SRV to determine
|  the port and address of the service.
|
|  If SRV is not used, the client uses the domain name and port that the
|  client was provided (e.g., by the user and/or a well-known service
|  port) to generate the name for the TLSA lookup.
|
|  For example, to request a TLSA resource record for an HTTP server
|  running TLS on port 443 at "www.example.com", you would use
|  "_443._tcp.www.example.com" in the request.  To request a TLSA
|  resource record for an SMTP server running the STARTTLS protocol on
|  port 25 at "mail.example.com", you would use
|  "_25._tcp.mail.example.com".
|
|  If SRV is used, the client begins with the domain name that the
|  client was provided (e.g., by the user) and first performs a SRV
|  lookup to get an list of port/target pairs sorted as specified by
|  RFC 2782.  For each port/target the client is attempting to connect
|  to, the client first performs the TLSA lookup using the port and the
|  initial name. If that TLSA lookup returns no records, then the client
|  performs a lookup using the port and target name.
|
|  For example, to request a TLSA resource record for an XMPP server
|  with the following SRV records:
|
|    _xmpp-server._tcp.example.com. IN SRV 0 0 1234 xmpp.example.net.
|    _xmpp-server._tcp.example.com. IN SRV 1 0 5678 im.example.org.
|
|  you would first do a TLSA lookup at "_1234._tcp.example.com". If that
|  returns no records, you would then do a lookup at
|  "_1234._tcp.xmpp.example.net". If you are unable to reach
|  xmpp.example.net, you would then do a TLSA lookup at
|  "_5678._tcp.example.com" and so on.
|
|  Future protocol-specific specifications may specify a different
|  scheme for looking up TLSA records.

In section 4.3:
]  This usage allows a domain name administrator to specify a new trust
]  anchor, such as if the domain issues its own certificates under its

should be, given the use case names in RFC 6394:
|  This usage is sometimes referred to as "trust anchor assertion" and
|  allows a domain name administrator to specify ...

Section 5:
]                                     ...  Clients that rely on another
]  entity to perform the DNSSEC signature validation MUST use a secure
]  transport between themselves and the validator.  Examples of secure
]  transports include TSIG [RFC2845], SIG(0) [RFC2931], and IPsec
]  [RFC6071].  ...

Slight nit: "entity" is rather vague and could be interpreted as
"software component" (such as the OS).  Would "host" be a better term?

> - Expanded "TLSA and DANE Use Cases and Requirements"

]  The different types of certificates associations defined in TLSA are

Grammar: s/certificates assocations/certificate assocations/

]  matched with various sections of [DANEUSECASES].  Three use cases

I think you can cover all 4 usage types with a reference to the use
cases in RFC 6394, so s/Three/The/

]  3.3 Domain-Issued Certificates  -- Implemented using certificate
]     usage 3.

Based on the title of section 3.3, I'd rewrite that as:
|  3.3 Trust Anchor Assertion and Domain-Issued Certificates --
|     Implemented using certificate usages 2 and 3, respectively.

In section 8.1:
]  In the following sections, "RFC Required" was chosen TLSA usages, and
]  "Specification Required" for selectors and hashes, because of the
]  amount of detail that is likely to be needed for implementers to
]  correctly implement new usages as compared to new matching types and
]  hash types.

Grammar: s/chosen TLSA/chosen for TLSA/

Also, you don't need any of the commas after the first (and they made
the text harder to read because it made me think it was delineating a
parenthetical clause).

Also, the terms used in the paragraph don't seem consistent with the
rest of the draft/the registry names/itself. Should it read:
|  In the following sections, "RFC Required" was chosen for TLSA usages
|  and "Specification Required" for selectors and matching types because
|  of the amount of detail that is likely to be needed for implementers
|  to correctly implement new usages as compared to new selectors and
|  matching types.

I'm not sure if specification required is sufficient for selectors, not
because they're going to be tremendously complex, but because some could
be a really bad idea, at least in some cases. Imagine I wrote up a
specification for DN matching or certificate policy matching. With
usages 0 & 1, that would be fine, but with usages 2 & 3, that would be
very foolish. Perhaps local client policy considering that to be weak
would resolve that, but it's not written that broadly.

The matching type registry has a similar problem, IMHO. (What about a
URI matching type?)

As far as I can tell from RFC 5226, the main difference between RFC
required & specification required is whether the referenced document
must have IETF consensus. Spec required will be checked for
interoperability, but nothing more AFAICT.

I realize this may never be a problem in practice but why not strengthen
the language?

In section 9 (Security Considerations):

The first two paragraphs talk about looking up A/AAAA records. Do we
need to add SRV to that list? Or maybe we should just refer to DNS
records (as there is also the issue of CNAMEs, etc).

Also, the considerations include:
]  Client treatment of any information included in the trust anchor is a
]  matter of local policy.  This specification does not mandate that
]  such information be inspected or validated by the domain name
]  administrator.

Should this text be expanded to include usage 3?

Do we want to add a paragraph reminding DNS admins that record
expiration is controlled by RRSIG expiration and not TTL, so the
signature period should take into account how long the domain can afford
to wait for the TLSA record to expire in the event of a server key
compromise.

We should probably add a reminder that clients must exercise care that
TAs introduced by type 2 aren't usable for validation of other TLS
connections. It should probably be a MUST somewhere in the text, but I'm
not sure where it would best fit.

In section 11 (with the help of id nits):
* draft-ietf-dane-use-cases has been published as RFC 6394
* draft-ietf-tls-rfc4347-bis has been published as RFC 6347
* Downref: Normative reference to an Informational RFC (the use cases)

In section A.1:
]   When creating TLSA record with certificate usage type 0 (CA
Grammar: s/record/records/

]  and 1 (SubjectPublicKeyInfo).  A careful choice is required because
]  the different methods for building trust chains are used by different
Grammar: s/because the/because/

In section A.1.1:
]  o  The client may not have an associated root certificate in trust
]     store and instead uses a cross-certificate with an identical
Grammar: s/in trust/in its trust/

HTH

-- 
Scott Schmit

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Feb 2012 16:45:01 -0500

Great stuff!

> Grammar: s/a client/client/ or s/a client/a client's/

Got it.

> Grammar: s/an protocol/a protocol/

Got it.

> the first name that has a TLSA record".

That's only half of what he said. The full text is "use the first name that has a TLSA record, unless there is a protocol specific exception".

> record it's trying to connect to.  Draft -15 doesn't say that at all.

The draft doesn't say it because there needs to be a protocol-specific exception to know when to look. That's why we added the text we did. Given what we read from the chairs, there is only one defined "first name", namely the one that *every* protocol starts with. Anything beyond that needs to be specified, given that the lengthy discussion on the list showed that there is no agreement on how to define what the follow-up names are.

> |  scheme for looking up TLSA records.

I think this is *way* beyond what the chairs asked us to do. If I'm wrong, I'm sure we'll hear from the chairs soon enough.

> |  allows a domain name administrator to specify ...

Good call.

> "software component" (such as the OS).  Would "host" be a better term?

No, for the exact reason you gave: it might be an OS service. We should not restrict this to "you need to go to another host".

> Grammar: s/certificates assocations/certificate assocations/

Yep

> |     Implemented using certificate usages 2 and 3, respectively.

I like this!

> Grammar: s/chosen TLSA/chosen for TLSA/

Yes.

> the text harder to read because it made me think it was delineating a

I prefer the current way slightly, but if you were confused, that's good enough. (Let's see if the RFC Editor adds them back in...)

> |  to correctly implement new usages as compared to new selectors and

Yep

> would resolve that, but it's not written that broadly.

This is a good consideration for WG LC.

> The matching type registry has a similar problem, IMHO. (What about a

Not sure how that would work.

> interoperability, but nothing more AFAICT.

This is not correct: you can get an RFC without IETF consensus, and that is actually called out in 5226.

> I realize this may never be a problem in practice but why not strengthen

If the WG wants to change these rules, we can. It seems worth discussing in WG LC.

> need to add SRV to that list?

No.

> Or maybe we should just refer to DNS

No. :-)

This is a morass that is specific to some applications that use TLS. The current spec does *not* address them. (Your proposed change for issue #28 would probably lead us to make this change.)

> Should this text be expanded to include usage 3?

I believe not, but I would like to hear more. Usage 3 is "match", not "match after poking at the contents", so there is no local policy about included information. Did you think otherwise?

> to wait for the TLSA record to expire in the event of a server key

This was discussed earlier, and I thought the resolution was that it is, in fact, the TTL. The *ability to use a TLSA record* is based on the RRSIG expiration, but the signature period of a certificate is unrelated to that.

> not sure where it would best fit.

It's already there: "The TLS session that is to be set up MUST be for the specific port number and transport name that was given in the TLSA query." How would you suggest to make this stronger?

> * draft-ietf-tls-rfc4347-bis has been published as RFC 6347

Good

> * Downref: Normative reference to an Informational RFC (the use cases)

I'll move the use cases down; I'm not sure why we said they were normative for implementers.

> Grammar: s/in trust/in its trust/

Yes, yes, and yes.

> HTH

Most definitely yes!

--Paul Hoffman

---

From: Scott Schmit <[email-masked]>
Date: Mon, 6 Feb 2012 23:26:55 -0500

> Great stuff!
I'm glad -- it look longer than I expected to write it all up. :)

> Given what we read from the chairs, there is only one defined "first
> name", namely the one that *every* protocol starts with. Anything
> beyond that needs to be specified, given that the lengthy discussion
> on the list showed that there is no agreement on how to define what
> the follow-up names are.

When I first read what he wrote, I got the same impression you have, but
rereading it, I can't defend the interpretation. What you're saying
would make perfect sense if what Warren wrote was "use the first name,
unless there is a protocol specific exception". But he wrote "use the
first name that has a TLSA record" which reads to me as "there are
several names, so go through the list and take the first that has a
record". Thus I ended up with the text I wrote.

I welcome clarification from the chairs.  (After writing that up, I hope
you're right--doing TLSA with SRV the way I wrote sounds really slow,
especially in the "no TLSA record" case.)

Assuming that you're right and I'm reading too much into "that has a
TLSA record", I'd amend my suggested text to the following:

> > |      The DNS domain name that the client was provided (e.g., by
> > |      the user).
> > |  
> > |  Future protocol-specific specifications may provide a different
> > |  mechanism for looking up TLSA records.

I think this is clearer than the current text.

> No, for the exact reason you gave: it might be an OS service. We
> should not restrict this to "you need to go to another host".

I think you've misread that. Are you suggesting that I MUST use TSIG,
SIG(0), and/or IPsec to get validation from my OS?  I could understand
that requirement if I'm reaching out to another node... :)

> I believe not, but I would like to hear more. Usage 3 is "match", not
> "match after poking at the contents", so there is no local policy
> about included information. Did you think otherwise?

Well, I hate to open what might be another can of worms, but the text
doesn't actually say what to or not to validate from a usage 3 EE
certificate. Should the client ignore EVERYTHING from the cert except
for the SPKI when doing the key agreement (which essentially treats it
like a TA), or should it check the validity period, DN, etc and just
ignore the signature (treating the cert like it's really signed by the
zone DNSKEY)?

> This was discussed earlier, and I thought the resolution was that it
> is, in fact, the TTL. The *ability to use a TLSA record* is based on
> the RRSIG expiration, but the signature period of a certificate is
> unrelated to that.

Perhaps an example will make my point better: say I have a TLS cert that
expires a year from now, an RRSIG that expires in two months, and a TTL
that expires in one day. An operator not familiar with DNSSEC and
reading the draft might end up thinking "ok, if the TLS certificate gets
compromised, we just have to change the TLSA records and wait a day for
all the clients to forget the old RR, and after that, the old TLS
certificate is useless/harmless." However, if it's worth it to the
attacker, the attacker has potentially 2 months in which to do his/her
dirty work by resending the old record every time the TTL expires (and
the TTL isn't even signed, so that can be faked too). Admittedly, if
some of the records in the signing chain up to the root expire before
then and keys are rolled, the time available to the attacker will be
less.

That's in the DNSSEC RFCs, but it might not hurt to remind people.

(FWIW, I'm not saying that the "drop records at TTL" text is wrong, this
doesn't affect that.)

> It's already there: "The TLS session that is to be set up MUST be for
> the specific port number and transport name that was given in the TLSA
> query." How would you suggest to make this stronger?

Sorry, you're absolutely right -- it wasn't in the sections that were
changed, so I overlooked it.

-- 
Scott Schmit

---

From: Warren Kumari <[email-masked]>
Date: Tue, 7 Feb 2012 10:29:23 -0800

On Feb 6, 2012, at 8:26 PM, Scott Schmit wrote:

> record".

Your initial impression was correct, and that is what I intended to say / how I intended to call it (and what was discussed, and what the WG wanted). 
I had a few option written down, and cut and pasted the wrong one. I could *swear* I had "use the first name, unless there is a protocol specific exception" in my buffer, but apparently I didn't… 

I apologize for:
A: causing confusion / consternation and 
B: wasting the WG's time...

I have just reached my co-chair and confirmed that the way that we agreed to call it is the "use the first name, unless there is a protocol specific exception" way, and the crappy wording is completely my fault…

I'll update the issue tracker. 

Again, sorry for causing confusion / consternation, etc and then taking so long to clarify / rectify… 

W

> Thus I ended up with the text I wrote.
> 

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

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Feb 2012 16:40:03 -0500

Good to hear. Note that we *hope* that the SRV-using communities (notably XMPP and SIP) come up with their definitions soon. Personally, I hope they come up with the same one, but don't know enough about how each protocol does the lookup to be sure that they should get the same answer.

--Paul Hoffman

---

From: Bill Owens <[email-masked]>
Date: Wed, 8 Feb 2012 08:12:08 -0500

> requests and/or responses, even though this is not a recommended

I came across another perspective on this problem while reading up on
Chrome's implementation of
"HTTPS pins"  <http://www.imperialviolet.org/2011/05/04/pinning.html>

    What about MITM proxies, Fiddler etc?

    There are a number of cases where HTTPS connections are
intercepted by using
    local, ephemeral certificates. These certificates are signed by a
root certificate
    that has to be manually installed on the client. Corporate MITM
proxies may do this,
    several anti-virus/parental control products do this and debugging
tools like Fiddler
    can also do this. Since we cannot break in these situations, user
installed root CAs
    are given the authority to override pins. We don't believe that
there will be any
    incompatibility issues.

Personally I think that's a very bad compromise, but I wonder whether
the pressures that led to this decision would cause them to reach the
same conclusion with respect to DANE?

Bill.