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

["Rene 'Renne' Bartsch, B.Sc. Informatics" <[e-mail]>]

Am 16.08.2018 um 12:10 schrieb Star Brilliant:
> On Thu, Aug 16, 2018 at 7:37 PM Rene 'Renne' Bartsch, B.Sc. Informatics <ietf=[e-mail]> wrote:
>>
>> Am 16.08.2018 um 11:01 schrieb Star Brilliant:
>>> On Thu, Aug 16, 2018 at 6:13 PM Rene 'Renne' Bartsch, B.Sc. Informatics <ietf=[e-mail]> 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).
>>>
>>> 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?
> 
> The security level is the same with either PKI and DANE.
> 
> Let me explain.


>> - Fraudulent certificate requests
> 
> 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/

>> - 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 the OSCP server is down the (sub-) domain is not reachable any more? The DNS is much more robust than an OCSP-server.

>> Bottom line: Don't trust a CA.
> 
> No offence, but do you trust ICANN?
> 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