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

Adam Langley <> Fri, 06 December 2013 18:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 45BA81ADE84 for <>; Fri, 6 Dec 2013 10:33:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.38
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RS183HgMoqgk for <>; Fri, 6 Dec 2013 10:33:29 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c01::22b]) by (Postfix) with ESMTP id EE6891AC828 for <>; Fri, 6 Dec 2013 10:33:28 -0800 (PST)
Received: by with SMTP id pa12so1202309veb.16 for <>; Fri, 06 Dec 2013 10:33:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=H4v+JDcWcG3UfFF+Oks1n3R55IkILfEUJxzeQj/CQF4=; b=B65vGAd4gnnriqS43hQCyEqAomCUhRRKMZWiURfm2PnSWi1axwj/hYF6CE+WPukJrn xjbAVOHnF+o5OyPyL2VvXmsOiZzSuide6mQTZaMulzDxzyylGsDsTJVmNwysZgXg/rs3 pP5uBC5SKYVCy9KWzEbTpykkukz0ZFauNJSA/ekyLhv4MZBCDacuq1aPtSx3QxSxITdk jm5jYfFKuQyuQxDv4lgivabO4MKcfq00PBYbwQ62BbpeR0Ool5g0YFsoqk7FJOXxqYvU jiGUNX2nNdp4bhGxjKb9PafnhVr7We9ehbO1QmINp0vwqJ8dIdrv1MY+YuDwZKHqjGII sFkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=H4v+JDcWcG3UfFF+Oks1n3R55IkILfEUJxzeQj/CQF4=; b=fwC5CiyepPbdhIcnZaD5cLakxg4X+Ylv8cQcAfS3YAKj0bjco0tVDSNIomEXydwBxq Vwl//++p3BT9JV22QWL5uh5y0CjggjzKgkQaKAjlAo0M0shBDYbLPqZWY4rboQglattT f+zuherv/LJrruz9v1koGepXc7j0V0t71zcwNykN7fPAGVVEYNRg0CGMi208aPLgu+K4 EliQfW4vglg8cXg2uDf3d7EfQpT2EaHlx5J08FbbwX7qy94q7kk2b1TcUHagKf1lWpGb CKakpTp+8KncWdEz715Zk7uEHM9tuwc/EeYrnCOM7sTYoCw5LEP4ZO9q/0aowbpWXQXy mhgQ==
X-Gm-Message-State: ALoCoQluelO19dgd8KgNLEd6vg+hMii/9hcC1B48q5il6y44Ge0QYdw3zOxIvVaL3Hddsbc0fJFfvtX60Z+OPs1zZC5VwT5nixAg36sBhtJoR28VZ4RvpnwfVXvYYUo55AZjl54MM1+YMXFnQZ986GRgkchOBRsRRcYmqwJNBiR6P3yOxAPJpsmazkaOjIUhMGL8pTynGmSQ
X-Received: by with SMTP id xq4mr1835331vcb.57.1386354804757; Fri, 06 Dec 2013 10:33:24 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 6 Dec 2013 10:33:04 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Adam Langley <>
Date: Fri, 6 Dec 2013 13:33:04 -0500
Message-ID: <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Dec 2013 18:33:30 -0000

On Fri, Dec 6, 2013 at 1:25 PM, Martin Rex <> wrote:
> For this feature to work at all, the prerequisite is that both communication
> peers must be updated.  When looking at a protocol feature that requires
> both communication peers to be updated as a prerequisite, wouldn't it be
> preferable to fix those protocol features of SSL/TLS that we deem necessary
> for reliable security to become negotiable even in the "most conservative"
> ClientHello that clients are willing to fallback to?

Fallback behaviour is needed for wide variety of buggy servers,
including those that are intolerant to unknown extensions.

I don't believe that there's a ClientHello format that is both devoid
of compat issues and sufficiently expressive to be able to negotiate
what we need now and in the future.