Re: [TLS] Simpler backward compatibility rules for 0-RTT
Erik Nygren <nygren@gmail.com> Thu, 23 June 2016 08:18 UTC
Return-Path: <nygren@gmail.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 7C3D612D598 for <tls@ietfa.amsl.com>; Thu, 23 Jun 2016 01:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 S0UOD_-2IFi8 for <tls@ietfa.amsl.com>; Thu, 23 Jun 2016 01:18:28 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 D0F6912D52D for <tls@ietf.org>; Thu, 23 Jun 2016 01:18:28 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id g127so64231617ith.0 for <tls@ietf.org>; Thu, 23 Jun 2016 01:18:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc; bh=Yxah6TCA3tkDH+9nyZmB4ajUwZ3yB5qwft0CqcF/mjE=; b=Yo7pCjIlcAZX1g3sPArRumXP+nWlkbvJV2+0bZdXy1cPUFhNkojnx6TSKN2WPnD7E4 S6H+snz80UC2YEFy+ZwMDakfRrA2h53GPNPV9ds3DWFhTtBU8lCcNlkDVUEcD2F+hQVv fhu6N8nrd7eG2lv09ghOwRmgvgvZL1pKVNU0/+lgRRk9PXdBdLQhZ0w73t2wrrhOTtHc G0DIJoepUujAjErLm9Sw4kgFKwyduWOaennM8cBNoKpuPEPLgY4fY78ditfJZf/5pVto ekDn+sHk570Y7kxaZJfWoq812M4BGMUHxnS+rhbhXlmgyi2y7Bf5oYaPrXHmrOWYUwau CoBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=Yxah6TCA3tkDH+9nyZmB4ajUwZ3yB5qwft0CqcF/mjE=; b=Oehof7kY+vYXW+l5Fn0hI80yxRfMF8cX0wfndkdOxIsmPiYyeioV/o4cT2OhzWijak 30MTgoiOqrfERYumzBExLFNKRfh6z5J8SjerCgGxjRfJlieNGl+dbXBNh6fC1y5kyVj3 cVbSjstfJ9VzEQ+O4dLfkz0ZSwRBKlsavbBUCIb7F3MCl72H1kilqmL9ZvCq6e2qafqg wnqsfoq0PEGo1mdbglRR+NRfwJB4BAVWO36vQUkIWTWzyHsZX1H9h6+3R/bpbFygei5I 3NRPzEcaKbtfVffsUo2QA2n3qK8HTumrrqDcYpzV6LZR/1oXGkO4yFK9U8RjAU579pwk xIXQ==
X-Gm-Message-State: ALyK8tIK+BA6zB7VOfvwNpDv9rfePkSoBSYnMD5s2UqUpaOKozQxMvcsRAnHvUdIZoKfeuwWIWXHojGTqeujmQ==
MIME-Version: 1.0
X-Received: by 10.36.44.200 with SMTP id i191mr18157751iti.99.1466669908072; Thu, 23 Jun 2016 01:18:28 -0700 (PDT)
Received: by 10.107.128.65 with HTTP; Thu, 23 Jun 2016 01:18:27 -0700 (PDT)
Received: by 10.107.128.65 with HTTP; Thu, 23 Jun 2016 01:18:27 -0700 (PDT)
In-Reply-To: <CAKC-DJgKkP4rtS9Z_SrM-ibbOMZxGKsz3522vm0xpfEOMnkV6A@mail.gmail.com>
References: <CABkgnnVgD2rTgdWkTEhd1b6CUpj_i7wD4-_E2Dd2=nJf1eW5RQ@mail.gmail.com> <CAJ_4DfQ1ttyF0z9vwmuq-yEvbHrh+93k3rkJ7gzgDQZoQnuUpQ@mail.gmail.com> <20160621175413.GB2989@LK-Perkele-V2.elisa-laajakaista.fi> <CAF8qwaCQSERcYNr42=DB-ZcBQde5qkrk8R_AD2qnnEsdwi7NoA@mail.gmail.com> <CABkgnnUsnz3Uh8dH=ke9uO82cgP3S7nJ0fgcs=JpsZu3qr0K0g@mail.gmail.com> <CACsn0c=EcXyrB83HnSbWWrQG5T2AjDQdG2D408qiDjqXEY3Htg@mail.gmail.com> <CABkgnnXdFJHEA60x-KObf_dT1aS5ys49mO4Uffmmw4sKwNX8Yg@mail.gmail.com> <CACsn0cn=B36Tn0O=RaUebAtjqxRVcQFD+kWyFVfXELiHY2ux2w@mail.gmail.com> <CABkgnnV4+_TvAGQ2SYWi+REnxSLgV+D_H3gKw0Rz6fswqd8iiA@mail.gmail.com> <CAKC-DJj5oxgs3VqP4+e7tS_u1WeeyQWq6SCH16evMkdoDTRyNw@mail.gmail.com> <CAKC-DJgKkP4rtS9Z_SrM-ibbOMZxGKsz3522vm0xpfEOMnkV6A@mail.gmail.com>
Date: Thu, 23 Jun 2016 10:18:27 +0200
Message-ID: <CAKC-DJj6p7RwUEO+vXG6Wst1cY4y_gq3=KSqoSi8GxFNjfLauQ@mail.gmail.com>
From: Erik Nygren <nygren@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="001a113f9f6cdfa35c0535edb231"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/G9Aab3ZwXk2dC3RN6iAIGNfxmfE>
X-Mailman-Approved-At: Sat, 25 Jun 2016 06:11:32 -0700
Cc: 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
Reply-To: erik@nygren.org
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: Thu, 23 Jun 2016 08:18:31 -0000
There are also very common cases of using multiple CDNs or server farms with different capabilities but with the same host name, or of switching a live site between platforms. As others have mentioned, the behaviors need to be well defined and result in extra rtt rather than hard failure to allow 0rtt to be safely deployable. - Erik On Jun 22, 2016 5:58 AM, "Martin Thomson" <martin.thomson@gmail.com> wrote: On 22 June 2016 at 12:01, Watson Ladd <watsonbladd@gmail.com> wrote: > Why isn't 0-RTT an extension in the Client Hello to deal with this? You can't stream extensions, which unfortunately is required given how most software interacts with their TLS stack. Let's be clear, the actual risk we're talking about is pretty-much confined to screw-ups. The deployment screwup where you left one server speaking TLS 1.2 somewhere before turning 0-RTT on; and TLS MitM, which calling a screw-up might be too positive a statement. Of course, David is right that screw-ups like this are too common for us to do nothing about them. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- 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