7 ms·

Technically there's no reason that there couldn't be an automatic PKI over the entire IP space, in which routers and ISPs are CAs. It never happened because the

Technically there's no reason that there couldn't be an automatic PKI over the entire IP space, in which routers and ISPs are CAs. It never happened because the IP world sees crypto as an app-layer problem, but it doesn't have to be that way. The protocols could be encrypted by default - all that's needed are protocols to let a device communicate to the router what its chosen public key is, and for that to communicate it back to the owner of the IP block, which has to operate an OCSP-like query service to vend certs.

bawolff 5y ago
That's sort of how Resource Public Key Infrastructure works for bgp. The big question is - do you trust your isp for that. Of potential attackers who can eavesdrop on my connection, isp (or someone at isp or gov giving isp a warrant) seems pretty high on the list.
- Nevermark 5y ago
  It isn't end-to-end encryption if you have to trust someone in the middle. Right?
  - bawolff 5y ago
    Well usually the term end-end means from you directly to the user you are talking to (if its in a chat context for example). TLS (in its normal usage) isn't end to end, putting encryption in a lower layer makes it even less likely to be end to end. In end to end encryption, preventing mitm attacks is the hardest part and often is glossed over. How many people actually verify the "safety number" when using signal? Probably most do not. So i would say common definitions of end to end allows for trusting someone in the middle to not perform active attacks (after all, you also have to trust them not to provide malicious binaries with keyloggers) but should prevent passive attacks by someone in middle.
    - Nevermark 5y ago
      Hmm. I think end-to-end needs to remain end-to-end, and you don't need to trust a plethora of third parties if everyone is using the same library/platform for encryption. Middle parties don't need to know anything about the encryption. The source for that library will be extremely well vetted. Maybe the most vetted code ever written. There are practicalities, such as how improved encryption gets added to the protocol, and how clients from previous versions negotiate the best supported encryption between them. Also, affordances for encrypted delayed transmission, i.e. storage in the middle. For instance, email providers would need to store encrypted messages until your local reader downloads them (either to read or store locally). In some cases such as backups, and syncing between your own clients, end-to-end would really just mean your end. As only you would ever decrypt anything. Either way, zero need for any third party to be involved in the encryption, other than the source & binary provider.Go with a highly respected/vetted version, or even a standards committee's reference implementation officially vetted by many entities, and a mechanism for anyone to vet and report. There is some thought needed for the design, as with any platform. And perfection might never be achieved - but things are much less perfect today. The return on that careful work would be an insane drop in the number of disparate implementations needed, and a much safer internet without all the cracks in and between disparate implementation.
      - bawolff 5y ago
        I'm not sure how having a single code base would help anything. Sure, interopable standards are needed, but what benefit does a single code base get us? > Also, affordances for encrypted delayed transmission, i.e. storage in the middle. For instance, email providers would need to store encrypted messages until your local reader downloads them (either to read or store locally). So the scenario here is we add encryption transparently at either layer 3 or layer 4 and the encryption is end-to-end (the email provider cannot read it, only the intended recipient). How would that work? At the very least the email provider would have to know the application level "to" address to route the email. If its end to end encrypted, they cannot as they are a middle party. Maybe you could say that some metadata is unencrypted, but then the encryption is clearly not happening transparently on a low layer if the application layer turns it on and off for different parts of the message. Not to mention - who are you encrypting it to? (Aka which key are you using). If this is transparently on layer 3/4 one presumes the key is tied to the ip address (and maybe port?) as the only identifier available. If its end to end encrypted through a middle man (email provider) for an eventual destination for whom not only do you not know their ip address, they are offline right now so they literally don't have one, how can you possibly get the right key for that transparently without involving the application layer? > There is some thought needed for the design, as with any platform. And perfection might never be achieved - but things are much less perfect today. Personally i think TLS is pretty good all things considered. Its not without trade-offs but most of those trade offs are pretty reasonable given the technical constraints we have. > The return on that careful work would be an insane drop in the number of disparate implementations needed, and a much safer internet without all the cracks in and between disparate implementation. Very few security issues are caused by interoperability issues between different crypto implementations. One implementation might have a bug a different one doesn't, but settling on a single implementation wouldn't stop bugs from being a thing.
- native_samples 5y ago
  The ISP would still be untrusted. They're just running a database/discovery service for your public key. Now you might say, what stops them announcing the wrong public key to the world, and then decrypting/re-encrypting a connection when it flows inbound to that IP across its wires. And the answer is the same as with TLS/SSL: not much, so you have to do lots of double checking and pinning. Recall that nothing in today's internet really rigorously stops an ISP obtaining a certificate for a website it hosts, or even one that it doesn't! A CA like LetsEncrypt will automatically probe an IP from several vantage points as part of validating a domain->IP mapping but that process can be triggered at any point, and the vantage points can be easily discovered. So an ISP that can 'catch' all the vantage points, can just redirect IP traffic from the CA to its own server to obtain a cert, and then MITM traffic heading towards a website. It's the same problem when doing it at the IP level. However, there is still a lot of value because you can get public keys in a variety of ways. For instance you could try to connect to yourself back via Tor, or a variety of other services, to verify that your public key the rest of the internet sees is what you think it is.
  - bawolff 5y ago
    I disagree, incentives would be very different imo. > Now you might say, what stops them announcing the wrong public key to the world, and then decrypting/re-encrypting a connection when it flows inbound to that IP across its wires. And the answer is the same as with TLS/SSL: not much, so you have to do lots of double checking and pinning. in WebPKI: - CA's have struct rules (CAB and individual browser vendors) and have to go through audits to verify they follow them (how much an audit is worth is debatable) - certificate transparency ensures that CA's can't misbehave without being detected, which if they do, they get kicked out as a CA. If an isp misbehaves in this scenario, how do we punish them? Can we kick them out of the internet? Seems unlikely. If a CA refues to do something, we can kick them out. > and pinning I personally think pinning is generally a bad solution to pki problems, but for the sake of argument: how do you do pinning (or even something simpler like TOFU) with only a transient identifier like a dynamic IP address? What do you pin to? Its even worse if you still want to support NAT. > A CA like LetsEncrypt will automatically probe an IP from several vantage points as part of validating a domain->IP mapping but that process can be triggered at any point, and the vantage points can be easily discovered. So an ISP that can 'catch' all the vantage points, can just redirect IP traffic from the CA to its own server to obtain a cert, and then MITM traffic heading towards a website. It's the same problem when doing it at the IP level. Which can be immediately noticeable via certificate transparency. More to the point, there is no single attacker who is on path for all of lets encrypt's vantage points (and you don't have a relationship with any of lets encrypt's isps so they are less likely to care about you), which wouldn't be true for this new scheme. I guess you could argue that the web host in the webpki case (when not using dns validation) is the most likely point of attack, but they could just attack directly since they own the hardware. > However, there is still a lot of value because you can get public keys in a variety of ways. For instance you could try to connect to yourself back via Tor, or a variety of other services, to verify that your public key the rest of the internet sees is what you think it is. Its easy to come by lists of public proxies. Tor itself publishes a list of all ips participating in the tor network. Ultimately the biggest problem is enforcement incentives. Much of the security of web pki relies on being able to detect and punish misbehaving CA's (of which there are only a small number of). I don't see a politically viable way of doing that for ISPs.

bawolff 5y ago

That's sort of how Resource Public Key Infrastructure works for bgp. The big question is - do you trust your isp for that. Of potential attackers who can eavesdrop on my connection, isp (or someone at isp or gov giving isp a warrant) seems pretty high on the list.

Nevermark 5y ago
It isn't end-to-end encryption if you have to trust someone in the middle. Right?
- bawolff 5y ago
  Well usually the term end-end means from you directly to the user you are talking to (if its in a chat context for example). TLS (in its normal usage) isn't end to end, putting encryption in a lower layer makes it even less likely to be end to end. In end to end encryption, preventing mitm attacks is the hardest part and often is glossed over. How many people actually verify the "safety number" when using signal? Probably most do not. So i would say common definitions of end to end allows for trusting someone in the middle to not perform active attacks (after all, you also have to trust them not to provide malicious binaries with keyloggers) but should prevent passive attacks by someone in middle.
  - Nevermark 5y ago
    Hmm. I think end-to-end needs to remain end-to-end, and you don't need to trust a plethora of third parties if everyone is using the same library/platform for encryption. Middle parties don't need to know anything about the encryption. The source for that library will be extremely well vetted. Maybe the most vetted code ever written. There are practicalities, such as how improved encryption gets added to the protocol, and how clients from previous versions negotiate the best supported encryption between them. Also, affordances for encrypted delayed transmission, i.e. storage in the middle. For instance, email providers would need to store encrypted messages until your local reader downloads them (either to read or store locally). In some cases such as backups, and syncing between your own clients, end-to-end would really just mean your end. As only you would ever decrypt anything. Either way, zero need for any third party to be involved in the encryption, other than the source & binary provider.Go with a highly respected/vetted version, or even a standards committee's reference implementation officially vetted by many entities, and a mechanism for anyone to vet and report. There is some thought needed for the design, as with any platform. And perfection might never be achieved - but things are much less perfect today. The return on that careful work would be an insane drop in the number of disparate implementations needed, and a much safer internet without all the cracks in and between disparate implementation.
    - bawolff 5y ago
      I'm not sure how having a single code base would help anything. Sure, interopable standards are needed, but what benefit does a single code base get us? > Also, affordances for encrypted delayed transmission, i.e. storage in the middle. For instance, email providers would need to store encrypted messages until your local reader downloads them (either to read or store locally). So the scenario here is we add encryption transparently at either layer 3 or layer 4 and the encryption is end-to-end (the email provider cannot read it, only the intended recipient). How would that work? At the very least the email provider would have to know the application level "to" address to route the email. If its end to end encrypted, they cannot as they are a middle party. Maybe you could say that some metadata is unencrypted, but then the encryption is clearly not happening transparently on a low layer if the application layer turns it on and off for different parts of the message. Not to mention - who are you encrypting it to? (Aka which key are you using). If this is transparently on layer 3/4 one presumes the key is tied to the ip address (and maybe port?) as the only identifier available. If its end to end encrypted through a middle man (email provider) for an eventual destination for whom not only do you not know their ip address, they are offline right now so they literally don't have one, how can you possibly get the right key for that transparently without involving the application layer? > There is some thought needed for the design, as with any platform. And perfection might never be achieved - but things are much less perfect today. Personally i think TLS is pretty good all things considered. Its not without trade-offs but most of those trade offs are pretty reasonable given the technical constraints we have. > The return on that careful work would be an insane drop in the number of disparate implementations needed, and a much safer internet without all the cracks in and between disparate implementation. Very few security issues are caused by interoperability issues between different crypto implementations. One implementation might have a bug a different one doesn't, but settling on a single implementation wouldn't stop bugs from being a thing.
native_samples 5y ago
The ISP would still be untrusted. They're just running a database/discovery service for your public key. Now you might say, what stops them announcing the wrong public key to the world, and then decrypting/re-encrypting a connection when it flows inbound to that IP across its wires. And the answer is the same as with TLS/SSL: not much, so you have to do lots of double checking and pinning. Recall that nothing in today's internet really rigorously stops an ISP obtaining a certificate for a website it hosts, or even one that it doesn't! A CA like LetsEncrypt will automatically probe an IP from several vantage points as part of validating a domain->IP mapping but that process can be triggered at any point, and the vantage points can be easily discovered. So an ISP that can 'catch' all the vantage points, can just redirect IP traffic from the CA to its own server to obtain a cert, and then MITM traffic heading towards a website. It's the same problem when doing it at the IP level. However, there is still a lot of value because you can get public keys in a variety of ways. For instance you could try to connect to yourself back via Tor, or a variety of other services, to verify that your public key the rest of the internet sees is what you think it is.
- bawolff 5y ago
  I disagree, incentives would be very different imo. > Now you might say, what stops them announcing the wrong public key to the world, and then decrypting/re-encrypting a connection when it flows inbound to that IP across its wires. And the answer is the same as with TLS/SSL: not much, so you have to do lots of double checking and pinning. in WebPKI: - CA's have struct rules (CAB and individual browser vendors) and have to go through audits to verify they follow them (how much an audit is worth is debatable) - certificate transparency ensures that CA's can't misbehave without being detected, which if they do, they get kicked out as a CA. If an isp misbehaves in this scenario, how do we punish them? Can we kick them out of the internet? Seems unlikely. If a CA refues to do something, we can kick them out. > and pinning I personally think pinning is generally a bad solution to pki problems, but for the sake of argument: how do you do pinning (or even something simpler like TOFU) with only a transient identifier like a dynamic IP address? What do you pin to? Its even worse if you still want to support NAT. > A CA like LetsEncrypt will automatically probe an IP from several vantage points as part of validating a domain->IP mapping but that process can be triggered at any point, and the vantage points can be easily discovered. So an ISP that can 'catch' all the vantage points, can just redirect IP traffic from the CA to its own server to obtain a cert, and then MITM traffic heading towards a website. It's the same problem when doing it at the IP level. Which can be immediately noticeable via certificate transparency. More to the point, there is no single attacker who is on path for all of lets encrypt's vantage points (and you don't have a relationship with any of lets encrypt's isps so they are less likely to care about you), which wouldn't be true for this new scheme. I guess you could argue that the web host in the webpki case (when not using dns validation) is the most likely point of attack, but they could just attack directly since they own the hardware. > However, there is still a lot of value because you can get public keys in a variety of ways. For instance you could try to connect to yourself back via Tor, or a variety of other services, to verify that your public key the rest of the internet sees is what you think it is. Its easy to come by lists of public proxies. Tor itself publishes a list of all ips participating in the tor network. Ultimately the biggest problem is enforcement incentives. Much of the security of web pki relies on being able to detect and punish misbehaving CA's (of which there are only a small number of). I don't see a politically viable way of doing that for ISPs.