IETF Logo Mail Archive

Re: [TLS] Version negotiation, take two

Kyle Rose <krose@krose.org> Tue, 13 September 2016 16:32 UTC

Return-Path: <krose@krose.org>
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 2696612B3C0 for <tls@ietfa.amsl.com>; Tue, 13 Sep 2016 09:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=krose.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 qOSE1frp383P for <tls@ietfa.amsl.com>; Tue, 13 Sep 2016 09:32:31 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 69BA712B447 for <tls@ietf.org>; Tue, 13 Sep 2016 09:30:10 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id 11so91841301qtc.0 for <tls@ietf.org>; Tue, 13 Sep 2016 09:30:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vz9pFFo3MHnLpHKZxKmNOvC42GwN3tqKofCyW/WC1Xg=; b=V4m/jY1yiSoIv9iyp3XNlVYC0pDDJwWlZSsBEESNvqsKTSX7uyIwXYlC/4gsqLLGBY 2NQVHosOdXS9wbgropVEFthilTxdwt4qun5Wessey/6A+0B6vPf+2w9VFBArPfVj99hQ SCTLBOZNk2YaXYSsHkaw3Lts9DxluRIOchWyE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vz9pFFo3MHnLpHKZxKmNOvC42GwN3tqKofCyW/WC1Xg=; b=JGShgnFAwQuXj4tdiDjyXyktVE+zMkXnn1vRcqTFue2FVzYtH3KMI6XTzQp4RUreiv M/y7WQsLFk3VGJ3VSxoilXBGLBo64DrjAeRIYzceCtGjxoVY2lyZv2ewJn4IWF4MeDLw TgW0bqGSTXz4QJiE0ghpBQpFFljvy9kG4bAzy9OZrtXffS0LYYnwZZ5ASWDaV6DwwIhS WNMmTxyQuxpNOHarNzJc8533Oqul+MhtwLrYZN1XG5EZ/UVEYwQgKYO04xVnGn1gM8e6 gxAsw7C4BVOmrldn7Dhv+1OFqE8UKUU3X8IBmsMFBFjl22vUbefAn84ftmfR/tQy9Kc+ 4WLQ==
X-Gm-Message-State: AE9vXwNEXQdl7xDtsbt1jQX94Wqcnw6ZNeZt6LTlmhiyUWVqSAHnn9nIvTgenbQwJ9QaEoXDgnl338bYDdHsgQ==
X-Received: by 10.200.36.13 with SMTP id c13mr2055893qtc.45.1473784209520; Tue, 13 Sep 2016 09:30:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.104.18 with HTTP; Tue, 13 Sep 2016 09:30:08 -0700 (PDT)
X-Originating-IP: [2001:470:1f07:121::1007]
In-Reply-To: <CAF8qwaA86yytg29QOD_N7ARimh9QcNGU_nnr_OrxqCrvrk2MBg@mail.gmail.com>
References: <CAF8qwaA86yytg29QOD_N7ARimh9QcNGU_nnr_OrxqCrvrk2MBg@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Tue, 13 Sep 2016 12:30:08 -0400
Message-ID: <CAJU8_nWGKxC+BykU4YnqJ6TEcJVwQmL+h+DVA8UiEoN5E2=rfg@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Content-Type: multipart/alternative; boundary="001a11404b9048edfa053c662083"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4YoZTfC7FH_2RUGVs5hXkQrlaJo>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Version negotiation, take two
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: Tue, 13 Sep 2016 16:32:34 -0000

On Thu, Sep 8, 2016 at 12:04 PM, David Benjamin <davidben@chromium.org>
wrote:

> The major arguments against this change seem to be:
>
> 1. It’s inelegant to have two mechanisms.
> 2. We should fix broken servers
>

There's also:

3. Implementors will find a way to screw this up, too.

But if you follow through with your plan to have Chrome randomly add a
really high version to the list to smoke out servers that fail when they
see unsupported versions, it's plausible version intolerance could be in
the noise next time around.

If you time-limit that behavior for a particular version of Chrome (say, to
a few months), you could even have it randomly add the next version or
current version + 2 to the list to detect and report on selective
next-version intolerance. I'd say this kind of failure mode is unlikely,
but... Murphy's Law.

Kyle

v2.27.6 | Report a Bug | By Email | System Status