Subject: Re: [dane] Classic PKI and DANE in harmony

From: Guido Witmond <[email-masked]>
Date: Sat, 01 Jun 2013 11:06:26 +0200

On 31-05-13 19:08, Guido Witmond wrote:

>
> To Jacob. As you work at a CA, I have this wish:

Got that working-at part wrong. My apologies to Jacob.

Respectfully, Guido.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 1 Jun 2013 14:37:09 +0000

On Sat, Jun 01, 2013 at 08:47:42AM +0200, Jakob Schlyter wrote:

> > I would love to see the CA-industry promote TLSA records for every
> > server certificate they sign. When I apply/renew a certificate the CA
> > gives me the correct RR-line, ready to include in my DNS(SEC)-records.
> 
> That sounds like an excellent idea.

This is I think unlikely to happen.  It is easy to compute a SHA256
digest of a certificate or public key from the associated certificate.
As we've seen the main obstacle to DANE adoption is DNSSEC deployment,
not so much difficulties with DANE itself.

Once DNSSEC is more widely implemented, publishing of TLSA RRs will
not be held back for lack of knowledge of what to publish or tools
to compute the digests.  One simple example:

    #! /bin/sh
    usage() {
	echo "usage: $0 base-domain certificate-file" >&2
	exit 1
    }
    getopts :h opt && usage
    [ $# -eq 2] || usage
    base=$1
    cert=$2
    openssl x509 -in "$cert" -noout -pubkey |
	openssl pkey -pubin -outform DER |
	openssl dgst -sha256 |
	awk -v base="$base" '{printf "%s IN TLSA 3 1 1 %s\n", base, $2}'

Tools for doing this should be included with server software.

Some people will likely be trusting enough to have some stranger's
web page compute the TLSA RR for them.  (This covers the CA case,
as end-users of certificates often receive these via email, in
which the sender is weakly authenticated if at all).

-- 
	Viktor.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 3 Jun 2013 10:16:14 +0100

On 31 May 2013 16:34, Jakob Schlyter <[email-masked]> wrote:
> On 30 maj 2013, at 16:55, Ben Laurie <[email-masked]> wrote:
>
>> a) It introduces latency, and
>
> so does checking revocation lists and OCSP.

Which is why they're default off.

>> b) It isn't reliable, so cannot be hard-fail.
>
> I'm a bit disappointed that browsers vendors are not willing to implement new protocols, like DANE, just because there exists clients out there that cannot reliable use them. I'm not saying we should enable these features by default, but to be able to test them and learn more we need them in something that is not an experimental build.

I don't have any particular view on whether browsers should or should
not implement protocols that don't work reliably, but my goal is to
accept reality and implement something that _is_ reliable (i.e.
Certificate Transparency).

>
> I would even stretch my neck out and claim that the additional controls provided by using DANE with certificate use 0/1 (i.e. backed by classic PKIX) would make sense even without DNSSEC. I know this is a very dangerous path and may dragons lure along it, but I still believe this is something we should explore further.
>
>         jakob
>

---

From: Ben Laurie <[email-masked]>
Date: Mon, 3 Jun 2013 10:21:30 +0100

On 31 May 2013 16:43, Phillip Hallam-Baker <[email-masked]> wrote:
> On Thu, May 30, 2013 at 12:18 PM, Ben Laurie <[email-masked]> wrote:
>>
>> The issue is not that the clients can't use DNSSEC, the issue is that
>> they cannot retrieve DNSSEC records.
>
>
> +1
>
> That is why the place to put the DNSSEC validator is in the DNS server and
> why we need to change the client to DNS server protocol so that the client
> can get the authenticated decision of the validator.
>
> Hence omnibroker.
>
> Omnibroker brokers will probably consume DANE records just like every other
> piece of data that might affect the trustworthiness of an Internet
> destination. But once there is a broker in the loop there is no need to
> worry about latency as the broker can pre-fetch cert status information. In
> fact we could go back to using CRLs for revocation.
>
> [Omnibroker also good for consuming CT data Ben]

Omnibroker introduces a trusted third party. It may be better than the
status quo, but I think we've got adequate proof that we can't
actually trust TTPs.

---

From: Carl Wallace <[email-masked]>
Date: Mon, 03 Jun 2013 07:23:50 -0400

On 6/3/13 5:16 AM, "Ben Laurie" <[email-masked]> wrote:

>> I'm a bit disappointed that browsers vendors are not willing to
>>implement new protocols, like DANE, just because there exists clients
>>out there that cannot reliable use them. I'm not saying we should enable
>>these features by default, but to be able to test them and learn more we
>>need them in something that is not an experimental build.
>

It may be reliable but it does not address the problem the less reliable
protocols address so you will still need to implement something else.  The
CT spec acknowledges this.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 3 Jun 2013 15:15:12 +0000

> Which is why they're default off.

As does also e.g. SPNEGO, which browser users can and often do
enable for specified domains since this supports SSO via Kerberos.
So there is a number of precendends for default-off security
mechanisms.  I think that DANE deserves a chance, and ideally what
we should be discussing is "when" not "whether".

There is a bit of a chicken/egg issue with DNSSEC, it takes some
effort to deploy, and this effort needs to have benefits to encourage
more deployment.  DANE could be one of the motivating factors driving
DNSSEC adoption, but without browser support the impetus is reduced.

> Certificate Transparency).

In what context is the normative languate below (
https://tools.ietf.org/html/draft-laurie-pki-sunlight-12#section-3
) intended to apply?

   TLS servers MUST present an SCT from one or more logs to the
   TLS client together with the certificate.  TLS clients MUST
   reject certificates that do not have a valid SCT for the end-entity
   certificate.

Must private-label internal-only corporate CAs implement this
standard? Does this apply only to certificates that chain to
designated roots? Are legacy clients that don't implement the new
standard no longer allowed to connect to servers?  The above
requirement seems rather bold without some constraints on its scope.

-- 
	Viktor.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 3 Jun 2013 16:25:21 +0100

On 3 June 2013 16:15, Viktor Dukhovni <[email-masked]> wrote:
> standard?

No.

> Does this apply only to certificates that chain to
> designated roots?

Yes.

> Are legacy clients that don't implement the new
> standard no longer allowed to connect to servers?

Clearly a client that does not implement the standard is not
constrained by any MUSTs in the standard. As is true for all
standards.

> The above

We should, perhaps, have said something about private CAs. Possibly
this was omitted because all interested parties already understood the
exemption and so failed to notice we hadn't put it in the I-D.

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 3 Jun 2013 16:38:00 +0000

> exemption and so failed to notice we hadn't put it in the I-D.

I think this is important to add.  Otherwise there seems to be an
inadvertent conflict with DANE TLSA usage 2 and 3.  Clients that
implement both standards should be able to verify at least privately
issued usage 3 EE certs, and privately issued usage 2 trust-anchors.

I think it should be clarified that CT hardens PKIX validation in
the context of the existing public CA PKI for trust chained to
designated PKIX roots (and eventually clients are expected to only
support CT conformant public roots, plus any private roots that
CT-exempted by the client).

When a client that supports both PKIX + CT and another PKI (say
DANE TLSA) is not using PKIX (e.g. DANE usage 2/3), it should be
clear that CT does not apply, and the client is still CT conformant
when it does not apply CT rules outside their intended scope.

Is that a fair statement of the implicit consensus?  It may be helpful
to make it explicit, so as to avoid confusion.

-- 
	Viktor.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 3 Jun 2013 17:57:49 +0100

> CT-exempted by the client).

I think the introduction makes that reasonably clear. In any case, no
further changes can be made to that document, which has just completed
AUTH48.

The intent is to follow up with a new document once we have gained
some experience with CT.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 06 Jun 2013 15:33:41 -0700

Viktor Dukhovni <[email-masked]> writes:

> It would be nice to have a DNSSEC-aware local cache on my Android
> phone.

FYI, our DNSSEC library works on android...
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 06 Jun 2013 15:53:57 -0700

> FYI, our DNSSEC library works on android...

Whoops; that was supposed to be for Viktor and not a general
(discouraged) advertisement, but I had failed to notice that the evil
"Reply-To: list" setting had been enabled.
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

---

From: Bry8 Star <[email-masked]>
Date: Thu, 06 Jun 2013 21:14:20 -0700

Firefox, Chrome, etc clients need to completely support DANE usage 2
(private CA, Trust Anchor) and DANE usage 3 (End Entity, server,
domain-issued) certs, obtained via local DNSSEC validation supported
DNS-Resolver, or via native DNSSEC libraries.  Since these clients
already supports Classic PKI, ... DANE usage case 0 and 1 support
not needed immediately.

I'm sure devs there, have seen RFC 6698, and related, then why are
they not implementing it yet ? something still incomplete ? What
is/are stopping them ?

These clients should show an icon to indicate when HTTPS based site
is authenticated via classic PKIX certs, and when authenticated via
TLSA/DANE certs.  These should have/show simple indicator icon with
"S" or "T" to indicate SSL/TLS authenticated / encrypted, or, an
indicator icon with "D" to indicate DANE DNSSEC authenticated /
encrypted, or, an indicator icon with "T+D" or "S+D" , or, "T/D" or
"S/D" to indicate both path Classic PKIX and DANE authenticated.

-- Bright.

---

From: Bry8 Star <[email-masked]>
Date: Thu, 06 Jun 2013 22:25:54 -0700

Since most domain-owners/holders send their CSR (cert signing
request) to their choice of public CA over unencrypted emails, if
these emails are intercepted by such entity/group who is/are capable
of doing so, ... then can those entities/groups use such CSR file to
obtain an alternative cert from another 3rd party or compromised
public CA cert ? and then, can they do/run various types of MITM,
exploitations, spoofing, forwarding, surveillance, data-collection,
DPI (deep packet inspection) type of devices (or servers), etc ?

Common/Public CA entities should either get CSR over TLS encrypted
pages from domain-owner, or, over GPG/PGP encrypted emails.

And should domain-owner(s) move all CSR, csr.pem, prv.key,
prv.key.pem, etc files to an external removable portable (and
preferably hot-pluggable) storage device which has encrypted
partition ? when dealing with, either their own Private self-signed
Root CA, IA (Intermediate Authority), i-CA etc type of cert, or,
when dealing with public CA signed cert, unless it is a end-entity
server cert related prv.key file, as server/service software needs
end-entity server cert's prv.key.

I understand, it is possible to obtain same domain-name based SSL
cert from a 3rd party CA, and use in middle and run a fake same
domain-name server.

And if TLSA (aka, DANE) dns record declares/publishes what exact SSL
cert is trusted by the domain-owner/holder, then web-browser clients
which can/will check it, can make sure what is the correct SSL cert.
So that is a very large +point numbers for DANE's advantage, to use
very correct SSL cert for securing the communication.

But, what type of other problems exist with current PKI
implementations ? and, How DANE and which other DNSSEC aspects can
solve it slightly better ?

-- Bright Star.

Received from Jakob Schlyter, on 2013-05-30 12:37 AM:
> On 30 maj 2013, at 04:24, Rick Andrews <[email-masked]> wrote:
> 
>> Is there another list that's right for discussing the merits and demerits of the different DANE options? I work for a CA, so of course I believe that the current PKI is *not* irreparably broken, nor do I agree that modes 2 and 3 are "substantially more robust". Because I believe your voice is respected in this forum, I wanted to speak up to make it clear that this opinion is not shared by all.
> 
> Unless the chairs do not object, I believe this mailing list is a good place to discuss this matters.
> 
> IMHO, classic PKI augmented by DANE would be a very strong package. However, I would argue that without the extra identity proofing and other controls set by by Extended Validation (EV), DANE has equally security properties to a plain Domain Validation (DV) certificate.
> 
> For a foreseeable future, we definitely need to combine DANE with classic PKI in order for the general Internet user to be able to validate certificates. For limited deployments, or applications where classic PKI has not yet gained significant traction (such as TLS for SMTP), a pure DANE solution makes sense (unless EV is required).
> 
> 	jakob
>

---

From: Yoav Nir <[email-masked]>
Date: Fri, 7 Jun 2013 05:48:52 +0000

On Jun 7, 2013, at 8:25 AM, Bry8 Star <[email-masked]> wrote:

> public CA cert ?

CAs make some effort to only send the signed certificate to the actual domain owner, but I suppose if the attacker is able to intercept the domain owner's mail, they could probably use the CSR to obtain a valid certificate for the domain.

> and then, can they do/run various types of MITM,

No. Since they're using the original CSR, their MitM attack will fail. If they generate their own CSR, the keys won't fit the TLSA record (or HPKP pin)

> pages from domain-owner, or, over GPG/PGP encrypted emails.

Many already allow you to upload the CSR through the web site, which is sometimes protected by TLS. But CSRs, much like certificates, are not considered secret information.

> end-entity server cert's prv.key.

It depends. The operational security of running HTTPS servers is a complex issue, and the solution that fits a personal blog is not the same that would fit a small online store, and not the same that would fit Google, Facebook, or a bank. I don't see what Google would gain from placing the private key on an external, removable, portable, and hot-pluggable device - their servers are always on.

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 7 Jun 2013 08:50:15 +0200

> already supports Classic PKI, ... DANE usage case 0 and 1 support

I would argue for the the opposite. Augmented PKI with DANE 0/1 would make a lot more sense riskwise and fit better into the current trust model. 1/2 could/should be made experimental in order to gain more experience; once that has been established we can move forward and enable it by default.

> they not implementing it yet ? something still incomplete ? What

From what I've heard, some are worried about the different failure modes. I believe we need to do more work on analyzing these and looking at the consequences of these in a world where DNSSEC lookups sometimes does not work and/or result in bad answers.

> "S/D" to indicate both path Classic PKIX and DANE authenticated.

User UI overload will not increase security - it will just confuse the end user. Some of the users out there has actually managed to tell DV and EV apart, more UI bloat will fail, IMHO. 

	jakob

---

From: Bry8 Star <[email-masked]>
Date: Fri, 07 Jun 2013 08:02:18 -0700

Hi Yoav, thanks for corrections.
But i think i failed to convey what i wanted to say for the first
half part.

> No. Since they're using the original CSR, their MitM attack will fail. If they generate their own CSR, the keys won't fit the TLSA record (or HPKP pin)

Since most domain-owner uses HOSTing/CLOUD based REMOTE-SERVERs, i
consider any type of private_keys, secret_keys, etc there are
already intercepted / copied / compromised.  Since many are known to
assist in Surveillance and Data-collection.  And most domains are
not yet DNSSEC signed, and most domain-owner's do not sign with
DNSSEC, yet. *sad*  I should have mentioned this in my posted
paragraph.  I wanted to talk about things, what most domain-owner's
normally do and believe.

> Many already allow you to upload the CSR through the web site, which is sometimes protected by TLS. But CSRs, much like certificates, are not considered secret information.

Thanks for clarifying.

> It depends. The operational security of running HTTPS servers is a complex issue, and the solution that fits a personal blog is not the same that would fit a small online store, and not the same th…

I do not think i said, Google should place private_keys on removable
storage device.

I mentioned, any private self-signed Root-CA, intermediate CA,
intermediate authority, etc cert's private_keys, csr, etc files
should be moved into removable storage device, and mentioned NOT to
move last level / end-entity, that is, server-cert's private_keys,
as service software needs that private_keys.

Google suppose to keep server-cert's private_key on their server.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 7 Jun 2013 15:59:22 +0000

> paragraph.  I wanted to talk about things, what most domain-owner's

This thread seems to have veered in a naive direction unrelated to
IETF stardards.  Perhaps the chairs can bring us back on track.

--
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 7 Jun 2013 12:30:06 -0400

> status quo, but I think we've got adequate proof that we can't

Like the 9 companies allegedly involved in PRISM?

I agree that we can't absolutely trust any party. We can't put absolute
trust in Google, or ICANN or Comodo. But the current design of the Web
requires us to trust all of them and rather more.

The situation is not the same with Google however as I can at least decide
whether or not to trust Google. I can in fact build an entirely Google-free
tool chain if I want. I can eliminate the need to trust Google but not the
need to trust at least one browser provider and one search engine[1].

The real point is not that I get to choose whether to trust Google but not
whether to trust Comodo or ICANN. And that is the difference between a CA
an Omnibroker as TTPs. They are both TTPs but one is an agent of and chosen
by the server operator and the other is chosen by the client operator.

Ah but now you are going to say that I can compile Chrome from source.
Which just leaves me with the task of checking a billion lines of source
for a backdoor. Omnibroker is designed to provide the same option.

If you install your own Omnibroker service you can do all the checking
yourself for every client that supports the protocol. You can do DANE
checks and CT and Convergence and anything else that you might invent in
the future. You can do all those checks all by yourself or you can ask a
Symantec or a Comodo or a Kaspersky for information on possible bad IP
addresses, botnets etc.

I am working to develop an open source Omnibroker that can be used as the
basis for just such a system called Tin-Foil-Hat. Some of the code is
already on Sourceforge.

SCVP and XKMS make a distinction between Certificate Path Discovery and
Certificate Path Validation. You can use either server as simply a service
that will find the information you need to make a trust decision or you can
outsource your trust decision. Omibroker allows the same thing but it is
not limited to PKI.

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

---

From: Ben Laurie <[email-masked]>
Date: Mon, 10 Jun 2013 15:50:21 +0100

On 7 June 2013 17:30, Phillip Hallam-Baker <[email-masked]> wrote:
> whether to trust Comodo or ICANN. And that is the difference between a CA an
> Omnibroker as TTPs. They are both TTPs but one is an agent of and chosen by
> the server operator and the other is chosen by the client operator.

My point is that CT introduces _untrusted_ third parties, and I think
that's the way forward. Replacing the UTP with a TTP you trust to
verify the UTP seems like a step backwards, regardless of my freedom
to choose who I misplace my trust in.

> Ah but now you are going to say that I can compile Chrome from source. Which
> just leaves me with the task of checking a billion lines of source for a
> backdoor. Omnibroker is designed to provide the same option.
>
> yourself for every client that supports the protocol. You can do DANE checks
> and CT and Convergence and anything else that you might invent in the
> future. You can do all those checks all by yourself or you can ask a

Hmm. I think you need to incorporate some way for an evil Omnibroker
to be both detectable and possible to bring to justice (i.e. something
like CT consistency proofs).

Our outline for Revocation Transparency might be a way to do that.

> basis for just such a system called Tin-Foil-Hat. Some of the code is

There's already a Linux distro called that, I believe.

> outsource your trust decision. Omibroker allows the same thing but it is not
> limited to PKI.
>
> --

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 12 Jun 2013 08:31:07 -0400

> to choose who I misplace my trust in.

What CT does is to provide a mechanism that (1) allows any party to audit
certain aspects of the operations of a TTP from public data and (2) allows
the audit to be performed as part of the certificate validation checking.

If your view of the Web is limited to the Web Browser on a capable machine
then there is an argument to be made for moving all checking etc into the
browser. But I have network enabled light bulbs in the house. I do not want
to be configuring trust in every lightbulb.

Regardless, Omnibroker supports two models the same as SCVP does:

1) Validation: Client delegates trust to the broker completely, broker
makes decision

2) Discovery: Client delegates a veto to the broker which can refuse a
connection to a site known to be dangerous and revalidates all the trust
data returned by the broker before relying on it.

One advantage of Discovery only model is that the broker can collect all
the data required to make the choice for the browser ahead of the decision
and cache it. So in the case of DANE data, browser checking adds latency so
a browser is unlikely to do checking for DANE records unless at least 10%
of sites have them. But a broker can do most of its checks offline so they
don't add latency.

In the case of DANE there is a second point to the discovery mode and that
is to provide a bypass round local DNS resolvers that block TLSA / DNSSEC
records.

A second advantage is that it enables discretion. Any security check that
you implement in the browser has to be reduced to a set of codified,
completely standard rules. The spam filtering companies don't take that
approach, they have a more tactical scheme making use of heuristic data and
actively change their strategy in response to changes in opposition tactics.

> Which
> checks

The broker can be required to hand over all the data used to make its
decision.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 12 Jun 2013 14:08:43 +0100

On 12 June 2013 13:31, Phillip Hallam-Baker <[email-masked]> wrote:
> 1) Validation: Client delegates trust to the broker completely, broker makes
> decision
>
> One advantage of Discovery only model is that the broker can collect all the
> data required to make the choice for the browser ahead of the decision and
> cache it. So in the case of DANE data, browser checking adds latency so a
> browser is unlikely to do checking for DANE records unless at least 10% of
> sites have them. But a broker can do most of its checks offline so they
> don't add latency.
>

Fair points. I note, though, that you still end up configuring every
light bulb...

> The broker can be required to hand over all the data used to make its

Not much use if the client can't check it? The advantage of a CT (or
RT)-like scheme is that anyone can check it, and all the client needs
to be able to do is check consistency...

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 13 Jun 2013 15:38:31 -0400

> Fair points. I note, though, that you still end up configuring every

I do that once and the protocol allows the configuration to be done with a
smart phone with a QR code reader capability:

http://tools.ietf.org/html/draft-hallambaker-wsconnect-02

I don't think it is practical to expect a light bulb to have a full IP
stack let alone DANE. but it is possible for them to consume DANE and PKIX
trust assertions if there is a secure way to delegate those choices to
another device.

More likely the light bulb is plugging into some low bandwidth, short range
wireless network. So what you would want is not connecting to Omnibroker
but some sort of general 'home automation' center that will tell the
lightbulb how and where to plug into the local site infrastructure.

After realizing that I chopped the Omnibroker protocol into two parts. The
difficult design decisions are all in the JSON Connect (JCX) Web Service
which makes it easy to establish that initial authenticated connection to a
trusted Web Service (which can be of any type at all). Omnibroker is then
simply one protocol that makes use of JCX to establish the long term trust
connection.

> to be able to do is check consistency...

Come on, you point out yourself that you only need a handful of browsers to
perform CT checking in order for CT to be largely effective at detecting a
major CA breach.

People who don't trust their broker can run a browser that revalidates the
chains locally. But as we all know, even a browser with local DNSSEC
validation is going to sometimes need help making sure it gets DNSSEC data
to work from. So running the omnibroker just as a path discovery agent is
still valuable.

But for the general consumer, they actually trust us to decide what
programs run on their machines at all. CertSentry, the Comodo
Ombinbroker-like application is currently bundled on the anti-virus
product. The expectation is that that Omnibroker will eventually replace
the proprietary protocol in CertSentry 1.0 to power the next generation.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 14 Jun 2013 14:12:04 +0100

On 13 June 2013 20:38, Phillip Hallam-Baker <[email-masked]> wrote:
> I don't think it is practical to expect a light bulb to have a full IP stack
> let alone DANE. but it is possible for them to consume DANE and PKIX trust
> assertions if there is a secure way to delegate those choices to another
> device.
>
> wireless network. So what you would want is not connecting to Omnibroker but
> some sort of general 'home automation' center that will tell the lightbulb
> how and where to plug into the local site infrastructure.
>

That is only true because anyone can check that CT is behaving itself.
So far, it seems Omnibroker can safely lie to selected clients with no
risk of detection.

> But for the general consumer, they actually trust us to decide what programs
> run on their machines at all. CertSentry, the Comodo Ombinbroker-like
> application is currently bundled on the anti-virus product. The expectation
> is that that Omnibroker will eventually replace the proprietary protocol in
> CertSentry 1.0 to power the next generation.
>
>
> --

---

From: Ben Laurie <[email-masked]>
Date: Mon, 24 Jun 2013 09:11:49 +0100

On 30 May 2013 18:02, Viktor Dukhovni <[email-masked]> wrote:
> On Thu, May 30, 2013 at 05:51:28PM +0100, Ben Laurie wrote:
>
>> > So is your concern that at this time DNSSEC lookup are too likely to
>> > return "bogus" (rather than with anything specific in DANE itself)?
>>
>> Indeed.
>
> Understood. There are perhaps work-arounds, and this should improve
> over time.
>
>
>> > Well, there's always 8.8.8.8:
>>
>> How does that help if you can't retrieve DNSSEC records?
>
> The Google 8.8.8.8 DNS cache does return DNSSEC records, as shown
> below:  So clients that can reach 8.8.8.8 or similar, can bypass
> their ISP's cache when the ISP cache is DNSSEC hostile.

I didn't respond to this at the time, because I wanted numbers rather
than handwaving. Now I have some numbers. :-)

Our experience is that ~4% of clients cannot retrieve arbitrary DNSSEC
records from their configured resolver. Independently, we have
surveyed the ability of clients to contact Google on port 53 (i.e. I
don't know how these numbers relate to the 4% but clearly the
prognosis is not good): ~13% of the time, UDP doesn't work, and ~60%
of the time TCP doesn't work.

I think this effectively rules out any reliance on DNS, leaving aside
all other considerations.

It remains my considered opinion that we can deploy CT a lot faster
than we can fix this.

---

From: Olaf Kolkman <[email-masked]>
Date: Mon, 24 Jun 2013 10:46:30 +0200

> all other considerations.

Ben,

We could have a long philosophical debate on that last statement, e.g. on whether innovation on the core of the Internet is still possible but that is likely to be out of scope for this list. ;-)

The reason for this reply is about the numbers you report.

I am not doubting those, on first sight they seem plausible. However, I would like to see a more detailed description of measurement methodology and an explanation of the effects causing this. Will there be a paper forthcoming? I am specifically interested possible workarounds around the blockage, that would be valuable input to some of the last-mile work Labs is interested in.

--Olaf

________________________________
"When you're NAT on the net, you're NOT on the net"  -- Hugh Daniel 
_______________________ 
Olaf Kolkman -- NLnet Labs
http://www.nlnetlabs.nl/

---

From: Ben Laurie <[email-masked]>
Date: Mon, 24 Jun 2013 10:24:07 +0100

On 24 June 2013 09:46, Olaf Kolkman <[email-masked]> wrote:
> We could have a long philosophical debate on that last statement, e.g. on
> whether innovation on the core of the Internet is still possible but that is
> likely to be out of scope for this list. ;-)

Well, I did mean "right now", and innovation is mostly not about
"right now". So we may well violently agree :-)

> I am not doubting those, on first sight they seem plausible. However, I
> would like to see a more detailed description of measurement methodology and
> an explanation of the effects causing this. Will there be a paper
> forthcoming? I am specifically interested possible workarounds around the
> blockage, that would be valuable input to some of the last-mile work Labs is
> interested in.

These are measurements done for other reasons that happen to inform
this particular problem - I am not aware of any paper planned.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 24 Jun 2013 13:52:49 +0000

On Mon, Jun 24, 2013 at 09:11:49AM +0100, Ben Laurie wrote:

> records from their configured resolver.

Isn't this rather good news?  Even now, with little DNSSEC use in
last mile environments, already 96% of clients can retrieve DNSSEC
records!  It is unlikely to get worse, especially if browsers start
making DNSSEC features available to early adopters who can report
problems to their ISPs for remediation.

> all other considerations.

Absolute "reliance", for each and every end-user all the time sure.
Even if DNSSEC faced no network operator impedance, there are today
too few domains that are DNSSEC signed for DANE in browsers to secure
"the web".

Similarly, even with the CT specification published, it will be
some time before the majority of web servers are CT capable.

> It remains my considered opinion that we can deploy CT a lot faster

CT and DANE address different problems, the choice between CT and
DANE is IMHO a false dichotomy.  I see little reason to choose
between them.  Why not implement both?

-- 
	Viktor.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 24 Jun 2013 15:29:54 +0100

> some time before the majority of web servers are CT capable.

CT does not require web server modifications.

> between them.  Why not implement both?

Sure.