4 ms·

> It's like CADT but with cryptography. TLS is 25 years old now. CADT is not a fair criticism when more than the lifetime of a whole teenager has elapsed. At s

> It's like CADT but with cryptography. TLS is 25 years old now. CADT is not a fair criticism when more than the lifetime of a whole teenager has elapsed. At some point building a second system is worth it. >You get to learn basically the same lessons about agility everybody else did, the same way everybody else learned them. Brilliant. We would also get to throw away a bunch of stuff we already know was a very bad idea. There has to be a limit somewhere to that tradeoff. At some point starting fresh allows you to throw away enough crap that you come out ahead. > If you say "Well, if we can't do shiny I guess we'll do the old thing" then you lose immediately, that's the thrust of their TLS 1.3 example, both client and server want to talk TLS 1.3 which isn't vulnerable - but the attacker abuses the fact that they're willing to talk TLS 1.2 instead. There is no difference there between changing from 1.2 to 1.3 and from 1.2 to ShinyNewStuff. My point is that from what I've read we've learned enough that we could design something better than TLS if we started fresh, so we could do TLS1.2->ShinyNewStuff instead of TLS1.2->TLS1.3 and get some advantages. The downgrade attacks are present in both cases until you eventually discontinue 1.2. >If you don't want to do RSA kex in your own system where you control all servers and clients, don't do RSA kex. One of the things we've learned over the last 25 years is that having optionally insecure ways to use security standards is a very bad idea. So the fact that configuring TLS well enough is feasible is part of the problem, not the solution. That's the kind of thing we could potentially fix.

tialaramex 8y ago
> TLS is 25 years old now. The on-the-wire protocol has some faint resemblance but the actual technology between SSL 2.0 and TLS 1.3 are utterly different. The original Bell phone system where you have to talk to an operator and say "Give me 4235 please", and a modern iPhone, are also utterly different - but every step along the way was achieved by backwards compatibility and that meant some compromises. So the iPhone still has "phone numbers" even though you probably rarely use them for anything. That's all that was going on in TLS. The "start fresh" you were originally asking for involves _throwing away_ that compatibility to get "some advantages". I explained why TLS doesn't do that. The feeling that surely starting over would help is _exactly_ CADT even if you're not a teenager. You absolutely can have those "some advantages" if you don't want backwards compatibility. But it's not obvious why you'd rewrite TLS rather than just use TLS in this case and refuse to downgrade below TLS 1.3. What happens when TLS 1.4 has even more "advantages" ?
- pedrocr 8y ago
  >but every step along the way was achieved by backwards compatibility and that meant some compromises This is not a good analogy. The phone system has thrown away plenty of standards as well. Throwing away TLS for something else doesn't have any compatibility problems on the web. There is no difference in compatibility between doing 1.2->ShinyNew and doing 1.2->1.3. Maybe we can do enough within just TLS versions to fix the flaws. Maybe doing 1.4 with a much stricter set of conditions is possible and so we should keep the base. But for some reason that keeps not happening and insecure options like these still exist. But the compatibility argument doesn't exist. The end user would not notice anything.
  - tialaramex 8y ago
    > Throwing away TLS for something else doesn't have any compatibility problems on the web No. Even just small changes to TLS resulted in massive compatibility mishaps. There was about a year delay in the TLS 1.3 process while they worked around things like this. > But for some reason that keeps not happening and insecure options like these still exist. Unfortunately you don't even understand enough about this topic to have noticed that the article is specifically mentioning a downgrade because the "insecure options like these" do not exist in TLS 1.3. Insisting that problems you don't understand will go away if we just rewrite everything again from scratch is even closer to CADT than the anti-agility enthusiasts.
    - pedrocr 8y ago
      >Even just small changes to TLS resulted in massive compatibility mishaps. There was about a year delay in the TLS 1.3 process while they worked around things like this. Those are part of the problem we should be solving. Delaying TLS 1.3 to enable middleboxes is precisely the kinds of things we should be throwing away from any standard. That TLS 1.3 was close enough to 1.2 for broken middleboxes to show how broken they are is an example of how backwards compatibility at all cost bites you, and yet you are using it to claim the opposite. It's perfectly possible that all that needs to be done for TLS to stop being a continuous problem is a sane TLS 1.4. But I'd like to see an actual argument for what that would look like instead of you just insulting me without adding anything to the discussion.

tialaramex 8y ago

> TLS is 25 years old now. The on-the-wire protocol has some faint resemblance but the actual technology between SSL 2.0 and TLS 1.3 are utterly different. The original Bell phone system where you have to talk to an operator and say "Give me 4235 please", and a modern iPhone, are also utterly different - but every step along the way was achieved by backwards compatibility and that meant some compromises. So the iPhone still has "phone numbers" even though you probably rarely use them for anything. That's all that was going on in TLS. The "start fresh" you were originally asking for involves _throwing away_ that compatibility to get "some advantages". I explained why TLS doesn't do that. The feeling that surely starting over would help is _exactly_ CADT even if you're not a teenager. You absolutely can have those "some advantages" if you don't want backwards compatibility. But it's not obvious why you'd rewrite TLS rather than just use TLS in this case and refuse to downgrade below TLS 1.3. What happens when TLS 1.4 has even more "advantages" ?

pedrocr 8y ago
>but every step along the way was achieved by backwards compatibility and that meant some compromises This is not a good analogy. The phone system has thrown away plenty of standards as well. Throwing away TLS for something else doesn't have any compatibility problems on the web. There is no difference in compatibility between doing 1.2->ShinyNew and doing 1.2->1.3. Maybe we can do enough within just TLS versions to fix the flaws. Maybe doing 1.4 with a much stricter set of conditions is possible and so we should keep the base. But for some reason that keeps not happening and insecure options like these still exist. But the compatibility argument doesn't exist. The end user would not notice anything.
- tialaramex 8y ago
  > Throwing away TLS for something else doesn't have any compatibility problems on the web No. Even just small changes to TLS resulted in massive compatibility mishaps. There was about a year delay in the TLS 1.3 process while they worked around things like this. > But for some reason that keeps not happening and insecure options like these still exist. Unfortunately you don't even understand enough about this topic to have noticed that the article is specifically mentioning a downgrade because the "insecure options like these" do not exist in TLS 1.3. Insisting that problems you don't understand will go away if we just rewrite everything again from scratch is even closer to CADT than the anti-agility enthusiasts.
  - pedrocr 8y ago
    >Even just small changes to TLS resulted in massive compatibility mishaps. There was about a year delay in the TLS 1.3 process while they worked around things like this. Those are part of the problem we should be solving. Delaying TLS 1.3 to enable middleboxes is precisely the kinds of things we should be throwing away from any standard. That TLS 1.3 was close enough to 1.2 for broken middleboxes to show how broken they are is an example of how backwards compatibility at all cost bites you, and yet you are using it to claim the opposite. It's perfectly possible that all that needs to be done for TLS to stop being a continuous problem is a sane TLS 1.4. But I'd like to see an actual argument for what that would look like instead of you just insulting me without adding anything to the discussion.