Subject: [dane] How to use TLSA "2 s m", "3 s m"

From: Bry8 Star <[email-masked]>
Date: Wed, 29 May 2013 02:16:37 -0700

How to use TLSA "2 s m" , "3 s m" ?

Please correct me anytime, my understanding is:

zone/domain-owners/holders can use simple tools like openssl/gnutls,
to create their own various types of self-signed private (aka:
non-public) CA cert or server certs, and then combine such with
DNSSEC + DANE based implementation in DNS records, when basic/simple
level of HTTPS/TLS secured web solution/service is expected.

For those (above) approaches to work:

* domain-owners/holders can, either use TLSA "2 s m" when they want
to use their own CA cert and other certs based on that CA cert
(these approach is aka : TA, non-public CA cert, self-signed private
CA cert, etc),

* or, domain-owners/holders can use TLSA "3 s m" when they want to
provide a secure service by using a very specific & single server
cert from a very specific server (these approach is aka :
domain-issued cert, domain cert, EE cert, server cert, no cert
chain, etc).

Since domain-owner's/holder's self created certificate is not
included in any web-browser software, when any visitor/user will try
to visit such site/zone securely using HTTPS/TLS encrypted
connections, then web-browser will ask/prompt visitors/users with 1
or more questions/messages that if visitor/user wants to
load+trust+use that unknown cert from that site or not.

cert = certificate , aka = also known as , CA = Certificate
Authority , TA = Trust Anchor, EE = end entity.

And, when higher level of secured solution is expected AND when
extra info are needed to be shown to visitors/users verified by a
mutually/known Trusted notarizing/vouching type of party, then TLSA
"u s m" would be "0 s m" or "1 s m". These type of cert comes from
public CA cert based company, such CA cert are usually pre-included
in web-browsers or in client software, and usually these companies
charge a fee/money to issue such domain cert or intermediate CA cert.

Both of these ("0 s m" , "1 s m") solutions are favored by
web-browser developing groups, so they kept it in such a condition
that : it will not create any extra warning and it will not
ask/prompt visitors/users with a question/message, when a HTTPS/TLS
based secured site is visited or web service is used.

Since, domain-owner/holder has publicly declared what exact cert
he/she/they trusts using TLSA "2 s m" or "3 s m" based dns rr, then
why web-browser will ask question/prompt visitor/user ? !
it is not unknown anymore, it is already+clearly declared+known+shown.

More practical use cases, guidance are needed to be shown publicly
for both "3 s m" and "2 s m" cases, specially for "2 s m" as it
involves extra configurations.

- - - - - - - - - - - - - - - - - - - - - - - - - -

For example, I own 3  domain-names which are related, and want to
use a common root CA cert for all these 3 domains/zones, so i did
these, as i have 3 set of server computers tuned for 3 different
type of tasks, and located in 3 different network locations :

Self-signed private non-public root CA cert (My_root_CA_cert) -->
intermediate high-strength CA cert (My_i_CA_1_cert) -->
dom1.tld_cert --> { www.dom1.tld_cert , m.dom1.tld_cert ,
mail.dom1.tld_cert , mail2.dom1.tld_cert , ns.dom1.tld_cert ,
ns2.dom1.tld_cert , livemsg.dom1.tld_cert }

and then i created for dom2.tld :

intermediate high-strength CA cert (My_i_CA_1_cert) -->
dom2.tld_cert --> { www.dom2.tld_cert , m.dom2.tld_cert ,
mail.dom2.tld_cert , mail2.dom2.tld_cert , ns.dom2.tld_cert ,
ns2.dom2.tld_cert , livemsg.dom2.tld_cert }

and so on.

Physical_Server_1 has:
* 'www', 'ns' and 'mail' hosts of "dom1.tld" in 3 separate VM instance.
* above hosts of "dom2.tld".
* above hosts of "dom3.tld".

Physical_Server_2 has:
* 'm', 'ns2' and 'mail2' hosts of "dom1.tld" in 3 separate VM instance.
* above hosts of "dom2.tld".
* above hosts of "dom3.tld".

Physical_Server_3 has:
* 'livemsg' host of "dom1.tld" in a VM instance, * 'livemsg' host of
"dom2.tld", * 'livemsg' host of "dom3.tld"

"dom1.tld" is for providing certain set of tasks/services/projects
01. "dom2.tld" is for providing another set of
tasks/services/projects 02. "dom3.tld" is for providing images,
videos, etc and may be placed in another server location.

If Physical_Server_01 is restarted or updated or downed or
disconnected for some reason, all essential services will be
delivered to visitors/users from redundant services from
Physical_Server_02.

So how many & what DNS RR will "www" host/server for "dom1.tld" will
exactly need/have for providing DANE based HTTPS service ?

In apache/nginx server software (HTTPS service daemon), in what
order it will have to provide those tls/ssl certs ?

What else need to be configured ?

Thanks in advance,

- -- Bright Star.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 May 2013 14:37:10 +0000

> (these approach is aka : TA, non-public CA cert, self-signed private

In which case they'd better make sure that the server's certificate
chain (sent during the TLS handshake) includes the TA certificate,
because the verifier can't be expected to have a copy.  Naive
implementations may not even handle 2 0 0 correctly.

> domain-issued cert, domain cert, EE cert, server cert, no cert

This is the most robust use case.  The name in the certificate
should not matter, but naive implementations may perform erroneous
name checks here, so if possible include the TLSA RR base domain
as a DNS subjectAltName in the peer certificate.

> load+trust+use that unknown cert from that site or not.

Until browsers support DANE.  Browser support for DANE should be
reasonably common before HTTPS servers (serving the public at large)
start employing usage 2/3 certificates that are not valid with
respect to the existing public CA PKI.

> charge a fee/money to issue such domain cert or intermediate CA cert.

IMHO the public CA PKI is irreparably broken, and provides little
additional assurance.  There is little reason to public 0/1 or even
2 when 3 is substantially more robust.

> based secured site is visited or web service is used.

No, all that's required is that during the transition your certificates
are still issued by a public CA that non DANE aware clients can verify.
There is no reason to public 0/1 when 3 matches the same certificate.
I expect that browsers will support all the usages.

> why web-browser will ask question/prompt visitor/user ? !

They should not, and I expect will not, once they support DANE.

-- 
	Viktor.

---

From: Christian Heutger <[email-masked]>
Date: Wed, 29 May 2013 18:22:32 +0000

Hi,

>2 when 3 is substantially more robust.

in my opinion, CA PKI model get hardened / recent issues fixed with DANE
but DANE is not able to replace it by sense. See below.

>They should not, and I expect will not, once they support DANE.

Finally DANE can replace the so called domain validation certificates as
how ever a domain control may be proofed when by a certificate stored in
the DNS. However the pressure to renew certificates (and generating new
private keys), limited validity of a certificate and additional third
party check of revocation status (especially if the webmaster and
hostmaster is not the same and there is a need of quick reaction) are open
topics.

But public certs beside the encryption and domain binding topic have
another reason: a third party proof the website owners existence, legal
name, address, depend on the certificate a minimum of 3 years doing
business etc. So finally DANE can't prevent from Phishing (similar
domains), can't prevent from unknown business partners, Š That still
requires someone verifying identity and warrantying for the job done. DANE
can ensure here, that this certificate is the real one and it's not been
"rewritten" by anyone else.

Regards,
Christian

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 May 2013 18:45:55 +0000

On Wed, May 29, 2013 at 06:22:32PM +0000, Christian Heutger wrote:

> the DNS.

We should not debate the merits and demerits of various PKI models
here.  The OP's question was about browser behaviour, and my comment
on the existing public CA PKI was mostly irrelevant personal opinion,
intended to justify the expectation that browsers will not only
support certificate usage 0/1 to the exclusion of 2/3.

Since browsers accept DV certs today, they most likely will also
support DANE validated certs when they implement DANE.  I would
expect Mozilla, Chrome, IE, ... to eventually include native
reasonably well designed DANE implementations without the need for
third-party plugins.  It is important that this happens, so if any
of you can influence browser vendors in that direction, do it!

[ Additional security beyond DV might be gained in the context of
  DANE via new TLDs where membership policies provide appropriate
  assurance against brand confusion.  Let's not get distracted by
  this issue, it is largely off topic. ]

-- 
	Viktor.

---

From: Rick Andrews <[email-masked]>
Date: Wed, 29 May 2013 19:24:25 -0700

> -----Original Message-----

Viktor,

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.

-Rick Andrews

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 30 May 2013 03:02:02 +0000

On Wed, May 29, 2013 at 07:24:25PM -0700, Rick Andrews 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.

You have little to worry about.  There's plenty of disagreement
all around, and I am a relative newcomer here, whatever respect I
may have earned here is limited in scope.  I expect my drafts will
prove a tough sell on various points.

I think we can all agree that my answer to the OP's question about
browser support for 2/3 is not controversial.

-- 
	Viktor.

P.S.  [ Explanation of personal views, not intended to change anyone's mind. ]

My concerns with respect certificate usages 0, 1 (and even 2) are
rather pragmatic.  Security systems that generate too many false
positives (false alarms of something wrong) and require users to
"click OK" to get past the annoying FPs ultimately fail to protect
users, even when the false negative rate is lower than with competing
systems.

My view is that a system with fewer FPs is better even if it has
more FNs, provided these are in balance.  Pulling numbers out of
thin air (not to be taken as carefully considered values), I'd
prefer a system with 0.01% FPs and 0.01% FNs over one with 5% FPs
and 0.00002% FNs.  The point being that with a 5% FP rate, the user
won't believe the verdict even when the system detects a real
problem.

In implementing DANE support for Postfix, I've found that usage 3
is by far the easiest to implement correctly for both the verifying
client and the verified server.  All the other use cases exhibit
subtleties that make FPs (verification failures with no actual MITM
in sight) more likely.  With public CAs this includes incomplete
list of CAs on the client side, problems with CRLs, ...  And I
don't buy the FN story for public CAs since there are so many of
them one needs to trust to avoid FPs.

With email reliable/timely delivery generally outweighs security
considerations, MTAs are store and forward, there is no user to
click OK, so high FP rates are simply unacceptable.  The KISS
principle leads me to conclude that with SMTP usage "3" wins over
all the others.

There are other reasons I dislike the public CA PKI, but I don't
bring particularly relevant expertise to those topics beyond what
others have said many times in the past.

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 30 May 2013 09:37:21 +0200

> 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, no…

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: Christian Heutger <[email-masked]>
Date: Thu, 30 May 2013 08:09:36 +0000

Hi Jakob,

I support your point of view, however domain validation also has some
advantages with public certificates over DANE. The requirement for
renewing (create new private key), the instant revoke with CRL and OCSP
(against caching DNS) but finally also to aware against hackers and
spammers. So if you look at DANE, everyone can run a valid site with https
and e.g. spread malware through that as often https traffic is not scanned
and usually be trusted, like recent mentioned phishing attacks. In
addition with SMTP over TLS running mail servers, the assumption would be,
that it is a valid mail server. If everyone can go with SMTP over TLS,
giving more trust to valid SMTP connections will be undergone.

Regards,
Christian 

Am 30.05.13 09:37 schrieb "Jakob Schlyter" unter <[email-masked]>:

>>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.
>
>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
>
>_______________________________________________
>dane mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dane
>
>--
>This message was scanned by ESVA and is believed to be clean.
>

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 30 May 2013 12:03:22 +0200

> 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 wh…

+1 !!!

--Olaf

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 30 May 2013 12:13:36 +0200

> giving more trust to valid SMTP connections will be undergone.

The additional services you mention are optional and not part of WebTrust and/or ETSI certifications. There is no guarantee that such services are performed on services served under a classic PKI certificate.

Regarding revocation we've seen too many examples where CRLs are not checked properly by the clients and/or OCSP responders are not responding (or responding so slow that users disable them). This might not be how the PKI infrastructure was designed, but it is the reality.

Anyone can do SMTP with TLS today and most (sane) mail servers do that. Without classic PKI. And the SMTP servers they talk to do no validation whatsoever. DANE can only make things better here.

	jakob

---

From: Tom Ritter <[email-masked]>
Date: Thu, 30 May 2013 07:33:13 -0400

I don't disagree with the idea that CAs+DANE provides a greater barrier for
HTTPS domain impersonation than just DANE.  But...

On 30 May 2013 04:09, Christian Heutger <[email-masked]> wrote:

> the instant revoke with CRL and OCSP
> (against caching DNS)

I don't agree with this.  Revocation through TTL expiry on a domain can
provide the same revocation delay as CRLs and OCSP.  CRLs have a "window of
replay" up to a week, OCSP from 6 hours to a day (usually).  TTLs are in
the same ballpark, and are configurable.

> like recent mentioned phishing attacks.

As part of my job I run phishing attacks on companies, fairly regularly.
 While most CAs do a decent job of protecting against the highest-profile
domains, obtaining a DV cert for the other 99.9% of companies is never a
problem.  A long lived or extremely popular phishing attack may get
detected in time to protect some users, but a single-day or two-operation
does not.  This is an advantage of CAs, but not a large one due to the lack
of protections supplied for 99.9% of companies, the fact that all CAs are
trusted equally so I can go to the weakest one, and that there is a natural
desire for CAs to issue certificates fast and only flag certificates for
manual review if absolutely necessary.

> In

PKIX Validation + SMTP is all sorts of wonky.  I'm just throwing it out
there ;)

> place to discuss this matters.

I'll occasionally join in if the consensus is to allow this type of
discussion, but unless it's directly related to a standard we're working on
or implementing, I don't really think this type of conversation is
productive at this point.  These arguments and debates have been hashed and
rehashed over and over.  There is a difference of opinion, and people feel
strongly on both sides.  Civil discussion is fine, but a lot of people are
tired of the topic, so the level of civility and interest is decreasing -
making the conversations less enlightening as time goes on.

-tom

---

From: Rick Andrews <[email-masked]>
Date: Thu, 30 May 2013 04:58:26 -0700

> > renewing (create new private key), the instant revoke with CRL and
> > OCSP (against caching DNS) but finally also to aware against hackers
> > and spammers. So if you look at DANE, everyone can run a valid site
> > with https and e.g. spread malware through that as often https
> traffic
> > is not scanned and usually be trusted, like recent mentioned phishing
> > attacks. In addition with SMTP over TLS running mail servers, the
> > assumption would be, that it is a valid mail server. If everyone can
> > go with SMTP over TLS, giving more trust to valid SMTP connections
> will be undergone.
> 
> The additional services you mention are optional and not part of
> WebTrust and/or ETSI certifications. There is no guarantee that such
> services are performed on services served under a classic PKI
> certificate.

It seems that there are enough differences between PKI use in SMTP and SSL/TLS that we should probably separate them for discussion. I'm most familiar with SSL. The services you mention are not entirely optional. SSL certs must be frequently renewed (the max validity period is being reduced over the next few years thanks to CA/Browser Forum requirements). IIS requires you to generate a new key pair when you renew. CRLs and OCSP responses are updated when a certificate is revoked.

> Regarding revocation we've seen too many examples where CRLs are not
> checked properly by the clients and/or OCSP responders are not
> responding (or responding so slow that users disable them). This might
> not be how the PKI infrastructure was designed, but it is the reality.

Things have been improving here. Several CAs have moved to or are considering moving to Content Distribution Networks (CDNs) for their CRLs and/or OCSP responses, which provide very low latency and very high availability. I hope browser vendors will reevaluate their behavior with respect to revocation as the situation improves. Browsers that don't check CRLs properly should address this problem in their implementations.

I would say for SSL at least, a DV cert from a public CA is superior to DANE without PKIX validation (DANE modes 2 and 3) because:
- The DV cert will conform to Baseline Requirements (minimum key size, strong signing and hashing algorithm, acceptable validity period, proper extensions)
- The DV cert would be very likely to have undergone automated checks for weak keys, weak exponents, not on Debian weak key list, not on internal phish lists, etc.
- The DV cert would contain AIA and/or CDP extensions, so if the CA detects that the site is fraudulent, it can revoke the cert.
- The CA issuing the cert would have undergone a WebTrust or ETSI audit. Audits aren't perfect, but I feel strongly that the threat of failing and audit makes CAs pay more attention to detail.

If I create my own self-signed SSL certificate, I can give it a 30-year validity, use MD2 or MD5, include a Debian weak key, add no basicConstraints extension or have CA=true. Such practices put my site and my users at risk.

> Anyone can do SMTP with TLS today and most (sane) mail servers do that.
> Without classic PKI. And the SMTP servers they talk to do no validation
> whatsoever. DANE can only make things better here.

I'm not familiar with SMTP. I wonder if both ends of the connection do proper chain validation and checks for the particular cert that is expected? Has anyone attempted MITM attacks against mail servers to see if they can be tricked? If they're not doing "classic PKI", it may be trivial to spoof one end of an SMTP connection and cause all kinds of trouble.

-Rick

---

From: Christian Heutger <[email-masked]>
Date: Thu, 30 May 2013 12:13:18 +0000

Thanks Rick,

there need to be added, that for Usage 2 there also rises up the issue, on
how secure the "own CA" is. CAs pay huge amounts to keep their
infrastructure secure, like Hardware Key Modules, like Offline-Signing
etc. So with Usage 2 the own CA can be everything, from an online CA,
storing the private key in the public accessible webroot, enabling
everyone who recognized it to issue certs for the domain by himself.

Am 30.05.13 13:58 schrieb "Rick Andrews" unter <[email-masked]>:

>It seems that there are enough differences between PKI use in SMTP and
>SSL/TLS that we should probably separate them for discussion. I'm most
>familiar with SSL. The services you mention are not entirely optional.
>SSL certs must be frequently renewed (the max validity period is being
>reduced over the next few years thanks to CA/Browser Forum requirements).
>IIS requires you to generate a new key pair when you renew. CRLs and OCSP
>responses are updated when a certificate is revoked.
>
>Things have been improving here. Several CAs have moved to or are
>considering moving to Content Distribution Networks (CDNs) for their CRLs
>and/or OCSP responses, which provide very low latency and very high
>availability. I hope browser vendors will reevaluate their behavior with
>respect to revocation as the situation improves. Browsers that don't
>check CRLs properly should address this problem in their implementations.
>
>I would say for SSL at least, a DV cert from a public CA is superior to
>DANE without PKIX validation (DANE modes 2 and 3) because:
>- The DV cert will conform to Baseline Requirements (minimum key size,
>strong signing and hashing algorithm, acceptable validity period, proper
>extensions)
>- The DV cert would be very likely to have undergone automated checks for
>weak keys, weak exponents, not on Debian weak key list, not on internal
>phish lists, etc.
>- The DV cert would contain AIA and/or CDP extensions, so if the CA
>detects that the site is fraudulent, it can revoke the cert.
>- The CA issuing the cert would have undergone a WebTrust or ETSI audit.
>Audits aren't perfect, but I feel strongly that the threat of failing and
>audit makes CAs pay more attention to detail.
>
>If I create my own self-signed SSL certificate, I can give it a 30-year
>validity, use MD2 or MD5, include a Debian weak key, add no
>basicConstraints extension or have CA=true. Such practices put my site
>and my users at risk.
>
>I'm not familiar with SMTP. I wonder if both ends of the connection do
>proper chain validation and checks for the particular cert that is
>expected? Has anyone attempted MITM attacks against mail servers to see
>if they can be tricked? If they're not doing "classic PKI", it may be
>trivial to spoof one end of an SMTP connection and cause all kinds of
>trouble.
>
>-Rick 
>
>--

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 30 May 2013 14:53:21 +0200

On 30 maj 2013, at 14:13, Christian Heutger <[email-masked]> wrote:

> So with Usage 2 the own CA can be everything, from an online CA,

There is not practical difference between usage 2 and 3 - it is just a choice of levels of indirection.

The core of the DV problem is that as long as you control the DNS (and therefore the mail server), you can get any certificate for anything within the domain. DANE just makes this issue more apparent (and adds actual security by requiring DNSSEC).

	jakob

---

From: Warren Kumari <[email-masked]>
Date: Thu, 30 May 2013 10:37:08 -0400

> Unless the chairs do not object, I believe this mailing list is a good place to discuss this matters.

The chairs  do not object. Obviously though, as always, standard mailing list etiquette is expected -- if this turns into ad hominem attack (or simply ads :-) ) we'll stomp on it…. 
> 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 e…

<no hats>
Well, yes and no…

It all (to me at least) depends on what all the attacker has managed to compromise. If (one day, fingers crossed) end hosts are all doing DNSSEC then an attacker who gets a mi-sissued cert shouldn't be able to actually use it, unless they have also compromised the DNS.

As an example, the Diginotar incident. If a site has a DV (or whatever other cert) and were using DANE, the attacker (who we assume has on the wire MITM capabilities) would not be able to actually *use* the cert. 

If the compromise happens because you lost control of your DNS infrastructure (including your registrar account, etc) then yeah, no huge difference…

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

Agreed.

> 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).

Also agreed. 

</no hats>

--
"Have you got any previous convictions?"

"Well, I dunno... I suppose I used to believe very firmly that a penny saved is a penny earned--"
-- Terry Pratchett

---

From: Ben Laurie <[email-masked]>
Date: Thu, 30 May 2013 15:39:42 +0100

> As an example, the Diginotar incident. If a site has a DV (or whatever other cert) and were using DANE, the attacker (who we assume has on the wire MITM capabilities) would not be able to actually…

You are imagining a future in which browsers suddenly decide that
out-of-band checking is acceptable, which seems unlikely to actually
occur other than in fantasy.

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 30 May 2013 16:53:55 +0200

> occur other than in fantasy.

Why?

---

From: Ben Laurie <[email-masked]>
Date: Thu, 30 May 2013 15:55:06 +0100

On 30 May 2013 15:53, Olaf Kolkman <[email-masked]> wrote:
> As an example, the Diginotar incident. If a site has a DV (or whatever other
> cert) and were using DANE, the attacker (who we assume has on the wire MITM
> capabilities) would not be able to actually *use* the cert.
>
>

Because:

a) It introduces latency, and

b) It isn't reliable, so cannot be hard-fail.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 30 May 2013 15:18:10 +0000

> a) It introduces latency, and

Negligible because DNS RRs are cached near the client, ideally at
127.0.0.1 (a forwarding DNSSEC validating cache on every computer,
mobile phone, ...), thereby eliminating issues wrt. MITM attacks
between the client and the caching resolver.

Also with a DNSSEC-validating cache, the client does not need to
repeatedly re-validate the same data.

The Postfix SMTP client maintains a small in-memory working-set of
such records, which further reduces latency to completely negligible
levels.

> b) It isn't reliable, so cannot be hard-fail.

I have to click "OK" multiple times a day with the current PKI,
often with ietf.org sites when the URL uses an different name for
the site than is found in its certificate, or because I don't trust
a bunch of questionable CAs, ...  will likely be far *more* reliable
(fewer false rejections) than the existing public CA PKI.

With a "3 1 1" TLSA RR (matching a leaf cert ultimately signed by
a public CA for now), a DANE-aware browser can reliably succeed
where the public CA PKI fails, due to:

    - A rogue CA publishing unauthorized certificates.
    - An incomplete (whatever that means) CA list on the client
    - Problems with CRLs

What specific problems do you anticipate with DANE TLSA that make
it unsafe to "hard-fail"?

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 30 May 2013 15:29:59 +0000

> PKIX Validation + SMTP is all sorts of wonky.  I'm just throwing it out

Please, please, find ~10 free minutes and read the draft!

    https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-00

Then you will see that:

    - The existing public CA PKI and SMTP with MX indirection are incompatible.

    - The same likely applies to submission via SRV records.

    - DANE is well suited to securing both, via 2/3 TLSA RRs only.

and perhaps you can help to improve the draft.

Thanks.

-- 
	Viktor.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 30 May 2013 16:41:00 +0100

> between the client and the caching resolver.

Even if this were true, first hit latency matters, too. As anecdotal
evidence, I just resolved a name unlikely to be cached locally:

$ dig www.disney.com
;; Query time: 535 msec

Unacceptable.

> repeatedly re-validate the same data.

Our experiments suggest that a _large_ percentage of clients cannot
see DNSSEC records at all.

> it unsafe to "hard-fail"?

See above.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 30 May 2013 08:51:09 -0700

> evidence, I just resolved a name unlikely to be cached locally:

Except that, thanks to glue records and parallelism and speculative prefetch, you can ALSO fetch TYPE=DANE along with the TYPE=A and TYPE=AAAA records that are already having to be fetched, and the DNSSEC related records (DS, DNSKEY, etc) can also be speculatively fetched, so there should be NO latency hit for fetching the records, with the only latency hit involving signature validation.

Although I disagree about the cache local.  The VALIDATION should be local, but it should still use the ISP-level recursive resolver cache, as that IS a huge win in practical performance and, thanks to DNSSEC in general, you don't have to trust that lying, MitMing SOB.

> see DNSSEC records at all.

This is the bigger problem, and I agree.  We should have some detailed data soon from Netalyzr, the tests that have been running for a while are:

Direct to the Internet fetching of DNSSEC records (DNSSEC to all roots for DS, DNSKEY, RRSIG, and NSEC, DNSSEC to .com for NSEC3)

Recursive resolver fetching of DNSSEC records using DO

Recursive resolver fetching of DNSSEC records without using DO to see if you can get the full necessary RRSIG for .com

(e.g. OpenDNS fails the latter: If you query without DNSSEC, you don't get the RRSIG for the DS record for .com!  But then again, OpenDNS is vocal that DNSSEC runs counter to their business model, so they will never support it)

I suspect that a non-trivial (>.1%, probably >1%) of sessions will fail all three tests, but I haven't conducted that data analysis yet.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 30 May 2013 15:55:39 +0000

> evidence, I just resolved a name unlikely to be cached locally:

That's how long it took to get the A record, which the browser
needs anyway!  So it must be acceptable.

    - This is I assume why Google does DNS pre-fetching, and the
      same can be done for TLSA RRs.

    - With a suitable asynchronous DNS lookup API, multiple DNS queries
      can be sent in parallel, the A record, AAAA record and TLSA RRs
      can all arrive in parallel.

What slows down page loads for me is not DNS, but the "skip this ad"
links that come up before the real page loads :-)

> see DNSSEC records at all.

This is fine, they can continue to use legacy PKI.  DANE does not
apply when the client has no DNSSEC support.  DANE is not intended
to "hard fail" when the client can't use DNSSEC.  It only hardfails
when it can and the returned RRs are "bogus".

A more serious issue for browsers is corporate MITM proxies.
Browsers behind such proxies (much as Chrome does now, since it
"knows" about the certificates of some sites) need to be configured
to enable alternatives to the default TLS security policy.

> > it unsafe to "hard-fail"?

You have not yet mentioned anything that makes it unsafe to hardfail
when TLSA RRs don't match, or DNSSEC replies are bogus.  Otherwise,
DANE does not hard fail.  I really don't want to be oppositional, 
sorry if it seems that way, difficult to seem otherwise in email.

It seems there may be some misconceptions about the DANE TLSA PKI
validation model, are you open to exploring this possibility?

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 30 May 2013 16:09:37 +0000

On Thu, May 30, 2013 at 08:51:09AM -0700, Nicholas Weaver wrote:

> Although I disagree about the cache local.  The VALIDATION should
> be local, but it should still use the ISP-level recursive resolver
> cache, as that IS a huge win in practical performance and, thanks
> to DNSSEC in general, you don't have to trust that lying, MitMing
> SOB.

A local cache should typically forward all requests to the ISP,
and validate the result locally.  There is no need to saddle
applications with DNSSEC validating code and library dependency
DLL hell. DNSSEC via IPC to "unbound" or similar is much cleaner.

I'm not suggesting side-stepping the ISP cache, just placing a
local cache between that and the application.  For example, there
should I believe be a DNSSEC validating cache on Android phones,
to complement the DNSSEC validation on 8.8.8.8.  That way the MITM
at a Starbucks Wifi hotspot can't tamper with 8.8.8.8 DNS replies.

> This is the bigger problem, and I agree.  We should have some
> detailed data soon from Netalyzr, the tests that have been running
> for a while are:

IMHO a DNSSEC-aware local resolver that can't see DNSSEC RRs through
its DHCP discovered forwarder should have a fallback strategy that
either uses the root servers directly, or uses 8.8.8.8 or similar
services that are publically accessible and don't fail to support
DNSSEC.  This would give Google more intel on DNS lookup traffic,
so I doubt they would mind.

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

-- 
	Viktor.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 30 May 2013 11:10:30 -0400

>> occur other than in fantasy.

Yes, I am, but 'tis a very pretty fantasy, filled with unicorns, rainbows, kittens and a Bloodhound (http://www.dnssec-tools.org/download/#gotoBloodhound). Obviously this is a niche browser, but...

Damn kids, git off of my fantasy...

> a) It introduces latency, and

Yes, this is true.

One option (less than ideal, but still better than nothing) would be for the DANE lookup / processing to be done in parallel with the normal A record, but not block the page. If, after the page is rendered / displayed it turns out that DANE says that something is wrong, the page could be replaced with the big, red, scary thing. Yes, by then it is possibly too late (you have already shipped cookies, etc to the attacker), but better than blithely thinking you are in the right place.

"Always do DANE" could also be an option that folk could decide to turn on, if they are more paranoid than the average user. Some folk might prefer a latency hit for the added peace of mind. 

It could also be that DANE is triggered only for "self signed" / other places where the "There is something odd here" bit happens. Would allow for some of the benefits, and (IMO) not that large a latency hit, as reading the "We couldn't validate this cert, what do you ant to do?!" bit takes some time anyway…

But yes, I get the issue. 

W

--
Curse the dark, or light a match. You decide, it's your dark.
                -- Valdis Kletnieks

---

From: Ben Laurie <[email-masked]>
Date: Thu, 30 May 2013 17:18:42 +0100

> when it can and the returned RRs are "bogus".

The issue is not that the clients can't use DNSSEC, the issue is that
they cannot retrieve DNSSEC records.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 30 May 2013 16:43:15 +0000

On Thu, May 30, 2013 at 05:18:42PM +0100, Ben Laurie wrote:

> >> See above [ I moved it below, so see below ]
> >

So is your concern that at this time DNSSEC lookup are too likely to
return "bogus" (rather than with anything specific in DANE itself)?

If so, then indeed we're relatively early on the DNSSEC adoption
curve, and some issues remain to be addressed in hostile environments
such as Hotel/Cafe/Airplane/... public Wifi hotspots that MITM DNS
for the terms-of-use click-through and/or customer authentication.

The state of the art here is regrettable,  we need to have better
mechanisms than that for joining public networks, ideally ones that
authenticate not only the customer, but also the provider.

> they cannot retrieve DNSSEC records.

Well, there's always 8.8.8.8:

    $ drill -D -t ns com. @8.8.8.8
    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 25827
    ;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 0 
    ;; QUESTION SECTION:
    ;; com.	IN	NS

    ;; ANSWER SECTION:
    com.	21033	IN	NS	a.gtld-servers.net.
    ...
    com.	21033	IN	NS	m.gtld-servers.net.
    com.	21033	IN	RRSIG	NS 8 1 172800 20130603042012 20130527031012
    35519 com.
    nETo/p1pX2mJo+BHZI20iQkgIGVTgbnqZ8vNf+CDy3w4/LJwrtP/r0NLBVzaQ/xpSLrxnkoxY9aRGtuwJp7oTOdTcq9gCN/QYyPuLK4gZT6BwjnOZmlVvyIQK8GKpafpsLniYX2xVGg07f7lpYdmRpMMZS4t5HXo46WZABXyYYU=

    ;; AUTHORITY SECTION:

    ;; ADDITIONAL SECTION:

    ;; Query time: 42 msec
    ;; EDNS: version 0; flags: do ; udp: 512
    ;; SERVER: 8.8.8.8
    ;; WHEN: Thu May 30 12:24:24 2013
    ;; MSG SIZE  rcvd: 419

and while some clients can't get to 8.8.8.8 either (WiFi hot-spot
browser MITM use-terms click-through), one simply uses HTTP for
that, it is an MITM attack regardless of PKI model.

The browser's DNS requests can include the "CD" bit when connecting
to non-HTTPS sites, or for mobile devices the O/S can provide a
suitable UI for joining mobile networks with the browser employing
"CD" just for that context.

[ The "CD" bit is "checking disabled" and solicits raw results from
  the validating cache. ]

-- 
	Viktor.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 30 May 2013 17:51:28 +0100

> return "bogus" (rather than with anything specific in DANE itself)?

Indeed.

> Well, there's always 8.8.8.8:

How does that help if you can't retrieve DNSSEC records?

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 30 May 2013 17:02:52 +0000

> > return "bogus" (rather than with anything specific in DANE itself)?

Understood. There are perhaps work-arounds, and this should improve
over time.

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

The remaining issue is jailed clients joining hotspots, ... that
may not be able to reach any external DNS servers.  This too can
be addressed (for example via the "CD" bit and HTTP and perhaps
a UI for joining networks that disables DNSSEC until the mobile
device is out of jail).

Longer term joining public networks should be handled at the
802.1X layer with suitable mobile devices UIs.  Not via MITM
on DNS and browsers.

> >     com.        21033   IN      RRSIG   NS 8 1 172800 20130603042012 20130527031012 35519 com. nETo/p1pX2mJo+BHZI20iQkgIGVTgbnqZ8vNf+CDy3w4/LJwrtP/r0NLBVzaQ/xpSLrxnkoxY9aRGtuwJp7oTOdTcq9gCN/QYyPuLK4gZT6BwjnOZmlVvyIQK8GKpafpsLniYX2xVGg07f7lpYdmRpMMZS4t5HXo46WZABXyYYU=

-- 
	Viktor.

---

From: SM <[email-masked]>
Date: Thu, 30 May 2013 17:23:40 -0700

>evidence, I just resolved a name unlikely to be cached locally:

;; Query time: 1221 msec

Regards,
-sm

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 31 May 2013 10:42:22 +0200

> a UI for joining networks that disables DNSSEC until the mobile

I am very interested in the last-mile and one of the ways we've tried to approach the last mile is by allowing folk to try.  Enter dnssec-trigger, a tool that does some config magic and allows you to run a validating resolver on 127.0.0.1.

At this moment it is clear to me that what we've done is not yet at the consumer level, on the other hand we are building a corpus of  operational experience on the type of problems people run into. I invite/encourage folk to try the tool and help us build experience by sharing their experiences on the dnssec-trigger mailinglist.  My personal experience is that you will need to understand a bit of troubleshooting and an occassional "unbound-control flush_zone ." to get you out of misery.

(See https://www.nlnetlabs.nl/projects/dnssec-trigger/ which is signed by CACERT, for which most of you will not have a trust-anchor in their browser, however it www.nlnetlabs.nl comes with a TLSA record, oh irony)

--Olaf

PS Chairs, I accept a slap if this is on the wrong side of the border of promotion.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 31 May 2013 13:29:18 +0000

> just a choice of levels of indirection.

There is a big difference in the implementation robustness.  With usage
3 the client looks only at the peer certificate or public key.

    - The server operator cannot accidentally leave out the required
      intermediate CAs from his chain (one of the most frequent
      administrator caused failure modes for TLS).

    - The client does not perform name checks, so a lot less can fail.

Therefore, while 2 and 3 are very similar in theory (when administrators
don't make mistakes and client implementations are bug free), the
usage 3 TLSA RR is far more likely to be robust in practice.

I'll add something to the operations draft about usage 3:

    - Servers SHOULD use a certificate with subjectAltname DNS entries
      that matches the base domains of all relevant TLSA RRs even with
      usage 3, because some client implementations may erroneously insist
      on checking the subject name in usage 3 certificates.

    - Clients MUST ignore the subject name in usage 3 cerficates, checking
      for a matching certificate or public key is the only check the client
      needs to perform.

-- 
	Viktor.

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 31 May 2013 17:34:35 +0200

> a) It introduces latency, and

so does checking revocation lists and OCSP.

> 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 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: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 31 May 2013 11:36:23 -0400

On Thu, May 30, 2013 at 6:13 AM, Jakob Schlyter <[email-masked]> wrote:

> The additional services you mention are optional and not part of WebTrust
> and/or ETSI certifications. There is no guarantee that such services are
> performed on services served under a classic PKI certificate.
>
> checked properly by the clients and/or OCSP responders are not responding
> (or responding so slow that users disable them). This might not be how the
> PKI infrastructure was designed, but it is the reality.
>

I agree with Jacob here but for a slightly different set of reasons.

First and most important, SMTP certs are only ever seen by SMTP clients
which are almost always MTAs in the modern Internet. It is not possible to
send SMTP on port 25 from 95% of IP addresses. You have to use submit. So
even if someone wanted to put a user experience onto STARTTLS they can't.
And doing so would be a silly idea because STARTTLS is not end to end at
the receiver.

So STARTTLS is an application where we only ever require confirmation of
the DNS name and nothing more. There is no need for accountability in a
receiver. There is no need to validate a claim to a real world identity and
reputation.

The Web is a very different environment because many sites do accept
payments and phishing is a threat. We are finding that the number of sites
that require accountability or establishing an identity or external
reputation claim is actually greater than the number of sites with CA
certs. So reducing the validation criteria to nothing more than a domain
name check is really not acceptable for those Web applications.

DANE is certainly relevant for the 95%+ of Web sites without any TLS at
all. Just as anything is better than a self signed unbound cert, anything
is better than no crypto. Just don't tell people to have confidence in it.
Do the crypto and don't mention that you did.

Whatever techies think the padlock icon SHOULD mean, the only meaning the
users will ever understand is 'I am safe'. So unless you think DANE alone
makes people SAFE then there should be no user interface.

The main reason that the WebPKI is designed the way that it is is that Marc
Andressen wanted to tell people that it is safe to shop online and the
Netscape lawyers told him that they were not going to let him take that
liability. Rather ironically, SSL was Marc's real contribution to the Web.
He gets no credit for it for two reasons. First he had a non-compete with
EIT that stopped him working on security (ever wondered why they chose Kipp
knowing he had no crypto experience?). Second, well you all know that one.

The liability concern is still there. Any browser provider that tells their
users that it is safe to use a site validated on DANE alone is accepting an
indeterminate liability.

[I think they are also kind of blowing it by not implementing revocation
checking properly but that is an easy fix for them. One morning there will
be some case and some lawyer will say 'hardfail OCSP'. And suddenly a bunch
of CAs with rubbish OCSP responders are going to be finding that they have
to fix them before they get their roots renewed.]

Which gets me back to STARTTLS and certs there. Sure DANE is better than
nothing and it is actually a good fit administratively. As a commercial
model it makes perfect sense for CAs to package DNSSEC administration up
with SSL certage and why not present through DNS and DANE? Its a good sales
package for the CAs to offer.

But I would not want to offer that package without putting the standard
disclaimers and warranties etc. in the certificate or else my liability is
going to be a problem. And I am probably going to want to offer something
for the outbound mail server as well (Using DKIM) where accountability is a
real issue and so the customer would want the cert issued off a public root.

So yes, DANE is synergistic with SMTP but it is an adjunct to rather than a
replacement for traditional PKI.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 31 May 2013 11:43:42 -0400

> 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]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 31 May 2013 11:57:37 -0400

On Fri, May 31, 2013 at 11:34 AM, Jakob Schlyter <[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.
>
> 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

I did tell everyone that I have been banging my head against that
particular wall for the past 20 years. But did anyone listen?

I predicted phishing back in 1993 and proposed DIGEST to pre-empt the
problem. But it was rejected due to a UNIX superstition against shadow
passwords and Rob and Ari's desire to be able to use the existing UNIX
password file to validate requests.

The reason I am proposing Omnibroker is because changing the browser is
hard and if we are going to improve Web security we need to decouple
security research from the need to deploy new browsers. If we can get them
to do omnibroker then we make one change and we move the security nexus out
to a place where we can do interesting stuff.

---

From: Guido Witmond <[email-masked]>
Date: Fri, 31 May 2013 19:08:32 +0200

On 31-05-13 17:34, Jakob Schlyter wrote:
> On 30 maj 2013, at 16:55, 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.
>

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

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.

DANE usage 0 is the missing link between (domain)name and signer,
something that was envisioned with ISO-x500 directory but never 
materialised.

Could you poke some people from the inside at your CA to consider it. I
don't think it is a lot of work. If I'm not mistaken, with usage 0, it
would be the same for each certificate signed with the CA's Root. (But
what do I know, I'm just a beginner. ;-) )

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

It would not give much security benefits without Perspectives, Cert
Patrol and others, but it is a little extra work for MitM-boxes to keep
up their appearance.

And it certainly help solving the chicken and egg problem we have now.
So please pursue that path.

Respectfully, Guido.

---

From: Jakob Schlyter <[email-masked]>
Date: Sat, 1 Jun 2013 08:47:42 +0200

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

I don't work at any CA - I'm just one of the crypto plumbers who wrote RFC 6698.

> gives me the correct RR-line, ready to include in my DNS(SEC)-records.

That sounds like an excellent idea.

	jakob