Re: [TLS] Enforcing Protocol Invariants

[Eric Rescorla <[e-mail]>]

On Fri, Nov 9, 2018 at 10:20 AM Ryan Carboni <[e-mail]> wrote:

> Okay, a modern browser connecting to a server owned by billion dollar
> corporations are able to implement the latest version of TLS, I’ll concede
> that. Regardless, I can only underline one point: any new protocol needs to
> break both compatibility and be downgradable, and require a small amount of
> code. It probably wasn’t wrong for the average browser implementation to
> downgrade upon connection failure before, it certainly seem more sound than
> any gritty details of recent protocol design.
>
> Furthermore, TLS 1.2 is perfectly fine, and so is TLS 1.3 by everyone’s
> statements. If so, a new protocol has no need to quickly replace either one
> of them, but instead have a high likelihood of being superior and simpler,
> and performs better according to current design of the internet.
>

This thread seems like it has drifted afield of the TLS WG, which is
chartered to work on TLS.

-Ekr

And possibly list recommendations for how out of scope issues could be
> resolved in a subsection for the inevitable RFC describing it. Boot entropy
> can be solved by increasing boot times by one second. Reminders of various
> Javascript functions to ensure authenticity. Etc.
>
> Google’s idea to rush out experimental protocols looks disgusting to me.
>