IETF Logo Mail Archive

Re: [TLS] An SCSV to stop TLS fallback.

Adam Langley <agl@google.com> Wed, 27 November 2013 15:28 UTC

Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA4D1AE090 for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 07:28:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level:
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
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 DUd2LH9i4AuL for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 07:28:43 -0800 (PST)
Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF1C1AE088 for <tls@ietf.org>; Wed, 27 Nov 2013 07:28:43 -0800 (PST)
Received: by mail-vb0-f43.google.com with SMTP id q12so4907615vbe.2 for <tls@ietf.org>; Wed, 27 Nov 2013 07:28:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7zibGCD3eSToiXYhx9S3wrX1Srp57mzwPh4X6DXeCc0=; b=oRCc/Uvb2auZ79iuTWCojJhcdPbux5S5Y2o0eLC4fy3OhVj62ckM8qK8TSFUthC2FA Vv974b7h2nRqO0T22jJU0ZQcXw3LzpHnWBEGGywOiOr/M1ttIRKVMXYzR8aaLEnAPTIS zCl842uJVksujV+cybiyzi9/qAC3vcqgvXnHx4p4aID7Ora3TuNGc+XbhG7A79ysj97c QWqXDqR81Cy5hJD7Bg8MA2y3tTUgonGK8qNL3REWrQE8/bDVIO0y6aEUPdiQs+zNPQY2 oeSWCzUMyOx1GDE6Ghg0AqXJyGPtqFGmjkbm8fLvH8loakQOi5tJ0Cp4PfieVq22QTM4 2ASg==
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:content-type; bh=7zibGCD3eSToiXYhx9S3wrX1Srp57mzwPh4X6DXeCc0=; b=X2v8Lb/9tR/hsRXcNa0J1jrI8zdILENNDFJK9CmC2rQM+5yqWqFx3VbQKfePwK88FM UWCqHf4dAH2HPxI3+dR+dz/poq9PNkn8Q7XGP9AoMeBO+HgKkviJ1QqRGp6v444bd7IN 9Ht+uu8hpeqAvQ6orIstPD7kkeiVCCWm4uBMbAuU6YrLD1mUXpe6ub2kIqbICX5cL1iX DaC6y9C3PB1eEbccp6xPrYhvC1te+ejWdaeFDXxLtQwdiCBcqpjECulRKcKGfXqBTAkH AoRl12xYEH5XLYe+YAZih4g+nRaXmBwOB09rOFcXeZwgEiNjccux6n8Y+EKLMpue/gHl lPSg==
X-Gm-Message-State: ALoCoQnkv6m0TlWCEty9qfwv1tbadTSc+UAmeKeu9qlXgthdKVEA7LNxidq+3sOu6QSaOkRgKa60AnWtReRB3WwDEgcJEvb4k09jngBoUsPv0CdpQQGzwirM9skBEtRPPxTJFEi248JCAVCpyULlLD8GPHbrzovFjGEEJjIwiy6q7wcd0tlUFLM4ks6Gg6otbOA7SCDDJnFB
X-Received: by 10.52.28.78 with SMTP id z14mr81466vdg.54.1385566122614; Wed, 27 Nov 2013 07:28:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Wed, 27 Nov 2013 07:28:22 -0800 (PST)
In-Reply-To: <CAFewVt42cSELgfiDa2M7OWwBcpEgcqNzHL4oAEjJ_3GJ8TEPrg@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CAFewVt42cSELgfiDa2M7OWwBcpEgcqNzHL4oAEjJ_3GJ8TEPrg@mail.gmail.com>
From: Adam Langley <agl@google.com>
Date: Wed, 27 Nov 2013 10:28:22 -0500
Message-ID: <CAL9PXLxjFT=QtMj3GNsei=OPJptt=q3M9Ai4arARjE2gfnHMkA@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: text/plain; charset="UTF-8"
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 27 Nov 2013 15:28:44 -0000

On Tue, Nov 26, 2013 at 8:42 PM, Brian Smith <brian@briansmith.org> wrote:
> these fallback connections add a lot of
> latency. If we attempt a fallback connection in response to a
> connection reset, and we receive an inappropriate_fallback alert, then
> we'd have to make yet *another* connection without the fallback.

I didn't have that in mind. In the code as I currently have it
written, an inappropriate_fallback doesn't trigger an "upgrade".
Rather the original error code that triggered the downgrade is
remembered and returned.

So the connection might go: TLS 1.2, connection reset; fallback to TLS
1.1, inappropriate_fallback; fail the connection with a connection
reset error.

We don't retry HTTP connections, after all.


Cheers

AGL

v2.23.0 | Report a Bug | By Email