Comparisons between CT and DANE

[Matt Palmer]

Hi,

I'm trying to understand the reasoning behind the comparison of CT and DANE
presented at http://www.certificate-transparency.org/comparison, and I'm
hoping someone can enlighten me as to what the thinking was.

The three areas in which DANE is marked as being inferior to CT are "No
side-channels", "No Trusted Third Parties", and "Unmodified Servers". My
thoughts on each aspect follow.

"No side-channels". The only "side-channel" I can think of DANE using is
DNS. I don't think DNS falls in the same category as the likes of an
OCSP responder for the purposes of this analysis. If DNS is flaky,
users are going to have *much* larger problems than not being able to
get TLSA records. If *every* possible side-channel is in the
microscope, it's worth examining the possibility of OCSP responder
failure causing issues for stapling, or inability to submit a
certificate to a new log.

"No Trusted Third Parties". I can think of two trusted third parties
involved in DANE: the DNS provider and the trust root (ICANN). Fair
enough. However, CT relies on at least as many (and no more reliable)
trusted third parties too -- CAs, log operators, and auditors. As a
server operator, I've got a much larger say in making sure my DNS
provider does the right thing by me than log operators and other CAs.

"Unmodified Servers". DANE doesn't require a modified HTTPS server, whereas
only one of three ways of distributing SCTs allows the server operator
to run an unmodified HTTPS server. DANE does require a DNS server which
knows about the TLSA record type, which (I presume) is the "server"
referred to as needing modification. That's somewhat disingenuous,
though; HTTPS server operators don't need to deal with that
modification, their DNS provider needs to worry about it. If
modifications to other parties' server software is "in scope", what
about the need for CAs to modify their services to acquire SCTs before
certificate issuance? It seems a bit sly to count one as in scope while
discounting the other.

For the record, I'm massively in favour of CT, and intend on deploying code
and infrastructure to support it's adoption. However, I *also* support
DANE, and I think they're complimentary approaches to the problem of
improving TLS. I think it's important to properly communicate the relative
benefits of different approaches, lest misunderstanding create ill-will.

- Matt

[Adam Langley]

On Tue, Jul 8, 2014 at 2:07 AM, Matt Palmer <mpa...@hezmatt.org> wrote:
> The three areas in which DANE is marked as being inferior to CT are "No
> side-channels", "No Trusted Third Parties", and "Unmodified Servers". My
> thoughts on each aspect follow.

DANE and CT aren't independent, although many seem to think that CT is
alternative rather than a complement to CT.

> "No side-channels". The only "side-channel" I can think of DANE using is
> DNS. I don't think DNS falls in the same category as the likes of an
> OCSP responder for the purposes of this analysis. If DNS is flaky,
> users are going to have *much* larger problems than not being able to
> get TLSA records.

The problem is that DANE, to most people, involves the client fetching
the DNSKEY, DS, RRSIG etc records from the DNS as needed. But many
(~4% in past tests) of users can't resolve a TXT record when they can
resolve an A record for the same name. In practice, consumer DNS is
hijacked by many devices that do a poor job of implementing DNS. This
is major headache for widespread implementation.

> "No Trusted Third Parties". I can think of two trusted third parties
> involved in DANE: the DNS provider and the trust root (ICANN). Fair
> enough. However, CT relies on at least as many (and no more reliable)
> trusted third parties too -- CAs, log operators, and auditors. As a
> server operator, I've got a much larger say in making sure my DNS
> provider does the right thing by me than log operators and other CAs.

The thought here is that CT can be audited and thus the logs are not
trusted the same extent that, say, the TLD operator is in DANE.

> "Unmodified Servers". DANE doesn't require a modified HTTPS server, whereas
> only one of three ways of distributing SCTs allows the server operator
> to run an unmodified HTTPS server. DANE does require a DNS server which
> knows about the TLSA record type, which (I presume) is the "server"
> referred to as needing modification. That's somewhat disingenuous,
> though; HTTPS server operators don't need to deal with that
> modification, their DNS provider needs to worry about it. If
> modifications to other parties' server software is "in scope", what
> about the need for CAs to modify their services to acquire SCTs before
> certificate issuance? It seems a bit sly to count one as in scope while
> discounting the other.

I think the point here is that site operators generally have to do
"work": contacting their registra to get a DS record setup, making
sure that their DNS servers do DNSSEC, adding TLSA records etc. While
CT can be done with no changes to current operator practices.

DANE and CT shouldn't be considered to be alternatives and, ideally,
that line shouldn't exist. But lots of people do seem to think that
they are.


Cheers

AGL

[Matt Palmer]

Hi Adam,

Thanks for responding.

On Tue, Jul 08, 2014 at 02:21:47PM -0700, Adam Langley wrote:
> On Tue, Jul 8, 2014 at 2:07 AM, Matt Palmer <mpa...@hezmatt.org> wrote:
> > The three areas in which DANE is marked as being inferior to CT are "No
> > side-channels", "No Trusted Third Parties", and "Unmodified Servers". My
> > thoughts on each aspect follow.
>
> DANE and CT aren't independent, although many seem to think that CT is
> alternative rather than a complement to CT.

The table on the "comparison" page reads, to me at least, like it's
reinforcing that "one or the other" feeling. Maybe I've just been poisoned
by too many vendor brochures, but I interpret a table like that as trying to
persuade me "CT is better, therefore you should switch to using CT!".

> > "No side-channels". The only "side-channel" I can think of DANE using is
> > DNS. I don't think DNS falls in the same category as the likes of an
> > OCSP responder for the purposes of this analysis. If DNS is flaky,
> > users are going to have *much* larger problems than not being able to
> > get TLSA records.
>
> The problem is that DANE, to most people, involves the client fetching
> the DNSKEY, DS, RRSIG etc records from the DNS as needed. But many
> (~4% in past tests) of users can't resolve a TXT record when they can
> resolve an A record for the same name. In practice, consumer DNS is
> hijacked by many devices that do a poor job of implementing DNS. This
> is major headache for widespread implementation.

Holy bejesus... 4% fail to retrieve a *TXT* record? I've been living in a
very sheltered corner of the world. I don't suppose this sort of thing
could be expected to get better with the widespread deployment of DNSSEC, so
that crappy middleboxes learn there's no value to be had in interfering?
No, that's far too optimistic.

> > "No Trusted Third Parties". I can think of two trusted third parties
> > involved in DANE: the DNS provider and the trust root (ICANN). Fair
> > enough. However, CT relies on at least as many (and no more reliable)
> > trusted third parties too -- CAs, log operators, and auditors. As a
> > server operator, I've got a much larger say in making sure my DNS
> > provider does the right thing by me than log operators and other CAs.
>
> The thought here is that CT can be audited and thus the logs are not
> trusted the same extent that, say, the TLD operator is in DANE.

Hmm... fair point. I hope WebTrust audits aren't in the near future to DNS
operators, though I suppose it could end up that way.

/me considers registering axfr-transparency.org to get ahead of the game

> > "Unmodified Servers". DANE doesn't require a modified HTTPS server, whereas
> > only one of three ways of distributing SCTs allows the server operator
> > to run an unmodified HTTPS server. DANE does require a DNS server which
> > knows about the TLSA record type, which (I presume) is the "server"
> > referred to as needing modification. That's somewhat disingenuous,
> > though; HTTPS server operators don't need to deal with that
> > modification, their DNS provider needs to worry about it. If
> > modifications to other parties' server software is "in scope", what
> > about the need for CAs to modify their services to acquire SCTs before
> > certificate issuance? It seems a bit sly to count one as in scope while
> > discounting the other.
>
> I think the point here is that site operators generally have to do
> "work": contacting their registra to get a DS record setup, making
> sure that their DNS servers do DNSSEC, adding TLSA records etc. While
> CT can be done with no changes to current operator practices.

I think the statement "CT can be done with no changes to current operator
practices" is overstating the case somewhat. It seems like there should be
a qualifier along the lines of "in theory" in there somewhere. Because in
practice, I don't see it being nearly as rosy a picture.

The CT CA survey of Feb 2014[1] suggests that between 20% and 33% of CAs[2]
will provide CT-compatible certificates that allow sites to maintain EV in
Chrome without server-side changes. Between 24% and 43% of CAs[3] will
provide OCSP responses which include SCTs, which requires site operators to
deploy OCSP stapling, which is, itself, not widely available in deployed
HTTPS servers (Apache in Debian stable and RHEL6 is too old, as is nginx in
Debian stable and EPEL6 -- and I'd be surprised if any of them had
backported a large feature like OCSP stapling support into an older
version).

It seems to me that in practical terms, the vast majority of site operators
are going to have to do "work" of some sort to remain EV in Chrome past Feb
next year. At the very least, they'll have to change certificate suppliers,
but I'd consider it more likely they will modify their HTTPS server
infrastructure to retrieve SCTs and serve them in a TLS extension.

> DANE and CT shouldn't be considered to be alternatives and, ideally,
> that line shouldn't exist. But lots of people do seem to think that
> they are.

Indeed many people do seem to think that they're alternatives -- including,
apparently, Google. Scott Rea of Digicert, Inc, presented at RSA-AP 2013,
(slides at
https://www.rsaconference.com/writable/presentations/file_upload/sec-t02_final.pdf)
stating "DANE lacks the support of Google" (p18). He doesn't source that
information, and if it were true at the time I'd be very glad to hear that
Google's stance had changed in the interim.

Also in that same presentation, Scott states "the consensus of the community
seems to be favoring CT, CAA, Pinning, and to a much lesser extent DANE."
(p18). Again, no sources, but if true, it would suggest that DANE and CT
*are*, in fact, considered alternatives rather than complimentary approaches
to providing additional assurance to identity verification of TLS.

Thanks,
- Matt

[1] https://sites.google.com/site/certificatetransparency/feb-2014-survey-responses

[2] Out of 21 respondents, 4 said "yes" and 3 said "maybe" to "Do you intend
to implement Precertificates for Certificate Transparency?"

[3] Out of 21 respondents, 6 said "yes" and 3 said "maybe" to "Do you intend
to embed SCTs in OCSP responses?"

[Eran Messeri]

That should not be the case - there'll be a whitelist of certificates that have not been re-issued yet (but appear in a log).

See http://www.certificate-transparency.org/ev-ct-plan.

> DANE and CT shouldn't be considered to be alternatives and, ideally,
> that line shouldn't exist. But lots of people do seem to think that
> they are.

Indeed many people do seem to think that they're alternatives -- including,
apparently, Google.  Scott Rea of Digicert, Inc, presented at RSA-AP 2013,
(slides at
https://www.rsaconference.com/writable/presentations/file_upload/sec-t02_final.pdf)
stating "DANE lacks the support of Google" (p18).  He doesn't source that
information, and if it were true at the time I'd be very glad to hear that
Google's stance had changed in the interim.

Also in that same presentation, Scott states "the consensus of the community
seems to be favoring CT, CAA, Pinning, and to a much lesser extent DANE."
(p18).  Again, no sources, but if true, it would suggest that DANE and CT
*are*, in fact, considered alternatives rather than complimentary approaches
to providing additional assurance to identity verification of TLS.

Thanks,
- Matt

[1] https://sites.google.com/site/certificatetransparency/feb-2014-survey-responses

[2] Out of 21 respondents, 4 said "yes" and 3 said "maybe" to "Do you intend
to implement Precertificates for Certificate Transparency?"

[3] Out of 21 respondents, 6 said "yes" and 3 said "maybe" to "Do you intend
to embed SCTs in OCSP responses?"

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Adam Langley]

On Tue, Jul 8, 2014 at 5:05 PM, Matt Palmer <mpa...@hezmatt.org> wrote:
> The table on the "comparison" page reads, to me at least, like it's
> reinforcing that "one or the other" feeling. Maybe I've just been poisoned
> by too many vendor brochures, but I interpret a table like that as trying to
> persuade me "CT is better, therefore you should switch to using CT!".

I agree and I was about to say that I didn't have edit rights on the
page, but it turns out that I do! So I've added a note to that effect.

> Holy bejesus... 4% fail to retrieve a *TXT* record? I've been living in a
> very sheltered corner of the world. I don't suppose this sort of thing
> could be expected to get better with the widespread deployment of DNSSEC, so
> that crappy middleboxes learn there's no value to be had in interfering?

There's also a strong latency argument against trying to chase DNSSEC
records (esp since clients would have to do several rounds in many
cases in order to get the full chain). But I think the dismal state of
port 53 is sufficiently bad that it's not really viable to depend on
anyway.

> I think the statement "CT can be done with no changes to current operator
> practices" is overstating the case somewhat. It seems like there should be
> a qualifier along the lines of "in theory" in there somewhere. Because in
> practice, I don't see it being nearly as rosy a picture.

Sure, we have a fight ahead of us. We've told the CAs that assuming
that servers will do OCSP stapling isn't going to fly.

> It seems to me that in practical terms, the vast majority of site operators
> are going to have to do "work" of some sort to remain EV in Chrome past Feb
> next year. At the very least, they'll have to change certificate suppliers,
> but I'd consider it more likely they will modify their HTTPS server
> infrastructure to retrieve SCTs and serve them in a TLS extension.

We are very much aiming note to have to make server operators do
anything extra. Having to switch CAs is a possibility.

> Indeed many people do seem to think that they're alternatives -- including,
> apparently, Google. Scott Rea of Digicert, Inc, presented at RSA-AP 2013,
> (slides at
> https://www.rsaconference.com/writable/presentations/file_upload/sec-t02_final.pdf)
> stating "DANE lacks the support of Google" (p18). He doesn't source that
> information, and if it were true at the time I'd be very glad to hear that
> Google's stance had changed in the interim.

We certainly have issues with DANE:

* Fetching the records doesn't seem viable or sufficiently fast. It is
possible for servers to serve the DNSSEC chain like a certificate
chain however: http://tools.ietf.org/html/draft-agl-dane-serializechain-01

* We have been working for a long time to get rid of 1K RSA in the
PKI. We're not there yet, but we're close. However, DNSSEC is full of
1K RSA and regressing would be very sad.

* CT is very important for the future, we're not going to let DANE bypass it.

If those three were solved, then it's just a complexity/benefit
consideration and the question of whether servers would actually use
it.


Cheers

AGL

[Matt Palmer]

Hi Eran,

On Thu, Jul 10, 2014 at 09:59:25AM +0100, 'Eran Messeri' via certificate-transparency wrote:
> On Wed, Jul 9, 2014 at 1:05 AM, Matt Palmer <mpa...@hezmatt.org> wrote:
> > The CT CA survey of Feb 2014[1] suggests that between 20% and 33% of CAs[2]
> > will provide CT-compatible certificates that allow sites to maintain EV in
> > Chrome without server-side changes. Between 24% and 43% of CAs[3] will
> > provide OCSP responses which include SCTs, which requires site operators to
> > deploy OCSP stapling, which is, itself, not widely available in deployed
> > HTTPS servers (Apache in Debian stable and RHEL6 is too old, as is nginx in
> > Debian stable and EPEL6 -- and I'd be surprised if any of them had
> > backported a large feature like OCSP stapling support into an older
> > version).
> >
> > It seems to me that in practical terms, the vast majority of site operators
> > are going to have to do "work" of some sort to remain EV in Chrome past Feb
> > next year. At the very least, they'll have to change certificate
> > suppliers,
> > but I'd consider it more likely they will modify their HTTPS server
> > infrastructure to retrieve SCTs and serve them in a TLS extension.
>
> That should not be the case - there'll be a whitelist of certificates that
> have not been re-issued yet (but appear in a log).
> See http://www.certificate-transparency.org/ev-ct-plan.

I wasn't referring to existing EV certs, although re-reading what I wrote I
can see I wasn't particularly clear.

What I *meant* to say was that if you want to get an EV cert after February
next year that behaves like an EV cert in Chrome, you're going to have to
do one of three things:

* Use one of the 20%-33% of CAs who will be providing SCTs in the certificates
they issue (that meets the "no need for server modifications" criteria
which is a selling point of CT);

* Use one of the 24%-43% of CAs who will be providing SCTs in their OCSP
responses, which you can then staple -- but only if you're running HTTPS
software from the latest stable release of your OS; OR

* Deploy a *very* up-to-date version of your HTTPS server software which can
retrieve SCTs from logs and present them via a TLS extension.

The point I was trying to make is that claiming that CT can be deployed
without changes to server software, when it appears that server operators
using any of the 2/3 or more of CAs who do not appear to be in any rush to
provide the newer certificates that would enable that, seems a little
disingenuous, when simultaneously claiming that other alternatives (I used
DANE as my example, since I'm familiar with that) *do* require server
modifications, when what they actually need is support from service
providers (DNSSEC and TLSA support in DNS providers) -- which is exactly the
same situation as CT is in.

I hope I've provided clarification (as opposed to further confusion <grin>).

- Matt

--
<Igloo> I remember going to my first tutorial in room 404. I was most upset
when I found it.

[Matt Palmer]

Hi Adam,

On Thu, Jul 10, 2014 at 10:16:31AM -0700, Adam Langley wrote:
> On Tue, Jul 8, 2014 at 5:05 PM, Matt Palmer <mpa...@hezmatt.org> wrote:
> > The table on the "comparison" page reads, to me at least, like it's
> > reinforcing that "one or the other" feeling. Maybe I've just been poisoned
> > by too many vendor brochures, but I interpret a table like that as trying to
> > persuade me "CT is better, therefore you should switch to using CT!".
>
> I agree and I was about to say that I didn't have edit rights on the
> page, but it turns out that I do! So I've added a note to that effect.

That seems like a reasonable clarification. Thanks for taking the time to
update that page.

> > Holy bejesus... 4% fail to retrieve a *TXT* record? I've been living in a
> > very sheltered corner of the world. I don't suppose this sort of thing
> > could be expected to get better with the widespread deployment of DNSSEC, so
> > that crappy middleboxes learn there's no value to be had in interfering?
>
> There's also a strong latency argument against trying to chase DNSSEC
> records (esp since clients would have to do several rounds in many
> cases in order to get the full chain).

That seems to me like an argument against DNSSEC itself -- or at least
against very poorly deployed DNSSEC, which isn't very different to the wider
problem of poorly deployed DNS in general. By the time it comes time to
retrieve a TLSA record and use it to establish identity, a client (or
whatever that client is using to do trusted DNSSEC validation, anyway) will
have already done a DNSSEC-enabled lookup down the same chain of trust to
get the A/AAAA record. If someone's then setup a CNAME on _443._tcp.<name>
to somewhere completely different... well, you can't legislate against
stupid.

On the latency issue, though -- wouldn't it be practical to do the TLSA
lookup in parallel with the A/AAAA lookup? By the time you come to do the
A/AAAA lookup, you know enough to know whether (https://) and exactly what
(_443._tcp.<host>) you'd need to lookup if there were a TLSA record to use.
As an added bonus, you can establish the TCP connection and get part way
through the TLS handshake before that TLSA record response *needs* to be
back to you.

The only additional latency you end up with is that, if you don't get a
timely response (even if it's SERVFAIL or NXDOMAIN) you need to wait for a
timeout on that TLSA request before you can proceed with validating the
certificate presented by the client.

> But I think the dismal state of port 53 is sufficiently bad that it's not
> really viable to depend on anyway.

The act of using a web browser establishes the dependency on DNS. DANE
simply utilises that existing dependency. I understand that the situation
isn't *entirely* that cut-and-dried -- middleboxes which interfere with
"weird" DNS record types are going to cause problems, and I suppose that the
statistic you cited about failing to look up TXT records is probably enough
*by itself* to make the idea infeasible. Making TLSA lookups work, though,
would seem to be the right way forward, rather than dumping DANE. Further
discussion of that, though, is probably best left to a DANE advocacy list,
not a CT list. <grin>

> > It seems to me that in practical terms, the vast majority of site operators
> > are going to have to do "work" of some sort to remain EV in Chrome past Feb
> > next year. At the very least, they'll have to change certificate suppliers,
> > but I'd consider it more likely they will modify their HTTPS server
> > infrastructure to retrieve SCTs and serve them in a TLS extension.
>
> We are very much aiming note to have to make server operators do
> anything extra. Having to switch CAs is a possibility.

I was wondering if "economic incentives" for CAs to deploy SCTs in their
certs was a potential part of the plan. One of the benefits of having
control of a major browser, I guess, is that you get to do those sorts of
things. <grin>

> We certainly have issues with DANE:
>
> * Fetching the records doesn't seem viable or sufficiently fast. It is
> possible for servers to serve the DNSSEC chain like a certificate
> chain however: http://tools.ietf.org/html/draft-agl-dane-serializechain-01

I did recently ponder if "DANE stapling" was practical -- and it s! Looks
like that draft didn't go anywhere (expired Jan 2012), though it would no
doubt serve as a good foundation for anyone who wanted to get to a state
where a TLS extension could be standardised.

> * We have been working for a long time to get rid of 1K RSA in the
> PKI. We're not there yet, but we're close. However, DNSSEC is full of
> 1K RSA and regressing would be very sad.

*facepalm* I suppose that's something for DNSSEC people to jump on top of
-- trawling around for 1k RSA keys and hassling DNS admins until it gets
fixed. Unfortunately, absent a directive from the root that all signed
zones must kick all 1k RSA keys out of their zone and not let any new ones
be added (and that this policy must apply recursively) I don't expect this
problem will be solved -- after all, that's pretty much what it's taken to
get them out of the PKI.

> * CT is very important for the future, we're not going to let DANE bypass it.

Hmm... the best interpretation of this I'm coming up with is "we've only got
so many resources, and we're focusing on CT rather than DANE at the moment",
but that doesn't seem like an "issue [Google has] with DANE". Would you
mind clarifying?

> If those three were solved, then it's just a complexity/benefit
> consideration and the question of whether servers would actually use
> it.

I really, *really* think they would. I see DANE as a potential "killer app"
for DNSSEC, as much as that sounds like hyperbole. Anyone using self-signed
certs and "aaah, I'll just click through", anyone running an internal CA
merely (or primarily) because they don't want to have to manually trust the
certs on every machine, and people who buy DV certs for all their internal
and "limited scope of use" services, would all be early adopters -- and we
all know that it's early adopters that make or break a technology.

I can say for a fact that if Chrome (or any other browser) released a
version which fully supported DANE out of the box this minute, I'd have
DNSSEC and TLSA records deployed to about two dozen places by the end of the
day. The fact that Chrome 33(?) on Linux nuked the TLSA verifier extension
(because NSAPI got removed) pushed me *very* close to switching back to
Firefox, and that's not something I consider lightly. Hell, if IE were the
first to provide full built-in DANE support, I'd seriously consider
re-installing WINE. (I know, I know, "don't say things you can't take
back...")

Once I worked out how to provide a local DNSSEC-enabled resolver to OS X and
Windows (I'm sure it's not hard, I've just never done it before), I'd have
DNSSEC and TLSA to a couple of dozen *more* places, and an e-mail out to a
number of people saying "from this day forth, when using the following
sites, you *must* use $DANE_SUPPORTING_BROWSER".

And I'm out of the large-scale infrastructure game at the moment. Six
months ago I would have been in a position to roll out DNSSEC/TLSA and
mandate a browser to a much larger audience.

- Matt

[Adam Langley]

On Thu, Jul 10, 2014 at 6:04 PM, Matt Palmer <mpa...@hezmatt.org> wrote:
> *facepalm* I suppose that's something for DNSSEC people to jump on top of
> -- trawling around for 1k RSA keys and hassling DNS admins until it gets
> fixed. Unfortunately, absent a directive from the root that all signed
> zones must kick all 1k RSA keys out of their zone and not let any new ones
> be added (and that this policy must apply recursively) I don't expect this
> problem will be solved -- after all, that's pretty much what it's taken to
> get them out of the PKI.

We don't need to remove all 1K keys, we can just say that we're not
going to accept certificate unless the chain is >= 2K. However, since
the root and many TLDs use a 1K key to sign the DS records, that
currently excludes everyone.

> Hmm... the best interpretation of this I'm coming up with is "we've only got
> so many resources, and we're focusing on CT rather than DANE at the moment",
> but that doesn't seem like an "issue [Google has] with DANE". Would you
> mind clarifying?

It's that there isn't a clear design for transparency with DANE. Maybe
we rate limit certificates by eTLD+1 or maybe we only demand
transparency to the eTLD+1 level. We don't really know and we don't
have the resources to focus on it at the moment. It's something that
would need to be sorted out.

> I really, *really* think they would. I see DANE as a potential "killer app"
> for DNSSEC, as much as that sounds like hyperbole. Anyone using self-signed
> certs and "aaah, I'll just click through", anyone running an internal CA
> merely (or primarily) because they don't want to have to manually trust the
> certs on every machine, and people who buy DV certs for all their internal
> and "limited scope of use" services, would all be early adopters -- and we
> all know that it's early adopters that make or break a technology.

We supported DNSSEC-stapled certs (with CAA records because it was
pre-DANE at the moment) and ~nobody used it.

Maybe it was premature, but it's the only data we have. (It got
removed because of lack of use and also because of the 1K issues. I
can't remember whether CT came before or after that.)


Cheers

AGL

[Matt Palmer]

On Mon, Jul 14, 2014 at 11:27:37AM -0700, Adam Langley wrote:
> On Thu, Jul 10, 2014 at 6:04 PM, Matt Palmer <mpa...@hezmatt.org> wrote:
> > *facepalm* I suppose that's something for DNSSEC people to jump on top of
> > -- trawling around for 1k RSA keys and hassling DNS admins until it gets
> > fixed. Unfortunately, absent a directive from the root that all signed
> > zones must kick all 1k RSA keys out of their zone and not let any new ones
> > be added (and that this policy must apply recursively) I don't expect this
> > problem will be solved -- after all, that's pretty much what it's taken to
> > get them out of the PKI.
>
> We don't need to remove all 1K keys, we can just say that we're not
> going to accept certificate unless the chain is >= 2K. However, since
> the root and many TLDs use a 1K key to sign the DS records, that
> currently excludes everyone.

Well, that'll teach me to make assumptions. The *root* is signed with a 1k
RSA key? I'm... flabbergasted.

> > Hmm... the best interpretation of this I'm coming up with is "we've only got
> > so many resources, and we're focusing on CT rather than DANE at the moment",
> > but that doesn't seem like an "issue [Google has] with DANE". Would you
> > mind clarifying?
>
> It's that there isn't a clear design for transparency with DANE. Maybe
> we rate limit certificates by eTLD+1 or maybe we only demand
> transparency to the eTLD+1 level. We don't really know and we don't
> have the resources to focus on it at the moment. It's something that
> would need to be sorted out.

I'm afraid I don't understand what "transparency with DANE" means. DANE, to
me, is primarily about domain owners making trustable assertions directly
about their identity, through the DNS, without the need to involve any third
parties (other than the DNS providers in the chain from the root to the
record of interest).

What excites me about CT is the fact that in order for third parties (in
general) to be trustworthy, they need to be transparent. Since CAs are in a
position of enormous trust (and will continue to be so, even in a
majority-DANE world, since the assertions that EV certs provide can't be
covered by DANE), transparency is required in order for them to be properly
trustworthy.

Is it perhaps that you'd like to be able to audit DNS operators (especially
those higher up in the tree) to make sure they're not sending out signed
records to some parties that aren't published globally? Interestingly, I
can see how that could be doable (using essentially the same merkle
tree/included signature model as CT), but the DNS is a somewhat different
beast than the global PKI, because one particular entity has to be
compromised to do the dodgy with DNS, not the-least-trustable-entity-of-100-
or-so, as is the case with CAs.

> > I really, *really* think they would. I see DANE as a potential "killer app"
> > for DNSSEC, as much as that sounds like hyperbole. Anyone using self-signed
> > certs and "aaah, I'll just click through", anyone running an internal CA
> > merely (or primarily) because they don't want to have to manually trust the
> > certs on every machine, and people who buy DV certs for all their internal
> > and "limited scope of use" services, would all be early adopters -- and we
> > all know that it's early adopters that make or break a technology.
>
> We supported DNSSEC-stapled certs (with CAA records because it was
> pre-DANE at the moment) and ~nobody used it.
>
> Maybe it was premature, but it's the only data we have. (It got
> removed because of lack of use and also because of the 1K issues. I
> can't remember whether CT came before or after that.)

I can make a fairly educated guess as to why DNSSEC-stapled CAA certs never
went anywhere -- well, a few guesses. One is that it probably wasn't
very loudly/widely advertised. I think of myself as a fairly
run-of-the-mill sysadmin, and I never heard about it. I don't pay
particularly close attention to browser development, but I do take a fairly
keen interest in service security issues.

The second guess I'd make is that CAA is a *very* different beast to DANE --
CAA records are primarily of value to the small percentage of domain owners
who desire assurance that no other CA is going to be tricked into issuing a
cert for their domain. The 99.99% of domains which are never going to be
worth that sort of effort, unsurprisingly, wouldn't make the effort. DANE,
on the other hand, is of value *both* to people who want to be assured that
no other CA is going to be tricked, but *also* (and, to my mind,
*primarily*) of value to people who wish to be able to have secure
communications to a wider audience than that which they can reach with a
self-signed cert or local CA, without needing a DV cert from a CA.

Guess the third: server support. How widely available were the necessary
server-side changes to staple those responses? I don't know of a setting in
the nginx I'm running today that would allow me to add a DNSSEC response
into the TLS stream.

My final guess is that the general perception of the security landscape may
have been *very* different when you rolled out DNSSEC-stapled CAA. It was
only 13 months ago that the NSA's dirty laundry started being aired, and
that has *massively* changed the way that people think about security. I
still don't think that CAA would see massive adoption, but I think there
would be a very different takeup of DNSSEC-stapled DANE today than there
would have been if Edward Snowden hadn't put his USB stick under his arm and
walked out.

At any rate, I'll stop trying to change your mind on a reasonable
prioritisation decision you've made -- I'm all in favour of getting CT
rolled out and broadly adopted.

- Matt

--
I really didn't foresee the Internet. But then, neither did the computer
industry. Not that that tells us very much of course -- the computer
industry didn't even foresee that the century was going to end.
-- Douglas Adams

[James Cloos]

>>>>> "MP" == Matt Palmer <mpa...@hezmatt.org> writes:

MP> Well, that'll teach me to make assumptions. The *root* is signed
MP> with a 1k RSA key? I'm... flabbergasted.

Remember that there are two keys. A Key Signing Key and a Zone Signing Key.

The KSK is the one referenced by the DS record, and thus difficult to change.

The ZSK is signed by the KSK.

The recomendation has been 2k for KSK and 1k for ZSK, with ZSK rollover
a common operation.

So they are smaller because they are expected to stick around for a
short time. And depending on the software they can be extremely easy to
roll over. My last ZSK rollover required less than a minute of effort,
a few seconds to generate the new ZSK, a few more to publish it and
then, after letting it propagate, another few seconds to make it active.

The KSKs, otoh, are expected to last at least as long as 509 private
keys tend to last.

Whether and, if so, how often everyone does those rollovers is an
interesting question.

-JimC
--
James Cloos <cl...@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6

[Matt Palmer]

On Mon, Jul 14, 2014 at 08:56:20PM -0400, James Cloos wrote:
> >>>>> "MP" == Matt Palmer <mpa...@hezmatt.org> writes:
>
> MP> Well, that'll teach me to make assumptions. The *root* is signed
> MP> with a 1k RSA key? I'm... flabbergasted.
>
> Remember that there are two keys. A Key Signing Key and a Zone Signing Key.
>
> The KSK is the one referenced by the DS record, and thus difficult to change.
>
> The ZSK is signed by the KSK.
>
> The recomendation has been 2k for KSK and 1k for ZSK, with ZSK rollover
> a common operation.

RFC6781 walks a rather delicate line on the subject, I think -- it doesn't
take a stand, but rather makes observations. Given that its argument that
1k keys are acceptable is based on analogy with PKIX, and 1k keys are being
phased out, suggests that a similar result should occur for DNSSEC.

> The KSKs, otoh, are expected to last at least as long as 509 private
> keys tend to last.

My X509 keys last a year. Or less, if I'm running particular versions of
OpenSSL at the wrong moment. <grin>

> Whether and, if so, how often everyone does those rollovers is an
> interesting question.

I think we both can guess fairly accurately at the answer to that question.

- Matt

--
Non-PHB basically told $MANAGER to go check his drive integrity.
-- steve, ASR

[Eran Messeri]

The numbers are higher - I believe more than 33% of CAs  will be able to embed SCTs in the certificates they issue by February 2015. Several have publicly committed to that, Ben can list out exactly who.

* Use one of the 24%-43% of CAs who will be providing SCTs in their OCSP
  responses, which you can then staple -- but only if you're running HTTPS
  software from the latest stable release of your OS; OR

* Deploy a *very* up-to-date version of your HTTPS server software which can
  retrieve SCTs from logs and present them via a TLS extension.

The point I was trying to make is that claiming that CT can be deployed
without changes to server software, when it appears that server operators
using any of the 2/3 or more of CAs who do not appear to be in any rush to
provide the newer certificates that would enable that, seems a little
disingenuous, when simultaneously claiming that other alternatives (I used
DANE as my example, since I'm familiar with that) *do* require server
modifications, when what they actually need is support from service
providers (DNSSEC and TLSA support in DNS providers) -- which is exactly the
same situation as CT is in.

I hope I've provided clarification (as opposed to further confusion <grin>).

That's a good point -  it should be phrased to say that "one of the ways for deploying CT does not require changes to server software. Another way relies on the use of modern server software that supports OCSP stapling."

IMHO the crucial point is that each deployment method requires exactly one major change and will provide the same benefit as others.

- Matt

--
<Igloo> I remember going to my first tutorial in room 404. I was most upset
when I found it.

[Ben Laurie]

Apologies that I managed to miss this conversation, seems my mail
client was incorrectly configured. A few points that I think may have
been missed:

1. Trusted third parties in DNSSEC (and therefore DANE): as well as
ICANN and the TLD operators, you also have all the registrars to worry
about. They are in essentially the same position as CAs are in PKI.
Plus, although we see it a lot less in the media, domain hijackings
are far more common than CA breaches.

2. CAs signed up to CT: you need to measure by volume of certificates
issued, not by number of CAs. By that count, according to my (now
somewhat out-of-date) calculations, over 95% of CAs are signed up to
include SCTs in certs. For EV the figure is even higher.

3. DNSSEC transparency: because of 1 it seems to us there's a pretty
clear need for a CT-like mechanism for DNSSEC. My rough architecture
is that every time you delegate a subdomain, you can also delegate a
log - so, subdomains that don't make many names can just use their
parent's log, subdomains with high volume can be forced by their
parent to find their own logs. In any case someone (not me) will be
talking about DNSSEC Transparency at the trans WG meeting next week in
Toronto.


On 15 July 2014 11:45, 'Eran Messeri' via certificate-transparency

[Matt Palmer]

On Sat, Jul 19, 2014 at 12:34:00PM +0100, 'Ben Laurie' via certificate-transparency wrote:
> Apologies that I managed to miss this conversation, seems my mail
> client was incorrectly configured. A few points that I think may have
> been missed:
>
> 1. Trusted third parties in DNSSEC (and therefore DANE): as well as
> ICANN and the TLD operators, you also have all the registrars to worry
> about. They are in essentially the same position as CAs are in PKI.
> Plus, although we see it a lot less in the media, domain hijackings
> are far more common than CA breaches.

That is a good point. I hadn't considered the role of registrars as both
trusted third parties and a long-running source of spectacular security
fail.

> 3. DNSSEC transparency: because of 1 it seems to us there's a pretty
> clear need for a CT-like mechanism for DNSSEC. My rough architecture
> is that every time you delegate a subdomain, you can also delegate a
> log - so, subdomains that don't make many names can just use their
> parent's log, subdomains with high volume can be forced by their
> parent to find their own logs. In any case someone (not me) will be
> talking about DNSSEC Transparency at the trans WG meeting next week in
> Toronto.

I look forward to seeing what comes out of that. I've tracked the
discussion on the trans list, and it looks like there are enough people
interested that it has the potential to come to a productive conclusion.

Thanks,
- Matt