4 ms·

Regardless of whether you think it's dishinest or not, his point still stands: tls mitm is not and cannot be mitigated via DNS.

tptacek 4y ago
Nor with DNSSEC: the same government that gave Microsoft control over this zone has de jure control over DNSSEC key management for that zone.
- xorcist 4y ago
  This control is indistinguishable from a domain transfer, so this is trivially true. Zones not under their control, however, are not vulnerable to this. So compared to the current system it would be an improvement.
- dane-pgp 4y ago
  DNSSEC doesn't protect you against the American government if you have a .org domain, but I doubt an American court could give Microsoft control over a domain registered under a ccTLD like .de or .ru or .za for example. I suspect Microsoft would also have trouble taking control of a domain registered under a gTLD run by a company based outside the US, but it would be interesting to see how the agreements between the gTLDs and ICANN would work out in practice.
  - rosnd 4y ago
    >DNSSEC doesn't protect you against the American government if you have a .org domain, but I doubt an American court could give Microsoft control over a domain registered under a ccTLD like .de or .ru or .za for example. What? Obviously they could. ICANN is subject to US law.
  - dcomp 4y ago
    Technically they could force root nameservers (based in the US) to intercept/proxy the whole gtld. So all except n (netnod (EU)) and i (WIDE (JP))
    - rosnd 4y ago
      >So all except n (netnod (EU)) and i (WIDE (JP)) US could just drop the records for those.
      - belorn 4y ago
        No, the US could not do that and there is multiple reasons for it. The root zone is rather special in that operating system semi-hard code the root servers. The operating system also have full control here and the number of name servers at the root zone changes very slowly. Operating systems developed by people not bound by US courts could just ignore it. The other reason is political. If they were to cut out eu or asia from the list then the risk of a split would increase massively. It would be suicide. If they did that people might even split internet further by splitting iana (Internet Assigned Numbers Authority), in which case a computer in EU would be unable to communicate with an computer in US, and then the concept of a global internet would no longer exist. A split is a exceedingly dangerous concept.
        rosnd 4y ago
        I think the hardcoded IPs are typically only used as hints to initially resolve the root-servers.net domains.
        belorn 4y ago
        Hints are used by the bind resolver software. It hard code the A -> M root servers and use those to initialize a cache. Naturally bind developers could change this behavior, and in the case that none of the hints works, the current behavior is to use a static compiled list that the software also include.
        rosnd 4y ago
        Not just bind, unbound also. Unbound uses the hardcoded list of IPs to resolve a-m once and build it's cache, the hardcoded IPs are never used again.
- huggingmouth 4y ago
  I wish there was wide support for public-key-addressable servers (like tor adresses). It won't solve the issue of memorable names, but it could solve this bootstrapping problem. Perhaps le should look into encorperating tor into its domain verification process.
  - hn_go_brrrrr 4y ago
    How do you handle key rotation?
    - Zamicol 4y ago
      Publish merkle roots on global ledgers like blockchains.
      - withinboredom 4y ago
        Handshake (namebase.io) comes to mind.
    - josephg 4y ago
      When you connect to the service, the client tells the server which public key (key A) its expecting the server to prove that it has ownership of. If the key A is still valid, the server can use the corresponding private key to sign a challenge. If the key has been rotated out, the server instead presents the new key, and a signature. Eg, the server responds by naming key B, and presents a certificate of key B, signed by key A (the presented key). Instead of just a single key rotation the server could present a chain of certificates from A to B to C (the key the server wants to use). And optionally, a message saying "from now on, please make further requests using key B as key A has expired".
      - dolni 4y ago
        This falls apart if keys are ever compromised.
        4y ago

tptacek 4y ago

Nor with DNSSEC: the same government that gave Microsoft control over this zone has de jure control over DNSSEC key management for that zone.

xorcist 4y ago
This control is indistinguishable from a domain transfer, so this is trivially true. Zones not under their control, however, are not vulnerable to this. So compared to the current system it would be an improvement.
dane-pgp 4y ago
DNSSEC doesn't protect you against the American government if you have a .org domain, but I doubt an American court could give Microsoft control over a domain registered under a ccTLD like .de or .ru or .za for example. I suspect Microsoft would also have trouble taking control of a domain registered under a gTLD run by a company based outside the US, but it would be interesting to see how the agreements between the gTLDs and ICANN would work out in practice.
- rosnd 4y ago
  >DNSSEC doesn't protect you against the American government if you have a .org domain, but I doubt an American court could give Microsoft control over a domain registered under a ccTLD like .de or .ru or .za for example. What? Obviously they could. ICANN is subject to US law.
- dcomp 4y ago
  Technically they could force root nameservers (based in the US) to intercept/proxy the whole gtld. So all except n (netnod (EU)) and i (WIDE (JP))
  - rosnd 4y ago
    >So all except n (netnod (EU)) and i (WIDE (JP)) US could just drop the records for those.
    - belorn 4y ago
      No, the US could not do that and there is multiple reasons for it. The root zone is rather special in that operating system semi-hard code the root servers. The operating system also have full control here and the number of name servers at the root zone changes very slowly. Operating systems developed by people not bound by US courts could just ignore it. The other reason is political. If they were to cut out eu or asia from the list then the risk of a split would increase massively. It would be suicide. If they did that people might even split internet further by splitting iana (Internet Assigned Numbers Authority), in which case a computer in EU would be unable to communicate with an computer in US, and then the concept of a global internet would no longer exist. A split is a exceedingly dangerous concept.
      - rosnd 4y ago
        I think the hardcoded IPs are typically only used as hints to initially resolve the root-servers.net domains.
        belorn 4y ago
        Hints are used by the bind resolver software. It hard code the A -> M root servers and use those to initialize a cache. Naturally bind developers could change this behavior, and in the case that none of the hints works, the current behavior is to use a static compiled list that the software also include.
        rosnd 4y ago
        Not just bind, unbound also. Unbound uses the hardcoded list of IPs to resolve a-m once and build it's cache, the hardcoded IPs are never used again.
huggingmouth 4y ago
I wish there was wide support for public-key-addressable servers (like tor adresses). It won't solve the issue of memorable names, but it could solve this bootstrapping problem. Perhaps le should look into encorperating tor into its domain verification process.
- hn_go_brrrrr 4y ago
  How do you handle key rotation?
  - Zamicol 4y ago
    Publish merkle roots on global ledgers like blockchains.
    - withinboredom 4y ago
      Handshake (namebase.io) comes to mind.
  - josephg 4y ago
    When you connect to the service, the client tells the server which public key (key A) its expecting the server to prove that it has ownership of. If the key A is still valid, the server can use the corresponding private key to sign a challenge. If the key has been rotated out, the server instead presents the new key, and a signature. Eg, the server responds by naming key B, and presents a certificate of key B, signed by key A (the presented key). Instead of just a single key rotation the server could present a chain of certificates from A to B to C (the key the server wants to use). And optionally, a message saying "from now on, please make further requests using key B as key A has expired".
    - dolni 4y ago
      This falls apart if keys are ever compromised.
      - 4y ago