Subject: [Doh] Suggestion on draft-ietf-doh-dns-over-https-13: Recommend DANE-TLS to authenticate the TLS-certificate

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Thu, 16 Aug 2018 10:13:20 +0200

Hi,

as TLS-certificates forged or obtained by devious means have become common in MITM-attacks by intelligence and criminals
I suggest to RECOMMEND authentication of the DoH-server TLS-certificate via DANE-TLS (RFC 6698) in section 10 (Security considerations).

Renne

---

From: Star Brilliant <[email-masked]>
Date: Thu, 16 Aug 2018 09:01:47 +0000

> I suggest to RECOMMEND authentication of the DoH-server TLS-certificate via DANE-TLS (RFC 6698) in section 10 (Security considerations).

Hi Renne,

I am sorry I could not get your point.

How could it be possible to forge TLS certificates without being detected through our current PKI systems?

But I agree that we need OCSP-Stapling indeed to prevent a recursive bootstrapping problem.

---

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Thu, 16 Aug 2018 11:37:01 +0200

> How could it be possible to forge TLS certificates without being detected through our current PKI systems?

- Stolen CA keys/hacked CA (https://en.wikipedia.org/wiki/DigiNotar -> Issuance of fraudulent certificates)
- Malicious CA
- CA forced by malicious law
- Abuse of intermediate certificates (https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html)
- Fraudulent certificate requests
- Broken revocation system (https://medium.com/@alexeysamoshkin/how-ssl-certificate-revocation-is-broken-in-practice-af3b63b9cb3)

What if the client doesn't get the CRL/OCSP informtation?

Bottom line: Don't trust a CA.

Renne

---

From: Star Brilliant <[email-masked]>
Date: Thu, 16 Aug 2018 10:10:27 +0000

> > How could it be possible to forge TLS certificates without being detected through our current PKI systems?

The security level is the same with either PKI and DANE.

Let me explain.

> - Stolen CA keys/hacked CA (https://en.wikipedia.org/wiki/DigiNotar -> Issuance of fraudulent certificates)

Stolen/hacked KSK and ZSK.
And currently it is nearly impossible to revoke and rotate the root-anchor key in case anything bad happens.

> - Malicious CA

Malicious domain registrar that modifies NS records combined with GeoDNS to prevent being detected.

> - CA forced by malicious law

We have certificate transparency records and CAA records to protect them.
But nothing similar in DANE world.

> - Abuse of intermediate certificates (https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html)

Yes it is detected!
(I said "... forge TLS certificates without being detected ...")

> - Fraudulent certificate requests

I could not get your point. Any examples?

> - Broken revocation system (https://medium.com/@alexeysamoshkin/how-ssl-certificate-revocation-is-broken-in-practice-af3b63b9cb3)

Therefore OCSP-Stapling is necessary.
Not only for security, but also for bootstrap to work.

> What if the client doesn't get the CRL/OCSP informtation?

If unable to get OCSP information, the client will probably query itself in a loop, and may crash finally.
If you run DoH server by yourself you will know this problem.

> Bottom line: Don't trust a CA.

No offence, but do you trust ICANN?
That is single authority, compared with multiple CAs.

Conclusion: I do not think DANE should be preferred than PKI (or "MORE RECOMMENDED" than PKI).
At most they have the same level of security. (Actually DANE is worse, e.g. nearly impossible to rotate the root-anchor.)

---

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Thu, 16 Aug 2018 13:22:10 +0200

> I could not get your point. Any examples?

https://arstechnica.com/information-technology/2013/01/turkish-government-agency-spoofed-google-certificate-accidentally/
https://nakedsecurity.sophos.com/2013/12/09/serious-security-google-finds-fake-but-trusted-ssl-certificates-for-its-domains-made-in-france/

> If unable to get OCSP information, the client will probably query itself in a loop, and may crash finally.
If the OSCP server is down the (sub-) domain is not reachable any more? The DNS is much more robust than an OCSP-server.

> That is single authority, compared with multiple CAs.

I definitely do not trust the ICANN.

The benefits I see in DANE is you only have two parties involved: ICANN and registry.
Neither of them can change the signature without being detected because of the tree structure.
Checking hundreds of CAs is quite complicated and error-prone. A lot of certificates are not revoked as CAs demand a revokation fee.
DANE also allows to use free self-signed certificates and revoke them by changing the TLSA resource record.
DNS is more robust than a few OCSP servers. It is common usage to create fake TLS certificates via intermediate certificates on firewall appliances.
This is not possible with DANE.

> Conclusion: I do not think DANE should be preferred than PKI (or "MORE RECOMMENDED" than PKI).

My opinion: PKI gives CAs the possibility to handle security according to their will. DANE is too static to be tampered with in such a magnitude.

> At most they have the same level of security. (Actually DANE is worse, e.g. nearly impossible to rotate the root-anchor.)

This should be solved now and will happen on 10/11/2018.

Renne

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Aug 2018 06:38:08 -0700

On Thu, Aug 16, 2018 at 1:13 AM, Rene 'Renne' Bartsch, B.Sc. Informatics <
ietf=[email-masked]> wrote:

> Hi,
>
> as TLS-certificates forged or obtained by devious means have become common
> in MITM-attacks by intelligence and criminals
> I suggest to RECOMMEND authentication of the DoH-server TLS-certificate
> via DANE-TLS (RFC 6698) in section 10 (Security considerations).
>

I don't think we should make this change. Much of the value proposition of
DoH is that it's straightforward to run on top of existing HTTPS
infrastructure, and as a practical matter nearly all of that infrastructure
depends on WebPKI certs and does not do DANE. For that reason, this
recommendation would be more aspirational than practical.

-Ekr

---

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Thu, 16 Aug 2018 17:42:22 +0200

Am 16.08.2018 um 15:38 schrieb Eric Rescorla:
> 
> 
> On Thu, Aug 16, 2018 at 1:13 AM, Rene 'Renne' Bartsch, B.Sc. Informatics <ietf=[email-masked] <mailto:ietf=[email-masked]>> wrote:
> 
>     Hi,
> 
> I don't think we should make this change. Much of the value proposition of DoH is that it's straightforward to run on top of existing HTTPS infrastructure, and as a practical matter nearly all of that infrastructure depends on WebPKI certs and does not do DANE. For that reason, this recommendation would be more aspirational than practical.

The problem I see is that e.g. firewall appliances with fake certificates by intermediate certificates can break privacy and manipulate the DNS records.
Without proper authentication of the DoH-server certificate DoH only protects from script-kiddies.

Renne

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Aug 2018 09:15:54 -0700

On Thu, Aug 16, 2018 at 8:42 AM, Rene 'Renne' Bartsch, B.Sc. Informatics <
ietf=[email-masked]> wrote:

>> On Thu, Aug 16, 2018 at 1:13 AM, Rene 'Renne' Bartsch, B.Sc. Informatics
>> <ietf=[email-masked] <mailto:ietf=40bartschnet.de@d
>> marc.ietf.org>> wrote:
>>
>>     Hi,
>>
>>     as TLS-certificates forged or obtained by devious means have become
>> common in MITM-attacks by intelligence and criminals
>>     I suggest to RECOMMEND authentication of the DoH-server
>> TLS-certificate via DANE-TLS (RFC 6698) in section 10 (Security
>> considerations).
>>
>>
>> I don't think we should make this change. Much of the value proposition
>> of DoH is that it's straightforward to run on top of existing HTTPS
> The problem I see is that e.g. firewall appliances with fake certificates
> by intermediate certificates can break privacy and manipulate the DNS
> records.
>

if you are behind such a firewall, you have much bigger problems than fake
DNS records, given that the traffic you are sending post-resolution is
almost certainly being protected with something rooted in the WebPKI.

Without proper authentication of the DoH-server certificate DoH only
> protects from script-kiddies.
>

I don't think it's accurate to characterize WebPKI as not "proper
authentication". That's certainly not the position we've taken elsewhere in
the IETF.

If you want to make some broader argument about how we should stop trusting
WebPKI and universally recommend DANE instead, you're welcome to do so, but
this particular document is mostly just an other application of HTTPS, so
it's really not the place for it.

-Ekr

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

---

From: Adam Roach <[email-masked]>
Date: Thu, 16 Aug 2018 11:29:43 -0500

On 8/16/18 10:42, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:
>> On Thu, Aug 16, 2018 at 1:13 AM, Rene 'Renne' Bartsch, B.Sc. 
>> Informatics <ietf=[email-masked] 
>> <mailto:ietf=[email-masked]>> wrote:
>>
>>     Hi,
>>
>>     as TLS-certificates forged or obtained by devious means have 
>> become common in MITM-attacks by intelligence and criminals
>> I don't think we should make this change. Much of the value 
>> proposition of DoH is that it's straightforward to run on top of 
>> existing HTTPS infrastructure, and as a practical matter nearly all 
>> of that infrastructure depends on WebPKI certs and does not do DANE. 
>> For that reason, this recommendation would be more aspirational than 
>> practical.
>
> The problem I see is that e.g. firewall appliances with fake 
> certificates by intermediate certificates can break privacy and 
> manipulate the DNS records.

The document does not suggest that DoH servers are used without 
authentication.

What DoH does -- and this is a huge part of its appeal -- is leverage 
the existing web security model. Because it's used on top of HTTPS in 
general (rather than any specific version of HTTPS), I would expect that 
its security model evolves in lock-step with the web security model. If 
that eventually includes DANE in some capacity, then DoH will naturally 
do the same thing.

For your own uses, if you are so opposed to the web security model that 
you believe it will not work for your application, I encourage you to 
look into RFC 7858, with particular attention to section 4, as well as 
draft-ietf-dprive-dtls-and-tls-profiles.

/a