Re: [TLS] Simpler backward compatibility rules for 0-RTT
David Benjamin <davidben@chromium.org> Wed, 22 June 2016 02:31 UTC
Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3559F12DF35 for <tls@ietfa.amsl.com>; Tue, 21 Jun 2016 19:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.125
X-Spam-Level:
X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbRE47NQl6Dk for <tls@ietfa.amsl.com>; Tue, 21 Jun 2016 19:31:34 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E0312DF31 for <tls@ietf.org>; Tue, 21 Jun 2016 19:31:34 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id g127so33733134ith.0 for <tls@ietf.org>; Tue, 21 Jun 2016 19:31:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fgqEnkSUHEYRpv+7H5Tkb6wgnF+Wler0HUM33OiFHIE=; b=ZZyGCaRnzlEqQFlybRVQXc4BaaTzn1KGQUvD9it0UuvS/JVqZ2DW9oA1gin89zlG+C Z7Y16L81wilStAW4+D16YIWukZwRxj23b2HR3TRm/hAwAf6Q0b3u2XDrHprH1mIiFkWp Xs7K0I8Muc6oJkdvRD1VlGKp7Vgky0w6Mj3gY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fgqEnkSUHEYRpv+7H5Tkb6wgnF+Wler0HUM33OiFHIE=; b=ZzoW+OzzZ3HMIbD907B6vD44rT+lTUbQjE/JU+vcBCxynCZhDxoa9/uBo9cWPd0eei dhREPgqlY1SedRlOIAf1NFNcvhMJroK8rDhI9TiSKA2AzCtdx6tlBVhOG8KiY1rKwH/4 l6N0I34K0XrTS1d0ruJln+Nzgpr/9zO62rbsfbE+ztnnvp3PUW6NASWPZ3x9F4ZpGgsc Hu1408qTnlcmTg2p00WOk7WKkEkRdtxp9BUBaMxW9mdpNHCxgtMF0gWHK7Df7bZdGKj2 /PdY8tSWrMnc3mSx5Y8pVBObuygCUYw5HIuWTbhUFt1H/eymYwP5dBtHop00pAttIbUM c9Ag==
X-Gm-Message-State: ALyK8tJ/aJZ0Jm13OU3BSN/X/VbZbef7aGXMKdF0du3U3me/fFr9pD335KyCx7SEsvzHafmG1W7k5t6SW88xMoHI
X-Received: by 10.36.11.84 with SMTP id 81mr10956831itd.76.1466562693342; Tue, 21 Jun 2016 19:31:33 -0700 (PDT)
MIME-Version: 1.0
References: <CABkgnnUsnz3Uh8dH=ke9uO82cgP3S7nJ0fgcs=JpsZu3qr0K0g@mail.gmail.com> <r470Ps-10115i-6FFB9306D2CD4AF69546AD05CDF750C6@Williams-MacBook-Pro.local> <CABkgnnXr_s=Y9xrn34-EUh9P1aUg0ZbeOziMgeGgosLn7ZgTdw@mail.gmail.com>
In-Reply-To: <CABkgnnXr_s=Y9xrn34-EUh9P1aUg0ZbeOziMgeGgosLn7ZgTdw@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Wed, 22 Jun 2016 02:31:22 +0000
Message-ID: <CAF8qwaCd_KPK91_77c0U_GyEEky5eo6f5cN9Ten-0ScN=uo1DQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>, Bill Frantz <frantz@pwpconsult.com>
Content-Type: multipart/alternative; boundary="001a1140c338610e3b0535d4bc6c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xamYg5nZgmha9CBfLAIYb2PZ988>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Simpler backward compatibility rules for 0-RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jun 2016 02:31:36 -0000
On Tue, Jun 21, 2016 at 8:45 PM Martin Thomson <martin.thomson@gmail.com> wrote: > On 22 June 2016 at 10:30, Bill Frantz <frantz@pwpconsult.com> wrote: > > Well, it seems like a browser could try TLS 1.3 without 0-RTT first. > > > > If it connects with 1.3 non-0-RTT, then it could mark the host as not > > supporting 0-RTT for a day or so and after that time retry to see if the > > host has been fixed. > > Yes, that is an option. Harder to manage, but certainly possible and > (overall) preferable to falling back to 1.2. > Right, that (minus the statefulness because I don't care for adding state here) was exactly my intent with the specification text. Don't change the ClientHello version and only retry with the 0-RTT data dropped. It explicitly says "It is NOT RECOMMENDED to retry the connection in response to a more generic error or advertise lower versions of TLS." The version fallback is also inevitable (unless the version negotiation is moved elsewhere), but at least we can separate the two and someday retire the version fallback half. (Also, it's unlikely, but one could also imagine that the retry switches back to hitting a 1.3-capable server. Then changing the ClientHello version will trip fallback detection and the connection will fail again. Whereas retrying with only 0-RTT off is a handshake that will work against 1.2 and 1.3 servers alike.) I don't care much about the exact distribution of MAY/SHOULD/MUST, if that's all we disagree on. If we both agree that browsers will have to fallback, I want the mechanism written down somewhere. Because it's not obvious that this fallback may be triggered without a version downgrade and without a broad trigger, both of which have been problems with the past fallbacks. (The version downgrade has clear security implications and a broad trigger means debugging harder and, worse, it hides bugs. I've seen many cases of server software shipping new code that flat-out doesn't work but fallbacks are so easy to trigger that no one noticed.) Note that, since TLS stacks typically are not in charge of creating sockets, the implementation is the same with or without the fallback. The TLS stack needs to return a very specific error code (<= 1.2 ServerHello in response to 0-RTT ClientHello) and higher-level logic can condition on it as it pleases. David
- Re: [TLS] Simpler backward compatibility rules fo… Ilari Liusvaara
- Re: [TLS] Simpler backward compatibility rules fo… Hubert Kario
- Re: [TLS] Simpler backward compatibility rules fo… Hubert Kario
- Re: [TLS] Simpler backward compatibility rules fo… Erik Nygren
- Re: [TLS] Simpler backward compatibility rules fo… Martin Thomson
- Re: [TLS] Simpler backward compatibility rules fo… Ilari Liusvaara
- Re: [TLS] Simpler backward compatibility rules fo… Watson Ladd
- Re: [TLS] Simpler backward compatibility rules fo… Martin Thomson
- Re: [TLS] Simpler backward compatibility rules fo… Martin Thomson
- Re: [TLS] Simpler backward compatibility rules fo… David Benjamin
- Re: [TLS] Simpler backward compatibility rules fo… Martin Thomson
- Re: [TLS] Simpler backward compatibility rules fo… Martin Thomson
- Re: [TLS] Simpler backward compatibility rules fo… Watson Ladd
- Re: [TLS] Simpler backward compatibility rules fo… Bill Frantz
- Re: [TLS] Simpler backward compatibility rules fo… Martin Thomson
- Re: [TLS] Simpler backward compatibility rules fo… David Benjamin
- Re: [TLS] Simpler backward compatibility rules fo… Ilari Liusvaara
- Re: [TLS] Simpler backward compatibility rules fo… Ryan Hamilton
- [TLS] Simpler backward compatibility rules for 0-… Martin Thomson
- Re: [TLS] Simpler backward compatibility rules fo… Watson Ladd
- Re: [TLS] Simpler backward compatibility rules fo… David Benjamin