On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario <hka...@redhat.com> wrote:
> On Thursday 02 June 2016 11:39:20 Yoav Nir wrote: > > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos > > > <n...@redhat.com> wrote:> > > > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote: > > >> 2% is actually pretty good, but I agree that we're going to need > > >> fallback. > > > > > > Please not. Lets let these fallbacks die. Not every client is a > > > browser. TLS 1.3 must be a protocol which doesn't require hacks to > > > operate. CBC was removed, lets do the same for insecure fallbacks. > > > > Not every client is a browser, but some are. So what does the browser > > do when a server resets the connection after seeing the ClientHello? > > > > Blank screen with a failure message? > > fallback to check if the connection failure is caused by TLSv1.3, and if > it is, display error message and put the blame squarely on the server > We browser folk hate these fallbacks just enough as much as you do, if not more. I personally spent quite a lot of time and effort getting rid of it in Chrome (and I'm happy to say, as of Chrome 50, I seem to have succeeded). I'm sure my counterparts at Mozilla went through similar pains. But reality is what it is. The Law of the Internet is the last thing that changed is blamed. We have a limited "budget" we can spend breaking things (otherwise I'd have removed almost everything by now!) and there is no chance I can break all the hosts I found. I have been reaching out to figure out the broken vendors, but this is a slow process. It will not be flushed this out anytime soon. With TLS 1.3 as it stands, I think a browser fallback in the short to medium term is a certainty. (If your clients don't need it, then by all means don't add one! I envy you.) David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
