4 ms·

If we trust DNS to publish the SNI public keys, why don't we trust it for the website certificate in the first place?

by opqpo 6y ago

yeaaaaaaaah 6y ago
Because it angers Thomas Ptacek.
thegagne 6y ago
I suppose because the certificate changes more often and it’s more reliable/predictable to change the server cert than DNS? If you ARE rotating the SNI public keys I’m assuming you can easily support multiple active at the same time.
Polylactic_acid 6y ago
Is getting an bad sni key a terrible risk? What kind of data would it leak?
- opqpo 6y ago
  The certificate will still have to be verified at client-side with the CAs. I know my idea will break the entire TLS flow but I am just talking about the validity of it in the first place.
  - zxcmx 6y ago
    Was just thinking about that. ESNI just protects the name of the site you're visiting. It's going to be most useful to reduce the amount of data available to bulk snoopers like ISPs or mass surveillance efforts. But there are lots of ways traffic analysis can uncover data. They can look at request sizes, timing, IP addresses - and critically, your DNS requests. ESNI is an incremental protection that is not expected to be perfect. Just reduce the amount of "low hanging data" that can easily be plucked from streams. If an attacker can snoop or hard MITM your DNS they know what site you are visiting anyway. So under the kind of threat model that makes sense for ESNI to be useful there is no real downside to distributing the keys over DNS. Actually I just had a look at the RFC and this explanation is redundant because they did it themselves in section 7.1: https://tools.ietf.org/html/draft-ietf-tls-esni-04#page-21 https://tools.ietf.org/html/draft-ietf-tls-esni-04#page-21 In contrast the existing CA infrastructure is intended to protect the content of the user's communications in basically all malicious networking scenarios: DNS hijacking and MITM in particular. The threats that the existing CA infrastructure are meant to protect you from are quite different. However, there is no reason I can think of that you couldn't distribute the certificate for say, foo.com (signed by existing CA infra) via DNS instead of sending it in-band. I believe you could make the protocol "work" this way. But DNS is not such a great protocol for sending big things like long certificate chains (in contrast to more svelte naked keys for ESNI). It would not be as good as sending it in-band and the security would be rather worse (more prone to disruption / poisoning / DoS), with more metadata leaked (eg certificate exchange is part of encrypted handshake in standard TLS). The main semantic difference I can see is that usually the server chooses what server certificate to present; DNS distribution would be more like the client choosing what server cert to use due to DNS eventual consistency. As a practical concern, servers would have to support all valid certs until expiry or introduce additonal negotiation. Servers would also need to figure out which cert the client actually chose, somehow (either by trial decryption or client signalling). Anyway, not TLS as we know it anymore. It's subtly (but not fatally) worse along several dimensions and I keep thinking of more ways it's worse as I've continued to edit this comment. Last thought: an attacker could easily force you to use an old (but not yet expired) cert. Again I guess the DNS-CA-TLS franken-protocol would have to work around that with additional mechanism (perhaps something like OCSP stapling).
- tialaramex 6y ago
  The owners of the key pair whose public half you are tricked into using get to see the otherwise concealed ClientHello which today includes SNI and ALPN. So e.g. they'd know you wanted to speak HTTP/2 to some.name.example But on the other hand to have substituted this key for the correct one they presumably already intercepted your DNS query and so they likely already knew you were intending to talk to some.name.example from that query.
donmcronald 6y ago
It's way easier to give someone a fake DNS reply than to get a valid SSL certificate, so maybe it's just a matter of risk. Bad DNS exposes where you're going. Bad SSL exposes everything you're doing there. It really doesn't matter though. You can just use DoH and trust Google / Cloudflare for everything. /s
- nuker 6y ago
  Im curious, can DoH server set Http cookies on my machine? Is DoT safer in this regard?
  - zxcmx 6y ago
    The server can Set-Cookie for sure if it wants to but the resolver is not supposed to accept it. From rfc8484: "HTTP cookies SHOULD NOT be accepted by DOH clients unless they are explicitly required by a use case." You'd have to review your particular resolver implementation to be sure. I suppose one would have to say DoT is safer in this regard, since accepting cookies is not an implementation error you could reasonably make without using an HTTP library. Most users are probably better off with DoH. It protects transport better. Sadly the problem of finding someone trustworthy to resolve through doesn't go away. EDIT: ^ This is wrong; DNS-over-TLS is fine.
    - nuker 6y ago
      > Most users are probably better off with DoH. It protects transport better. Thanks. Why it protects transport better?
      - deleted 6y ago
        [deleted]
      - zxcmx 6y ago
        Ohhhhhhhhhhhhh I wrote my reply assuming you meant DNS-over-TCP not DNS-over-TLS. Duh, sorry. Should have been obvious from context. Yeah DNS-over-TLS is safer in this regard and provides equivalent network-path protection. DoH is kind of a garbage protocol but it's a concession to the fact that a lot of "real" networks are broken and HTTP(s) is the only thing you can rely on being able to transport. Since DNS-over-HTTPS goes over proxies and uses port 443, it'll "work by default" in a larger variety of networks than DNS-over-TLS. CloudFlare have made the argument that DoH "blends in" better with regular HTTPS traffic but I don't really buy that when everyone just uses the same few recursive resolvers.
becauseiam 6y ago
It's possible we _could_ - a combination of DNSSEC used to sign records, and TLSA records to provide the linking. In reality, however...
BillinghamJ 6y ago
Yep, there is a standard for exactly that - it's called DANE - https://en.m.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.m.wikipedia.org/wiki/DNS-based_Authentication_of_... I was quite hopeful it might lead to widespread use of self-signed certs, though with things like LetsEncrypt, it's not really needed any more
amalcon 6y ago
You need to look at the threat model. The threat model around eSNI public key substitution is a minor privacy invasion: Eve can see the hostnames you're connecting to. This isn't so bad because your DNS provider can already see the hostnames you're connecting to. Standards like DNS over TLS are being explored to make it harder for other parties to use this type of attack. The threat model around TLS public key substitution is basically full read/write control over your requests. This represents both a major privacy invasion and exposure of auth secrets like your bank account password. Your DNS provider doesn't already have access to those things. edit: You could deliver a cert this way, and authenticate the cert out of band e.g. through the CA system. This kind of approach is sound from a security standpoint, but there just isn't a lot of upside. There are fewer moving parts when you just deliver the cert the way we do now.
badrabbit 6y ago
DANE is a thing but also, websites can and should work without DNS (IP SAN) and alsk, it gets difficult when you have multiple subdomains and when the certificate is for the http host instead of the domain. But for regular sites, DANE with CT logs makes a lot of sense
hannob 6y ago
> If we trust DNS to publish the SNI public keys, why don't we trust it for the website certificate in the first place? These are two very different things. The SNI public keys are only used to encrypt the hostname, i.e. the goal here is hostname privacy. You can't have hostname privacy without trusting the DNS. But it will always be a weak form of privacy, because you have to trust a third party. So what is happening here is that we say "ok, we can't have perfect hostname privacy, but allowing the DNS server to compromise our privacy is better than allowing it to everyone". Now if you put the cert there you'd say "we allow the DNS to compromise all of our TLS". You really don't want that. As multiple people here have said there's a way to put signed certificates into DNS called DANE. But it suffers from the fact that it relies on DNSSEC, which is a complex beast and probably most relevant: Which in the decades it has existed hasn't managed to get any relevant traction.

If we trust DNS to publish the SNI public keys, why don't we trust it for the website certificate in the first place?

by opqpo 6y ago

If we trust DNS to publish the SNI public keys, why don't we trust it for the website certificate in the first place?

yeaaaaaaaah 6y ago

Because it angers Thomas Ptacek.

thegagne 6y ago

I suppose because the certificate changes more often and it’s more reliable/predictable to change the server cert than DNS? If you ARE rotating the SNI public keys I’m assuming you can easily support multiple active at the same time.

Polylactic_acid 6y ago

Is getting an bad sni key a terrible risk? What kind of data would it leak?

opqpo 6y ago
The certificate will still have to be verified at client-side with the CAs. I know my idea will break the entire TLS flow but I am just talking about the validity of it in the first place.
- zxcmx 6y ago
  Was just thinking about that. ESNI just protects the name of the site you're visiting. It's going to be most useful to reduce the amount of data available to bulk snoopers like ISPs or mass surveillance efforts. But there are lots of ways traffic analysis can uncover data. They can look at request sizes, timing, IP addresses - and critically, your DNS requests. ESNI is an incremental protection that is not expected to be perfect. Just reduce the amount of "low hanging data" that can easily be plucked from streams. If an attacker can snoop or hard MITM your DNS they know what site you are visiting anyway. So under the kind of threat model that makes sense for ESNI to be useful there is no real downside to distributing the keys over DNS. Actually I just had a look at the RFC and this explanation is redundant because they did it themselves in section 7.1: https://tools.ietf.org/html/draft-ietf-tls-esni-04#page-21 https://tools.ietf.org/html/draft-ietf-tls-esni-04#page-21 In contrast the existing CA infrastructure is intended to protect the content of the user's communications in basically all malicious networking scenarios: DNS hijacking and MITM in particular. The threats that the existing CA infrastructure are meant to protect you from are quite different. However, there is no reason I can think of that you couldn't distribute the certificate for say, foo.com (signed by existing CA infra) via DNS instead of sending it in-band. I believe you could make the protocol "work" this way. But DNS is not such a great protocol for sending big things like long certificate chains (in contrast to more svelte naked keys for ESNI). It would not be as good as sending it in-band and the security would be rather worse (more prone to disruption / poisoning / DoS), with more metadata leaked (eg certificate exchange is part of encrypted handshake in standard TLS). The main semantic difference I can see is that usually the server chooses what server certificate to present; DNS distribution would be more like the client choosing what server cert to use due to DNS eventual consistency. As a practical concern, servers would have to support all valid certs until expiry or introduce additonal negotiation. Servers would also need to figure out which cert the client actually chose, somehow (either by trial decryption or client signalling). Anyway, not TLS as we know it anymore. It's subtly (but not fatally) worse along several dimensions and I keep thinking of more ways it's worse as I've continued to edit this comment. Last thought: an attacker could easily force you to use an old (but not yet expired) cert. Again I guess the DNS-CA-TLS franken-protocol would have to work around that with additional mechanism (perhaps something like OCSP stapling).
tialaramex 6y ago
The owners of the key pair whose public half you are tricked into using get to see the otherwise concealed ClientHello which today includes SNI and ALPN. So e.g. they'd know you wanted to speak HTTP/2 to some.name.example But on the other hand to have substituted this key for the correct one they presumably already intercepted your DNS query and so they likely already knew you were intending to talk to some.name.example from that query.

donmcronald 6y ago

It's way easier to give someone a fake DNS reply than to get a valid SSL certificate, so maybe it's just a matter of risk. Bad DNS exposes where you're going. Bad SSL exposes everything you're doing there. It really doesn't matter though. You can just use DoH and trust Google / Cloudflare for everything. /s

nuker 6y ago
Im curious, can DoH server set Http cookies on my machine? Is DoT safer in this regard?
- zxcmx 6y ago
  The server can Set-Cookie for sure if it wants to but the resolver is not supposed to accept it. From rfc8484: "HTTP cookies SHOULD NOT be accepted by DOH clients unless they are explicitly required by a use case." You'd have to review your particular resolver implementation to be sure. I suppose one would have to say DoT is safer in this regard, since accepting cookies is not an implementation error you could reasonably make without using an HTTP library. Most users are probably better off with DoH. It protects transport better. Sadly the problem of finding someone trustworthy to resolve through doesn't go away. EDIT: ^ This is wrong; DNS-over-TLS is fine.
  - nuker 6y ago
    > Most users are probably better off with DoH. It protects transport better. Thanks. Why it protects transport better?
    - deleted 6y ago
      [deleted]
    - zxcmx 6y ago
      Ohhhhhhhhhhhhh I wrote my reply assuming you meant DNS-over-TCP not DNS-over-TLS. Duh, sorry. Should have been obvious from context. Yeah DNS-over-TLS is safer in this regard and provides equivalent network-path protection. DoH is kind of a garbage protocol but it's a concession to the fact that a lot of "real" networks are broken and HTTP(s) is the only thing you can rely on being able to transport. Since DNS-over-HTTPS goes over proxies and uses port 443, it'll "work by default" in a larger variety of networks than DNS-over-TLS. CloudFlare have made the argument that DoH "blends in" better with regular HTTPS traffic but I don't really buy that when everyone just uses the same few recursive resolvers.

becauseiam 6y ago

It's possible we _could_ - a combination of DNSSEC used to sign records, and TLSA records to provide the linking. In reality, however...

BillinghamJ 6y ago

Yep, there is a standard for exactly that - it's called DANE - https://en.m.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.m.wikipedia.org/wiki/DNS-based_Authentication_of_... I was quite hopeful it might lead to widespread use of self-signed certs, though with things like LetsEncrypt, it's not really needed any more

amalcon 6y ago

You need to look at the threat model. The threat model around eSNI public key substitution is a minor privacy invasion: Eve can see the hostnames you're connecting to. This isn't so bad because your DNS provider can already see the hostnames you're connecting to. Standards like DNS over TLS are being explored to make it harder for other parties to use this type of attack. The threat model around TLS public key substitution is basically full read/write control over your requests. This represents both a major privacy invasion and exposure of auth secrets like your bank account password. Your DNS provider doesn't already have access to those things. edit: You could deliver a cert this way, and authenticate the cert out of band e.g. through the CA system. This kind of approach is sound from a security standpoint, but there just isn't a lot of upside. There are fewer moving parts when you just deliver the cert the way we do now.

badrabbit 6y ago

DANE is a thing but also, websites can and should work without DNS (IP SAN) and alsk, it gets difficult when you have multiple subdomains and when the certificate is for the http host instead of the domain. But for regular sites, DANE with CT logs makes a lot of sense

hannob 6y ago

> If we trust DNS to publish the SNI public keys, why don't we trust it for the website certificate in the first place? These are two very different things. The SNI public keys are only used to encrypt the hostname, i.e. the goal here is hostname privacy. You can't have hostname privacy without trusting the DNS. But it will always be a weak form of privacy, because you have to trust a third party. So what is happening here is that we say "ok, we can't have perfect hostname privacy, but allowing the DNS server to compromise our privacy is better than allowing it to everyone". Now if you put the cert there you'd say "we allow the DNS to compromise all of our TLS". You really don't want that. As multiple people here have said there's a way to put signed certificates into DNS called DANE. But it suffers from the fact that it relies on DNSSEC, which is a complex beast and probably most relevant: Which in the decades it has existed hasn't managed to get any relevant traction.