3 ms·

> but I refuse to let anybody know that I want to communicate with Bob That's not the problem though. You're not trying to stop an eavesdropper knowing you're

by gnode 8y ago

> but I refuse to let anybody know that I want to communicate with Bob That's not the problem though. You're not trying to stop an eavesdropper knowing you're communicating with a particular server, but rather which hostname you're talking to them as. To extend the Bob analogy; you're not trying to hide that you're communicating with Bob, but that you're speaking to each other as members of Fight Club. It's certainly not impossible, although overcoming issues of scaling or increased handshake round trips is a difficulty.

tialaramex 8y ago
You say "difficulty", the evidence seems to suggest impossibility. I am 100% certain that if you have an actual plan for how to do this without an extra round trip the TLS WG wants to hear about it (but please read the draft with the problem statement first so that you don't embarrass yourself and propose something that doesn't actually solve the problem) In order to be sure we're talking to Bob, so that it's OK if Bob knows we want his Fight Club certificate, I think we have to incur an extra round trip while we obtain the proof he's Bob and send back the request for Fight Club. If we try to skip that step, Mallory simply interposes, we send our message to Mallory, believing she is Bob, and she reads it to determine we want Fight Club, we are undone. So we have to wait until Bob proves his identity, and only then reveal that we wanted Fight Club.
- gnode 8y ago
  Forgive me if there's some flaw I've overlooked in this approach, but couldn't you use DNS to aid in this? I.e. add Bob's public key to the DNS for fight.club which you get for free in round trips, as you're resolving the A & AAAA records anyway. You then encrypt the SNI asking for fight.club (along with a random nonce) with Bob's pubkey. Of course, this approach would require the DNS record is authenticated, so DNSSEC is a must, added to which the DNS resolution must be encrypted, so DNS over HTTPS, DNSCurve, etc.
  - tialaramex 8y ago
    After some thought I agree with you that this can work, if you have encrypted DNS and DNSSEC in play. I am of course not a world-renowned expert so maybe we both overlooked something. Two small problems I will mention, one of which I'm sure you already know: First, encrypted DNS and DNSSEC are not yet widely deployed, so this isn't the silver bullet many people expected of Encrypted SNI. Second, for an endpoint which has many unrelated names and certificates - which is the case where encrypted SNI is gaining us a clear security benefit given our packets must have a plaintext IP destination - now they need to try every possible private key to see if they can open our encrypted SNI. This might be a very considerable burden.
    - gnode 8y ago
      > now they need to try every possible private key to see if they can open our encrypted SNI. The idea was to have a single common introductory keypair which all tenants publish to their DNS, in order to encrypt the SNI. That way there is no need to try multiple private keys. The lack of DNSSEC deployment is an issue, although there's nothing to stop such schemes being employed on an opportunistic basis. However, when DNSSEC is available for a domain, the scheme should be enforced to prevent a MITM attack.

by gnode 8y ago

tialaramex 8y ago

You say "difficulty", the evidence seems to suggest impossibility. I am 100% certain that if you have an actual plan for how to do this without an extra round trip the TLS WG wants to hear about it (but please read the draft with the problem statement first so that you don't embarrass yourself and propose something that doesn't actually solve the problem) In order to be sure we're talking to Bob, so that it's OK if Bob knows we want his Fight Club certificate, I think we have to incur an extra round trip while we obtain the proof he's Bob and send back the request for Fight Club. If we try to skip that step, Mallory simply interposes, we send our message to Mallory, believing she is Bob, and she reads it to determine we want Fight Club, we are undone. So we have to wait until Bob proves his identity, and only then reveal that we wanted Fight Club.

gnode 8y ago
Forgive me if there's some flaw I've overlooked in this approach, but couldn't you use DNS to aid in this? I.e. add Bob's public key to the DNS for fight.club which you get for free in round trips, as you're resolving the A & AAAA records anyway. You then encrypt the SNI asking for fight.club (along with a random nonce) with Bob's pubkey. Of course, this approach would require the DNS record is authenticated, so DNSSEC is a must, added to which the DNS resolution must be encrypted, so DNS over HTTPS, DNSCurve, etc.
- tialaramex 8y ago
  After some thought I agree with you that this can work, if you have encrypted DNS and DNSSEC in play. I am of course not a world-renowned expert so maybe we both overlooked something. Two small problems I will mention, one of which I'm sure you already know: First, encrypted DNS and DNSSEC are not yet widely deployed, so this isn't the silver bullet many people expected of Encrypted SNI. Second, for an endpoint which has many unrelated names and certificates - which is the case where encrypted SNI is gaining us a clear security benefit given our packets must have a plaintext IP destination - now they need to try every possible private key to see if they can open our encrypted SNI. This might be a very considerable burden.
  - gnode 8y ago
    > now they need to try every possible private key to see if they can open our encrypted SNI. The idea was to have a single common introductory keypair which all tenants publish to their DNS, in order to encrypt the SNI. That way there is no need to try multiple private keys. The lack of DNSSEC deployment is an issue, although there's nothing to stop such schemes being employed on an opportunistic basis. However, when DNSSEC is available for a domain, the scheme should be enforced to prevent a MITM attack.