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

Adam Langley <agl@google.com> Fri, 06 December 2013 18:33 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 45BA81ADE84 for <tls@ietfa.amsl.com>; Fri, 6 Dec 2013 10:33:30 -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 RS183HgMoqgk for <tls@ietfa.amsl.com>; Fri, 6 Dec 2013 10:33:29 -0800 (PST)
Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id EE6891AC828 for <tls@ietf.org>; Fri, 6 Dec 2013 10:33:28 -0800 (PST)
Received: by mail-ve0-f171.google.com with SMTP id pa12so1202309veb.16 for <tls@ietf.org>; Fri, 06 Dec 2013 10:33:24 -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=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; 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=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 10.221.66.132 with SMTP id xq4mr1835331vcb.57.1386354804757; Fri, 06 Dec 2013 10:33:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Fri, 6 Dec 2013 10:33:04 -0800 (PST)
In-Reply-To: <20131206182527.98EA51AB3C@ld9781.wdf.sap.corp>
References: <CADMpkcKGs_=Skd2_NzdyNvQB2WachTtBGNPx+5QHxwRhQ7Ln_w@mail.gmail.com> <20131206182527.98EA51AB3C@ld9781.wdf.sap.corp>
From: Adam Langley <agl@google.com>
Date: Fri, 6 Dec 2013 13:33:04 -0500
Message-ID: <CAL9PXLxD=JCZCkvAHgoENZj_Vr-HQB9tCQd7QkrQUx5LL1B_BQ@mail.gmail.com>
To: mrex@sap.com
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: Fri, 06 Dec 2013 18:33:30 -0000

On Fri, Dec 6, 2013 at 1:25 PM, Martin Rex <mrex@sap.com> 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.


Cheers

AGL