4 ms·

>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 a

>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
    > 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. Your "solution" of just breaking things while declaring this "doesn't have any compatibility problems" is not a solution people are going to accept. It genuinely doesn't matter that you think it'd be a great idea, not the tiniest bit, since it would see no adoption. TLS 1.3 did not take this "backwards compatibility at all cost" approach you describe. On the contrary, it was engineered very carefully to work _around_ middleboxes. The protocol is untidy as a result, with extraneous compatibility fields, but the cryptography remains as intended. But you've not addressed that at all since your entire basis is "From what I've read a lot of the issues is the complexity of the standard itself". Again, this issue you're reading about today is NOT a problem with TLS 1.3, and would not have been fixed by any changes to TLS 1.3 or imaginary alternatives to TLS 1.3 _unless_ as a side effect they prohibited falling back to earlier versions, something you can already choose to do if that's what you want (you do not).
    - pedrocr 8y ago
      >It genuinely doesn't matter that you think it'd be a great idea, not the tiniest bit, since it would see no adoption. The discussion around TLS 1.3 delays included plenty of people that also thought middleboxes should not be enabled. If a standard that broke compatibility with them completely would be adopted is an open question. >TLS 1.3 did not take this "backwards compatibility at all cost" approach you describe. On the contrary, it was engineered very carefully to work _around_ middleboxes. The protocol is untidy as a result, with extraneous compatibility fields, but the cryptography remains as intended. The second part contradicts the first. The standard has had to be made more complex to allow for the backwards compatibility and that's a future liability. We've had other holes in TLS from these extra complexities that are completely unneeded. >Again, this issue you're reading about today is NOT a problem with TLS 1.3 Again that's not my point at all. I'm not discussing today's issue in particular. I'm referring to the fact that we keep finding bugs in TLS consistently. I was wondering if we were at the point were a clean slate would reduce this. I've made that point, someone else has pointed out to an experiment in doing just that, maybe someday we'll get a full test. You're dismissal of the actual question as if it's invalid is just being unpleasant without being helpful.

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
  > 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. Your "solution" of just breaking things while declaring this "doesn't have any compatibility problems" is not a solution people are going to accept. It genuinely doesn't matter that you think it'd be a great idea, not the tiniest bit, since it would see no adoption. TLS 1.3 did not take this "backwards compatibility at all cost" approach you describe. On the contrary, it was engineered very carefully to work _around_ middleboxes. The protocol is untidy as a result, with extraneous compatibility fields, but the cryptography remains as intended. But you've not addressed that at all since your entire basis is "From what I've read a lot of the issues is the complexity of the standard itself". Again, this issue you're reading about today is NOT a problem with TLS 1.3, and would not have been fixed by any changes to TLS 1.3 or imaginary alternatives to TLS 1.3 _unless_ as a side effect they prohibited falling back to earlier versions, something you can already choose to do if that's what you want (you do not).
  - pedrocr 8y ago
    >It genuinely doesn't matter that you think it'd be a great idea, not the tiniest bit, since it would see no adoption. The discussion around TLS 1.3 delays included plenty of people that also thought middleboxes should not be enabled. If a standard that broke compatibility with them completely would be adopted is an open question. >TLS 1.3 did not take this "backwards compatibility at all cost" approach you describe. On the contrary, it was engineered very carefully to work _around_ middleboxes. The protocol is untidy as a result, with extraneous compatibility fields, but the cryptography remains as intended. The second part contradicts the first. The standard has had to be made more complex to allow for the backwards compatibility and that's a future liability. We've had other holes in TLS from these extra complexities that are completely unneeded. >Again, this issue you're reading about today is NOT a problem with TLS 1.3 Again that's not my point at all. I'm not discussing today's issue in particular. I'm referring to the fact that we keep finding bugs in TLS consistently. I was wondering if we were at the point were a clean slate would reduce this. I've made that point, someone else has pointed out to an experiment in doing just that, maybe someday we'll get a full test. You're dismissal of the actual question as if it's invalid is just being unpleasant without being helpful.