3 ms·

The IP address is just a hint in that example because we don't yet have robust identity based networking. It's actually meaningless, either I successfully auth

The IP address is just a hint in that example because we don't yet have robust identity based networking. It's actually meaningless, either I successfully authenticate with the public key on the other end, or I don't. I don't care about getting the wrong IP address, worst thing that could happen is that I bother the wrong process and it can't establish a connection with me. You must be a TLS expert because saying we need to check if a public key "belongs to the claimed identity" is creating a problem where none exists. The public key is an identity, that's who I want to connect to. In the Wireguard example, it really is that easy.

abnry 2y ago
I think man in the middle attacks are the concern. But still better than plaintext.
repelsteeltje 2y ago
TLS (as in https for websites) solves a different trust issue than wireguard. The case you present was two trusted parties (or one party ) set up a VPN between two hosts. It assumes there is some pre existing secure channel to exchange the public keys. If you were to simply exchange those over telnet, you're open to mitm attacks. With https this key exchange mitm aspect is acknowledged and that is where most of the complexity comes in. Since a client typically connects to a website without prior keys, we need a trusted third party like a CA or trust chain to verify were connecting to the domain we intended to connect to. Not staying tls isn't bloated, but to be fair, it solves a more complicated problem.
- alphazard 2y ago
  I don't think these use cases are as separable as the TLS "experts" would claim. If something is giving me the IP address, why can't it also give me the public key? We just don't have a convention of passing those things around together, security came after the fact. We didn't design for security. In a lot of cases the IP comes from a configuration file. That's assumed to be secure. In some cases it comes from an authority. If I'm trusting the authority for the IP address, why can't I trust them for the identity as well? I have to trust a different authority for that? That is twice as complicated as necessary. DNS should really be about which identity owns a name. We are starting to get there with DNSSec, once that's sorted out we could easily return `<public key>@<ip:port>` entries in authenticated DNS records. The root server (transitively) claimed that this public key represents this domain name, and it was last seen accepting connections at this IP and port.
  - tptacek 2y ago
    Purely from a technical perspective, whatever is giving you an IP address from a name lookup could indeed give you a certificate. The IETF has for 30 years been hypnotized by this fact, in much the same way as Joel Spolsky used to write about the "everything software project is some specific subclass of 'spreadsheet'". The problems with make name lookups yield certificates are all real-world, pragmatic, people-based issues: * The deployed base of DNS software, which includes middleboxes of all shapes and sizes that pay attention to DNS, is hostile to things that look like DANE lookups, so DANE lookups (really, all DNSSEC lookups) have a high failure rate, so high that anything using DNSSEC needs to have an alternate path to building a secure channel without DNSSEC. * The entities that ultimately decide what DNS lookups are going to return (note well: those entities are rarely ever the people who "own" the zones themselves) are themselves firms with roughly the same shape as certificate authorities, but with none of the accountability mechanisms; browser vendors had to force legacy CAs to adopt Certificate Transparency and no such leverage exists for the DNS. * For bonus fun, add in that ultimately most of the (~all of the popular) TLDs are de jure government controlled --- and governments have a lot of practice exploiting their control over DNS for policy ends. DNSSEC is a dead letter. Deployment in .COM actually WENT DOWN within the last 24 months, and it was trifling to begin with. The most common experience large tech companies have had with deploying it is "falling off the face of the Internet for several hours due to misconfiguration". Stick a fork in it. It was a reasonable idea that, like many reasonable ideas, has turned out to be completely impractical in the real world.
JackSlateur 2y ago
The public key can be linked to an identity only if the client already own that mapping (identity <-> public key) For the vast majority of use cases, this cannot be done, hence certificates (with CA)
tptacek 2y ago
WireGuard is deployed between mutually trusting, pre-introduced endpoints. TLS has to work for huge numbers of anonymous untrusting clients, often with transaction time budgets denominated in the tens of milliseconds. This is also where perennial exhortations to adopt SSH-style "ToFU" models on the public web run aground.

abnry 2y ago

I think man in the middle attacks are the concern. But still better than plaintext.

repelsteeltje 2y ago

TLS (as in https for websites) solves a different trust issue than wireguard. The case you present was two trusted parties (or one party ) set up a VPN between two hosts. It assumes there is some pre existing secure channel to exchange the public keys. If you were to simply exchange those over telnet, you're open to mitm attacks. With https this key exchange mitm aspect is acknowledged and that is where most of the complexity comes in. Since a client typically connects to a website without prior keys, we need a trusted third party like a CA or trust chain to verify were connecting to the domain we intended to connect to. Not staying tls isn't bloated, but to be fair, it solves a more complicated problem.

alphazard 2y ago
I don't think these use cases are as separable as the TLS "experts" would claim. If something is giving me the IP address, why can't it also give me the public key? We just don't have a convention of passing those things around together, security came after the fact. We didn't design for security. In a lot of cases the IP comes from a configuration file. That's assumed to be secure. In some cases it comes from an authority. If I'm trusting the authority for the IP address, why can't I trust them for the identity as well? I have to trust a different authority for that? That is twice as complicated as necessary. DNS should really be about which identity owns a name. We are starting to get there with DNSSec, once that's sorted out we could easily return `<public key>@<ip:port>` entries in authenticated DNS records. The root server (transitively) claimed that this public key represents this domain name, and it was last seen accepting connections at this IP and port.
- tptacek 2y ago
  Purely from a technical perspective, whatever is giving you an IP address from a name lookup could indeed give you a certificate. The IETF has for 30 years been hypnotized by this fact, in much the same way as Joel Spolsky used to write about the "everything software project is some specific subclass of 'spreadsheet'". The problems with make name lookups yield certificates are all real-world, pragmatic, people-based issues: * The deployed base of DNS software, which includes middleboxes of all shapes and sizes that pay attention to DNS, is hostile to things that look like DANE lookups, so DANE lookups (really, all DNSSEC lookups) have a high failure rate, so high that anything using DNSSEC needs to have an alternate path to building a secure channel without DNSSEC. * The entities that ultimately decide what DNS lookups are going to return (note well: those entities are rarely ever the people who "own" the zones themselves) are themselves firms with roughly the same shape as certificate authorities, but with none of the accountability mechanisms; browser vendors had to force legacy CAs to adopt Certificate Transparency and no such leverage exists for the DNS. * For bonus fun, add in that ultimately most of the (~all of the popular) TLDs are de jure government controlled --- and governments have a lot of practice exploiting their control over DNS for policy ends. DNSSEC is a dead letter. Deployment in .COM actually WENT DOWN within the last 24 months, and it was trifling to begin with. The most common experience large tech companies have had with deploying it is "falling off the face of the Internet for several hours due to misconfiguration". Stick a fork in it. It was a reasonable idea that, like many reasonable ideas, has turned out to be completely impractical in the real world.

JackSlateur 2y ago

The public key can be linked to an identity only if the client already own that mapping (identity <-> public key) For the vast majority of use cases, this cannot be done, hence certificates (with CA)

tptacek 2y ago

WireGuard is deployed between mutually trusting, pre-introduced endpoints. TLS has to work for huge numbers of anonymous untrusting clients, often with transaction time budgets denominated in the tens of milliseconds. This is also where perennial exhortations to adopt SSH-style "ToFU" models on the public web run aground.