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

Watson Ladd <watsonbladd@gmail.com> Wed, 27 November 2013 01:13 UTC

Return-Path: <watsonbladd@gmail.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 0F9FA1ADF7F for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:13:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 CVrMLOLFzhlJ for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:13:41 -0800 (PST)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id E181B1ADEA1 for <tls@ietf.org>; Tue, 26 Nov 2013 17:13:40 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id hq4so6514409wib.14 for <tls@ietf.org>; Tue, 26 Nov 2013 17:13:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=05nR7bDgKzzbRK3HIJr09aYLpqXtn2qhJq1cHJATOto=; b=C/eul6o95ZkHJvA9lrLAlHuHmBUBUN00Fa2mslbXx0CnHFNMj/f3x5w6iPEZxjAkes uW6IMrhzNk5abuDMdxo93Yqrsl+54yEm3UQbOEphldSfHvQx2/agQyvhn9ZLZPREzHBg FyBZ3Xmdj8iUz6XdiscjcCKoMBa7gfdCGcUWqD2ZeY/pyNubkU88LSNSG/TevQ2VWvkN +EKfrknttWRRdM4SHb0mqoYyoiwDqSymi7mrexysicS6+FMtEJy9gcdC1w5oxSbxn3a7 iC+ZkuLbhhG9/aGFlEh5pUbaNgTbmP4bDVbZSXkFKRSlR57A6tsVrHLAJ0pi/SaScuzc jOlQ==
MIME-Version: 1.0
X-Received: by 10.194.1.139 with SMTP id 11mr12420913wjm.33.1385514820222; Tue, 26 Nov 2013 17:13:40 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Tue, 26 Nov 2013 17:13:40 -0800 (PST)
In-Reply-To: <20131126021923.E56981AAF0@ld9781.wdf.sap.corp>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <20131126021923.E56981AAF0@ld9781.wdf.sap.corp>
Date: Tue, 26 Nov 2013 17:13:40 -0800
Message-ID: <CACsn0cksaErqtDZtfvoPEJtZfPRXrUQsp_YH7tiOsbnOizZs5g@mail.gmail.com>
From: Watson Ladd <watsonbladd@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: Wed, 27 Nov 2013 01:13:43 -0000

On Mon, Nov 25, 2013 at 6:19 PM, Martin Rex <mrex@sap.com> wrote:
> Adam Langley wrote:
>> Sad as it is, in order to work on public Internet all browsers
>> implement TLS fallback: in the event of a handshake failure they will
>> retry the connection with a lesser SSL/TLS version.
>>
>> This means that an active attacker can disable AES-GCM support and,
>> ultimately, ECDHE if they push the browser back to SSLv3. It would be
>> good to finally do something about this.
>>
>> Thus I'd like to propose the design of an SCSV with which we can move forward:
>>
>>   In the event that a client is making a fallback connection, it
>> includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
>> current server which sees this cipher suite in a ClientHello SHOULD
>> return a fatal alert, inappropriate_fallback (86) and abort the
>> connection.
>
>
> We keep this proposals for newly creating interop problems keep
> coming up on this list?
Why didn't you complain before we had the problems?
How does AGL's proposal introduce interop issues?
I agree this is important to avoid in the future, but I don't think
this proposal
causes any more problems.
>
> How about instead fixing the negotiation so that AES-GCM&AES-CCM
> can be sent in whatever ClientHello there is (including SSLv2)
> and an additional SCSV to signal availability of a specific subset of
> ECDHE that can be used without a TLS ECC extension, such as the subset
> that is supported by Windows 7+?
SSLv2.0 is irredeemably broken.
SSLv3.0 doesn't use HMAC, so the decision was made to go to TLS 1.0, rather than
negotiate an extension. It also only supports SHA1 and MD5. The
allowable key exchanges
also changed. Implementing this in a backwards-compatible manner would be hard.
Why the SSL structure was kept around is beyond me: surely someone in
1999 should have
understood the cryptographic issues inherent in the design. (Actually
someone did, namely Rogaway, and everyone ignored him).
But yes, to the extent we can make future changes backwards compatible
we should.
>
>
> If there is a problem in negotiating what _we_want_to_do_, because the
> installed base does not like the kind of negotiation that was originally
> proposed to be used, then the pragmatic engineering approach will be
> to define an alternative negotiation of at least a useful subset
> that will be compatible with the installed base, and which will not need
> to be stripped from a "conservative fallback handshake" -- and therefore
> will be resilient to downgrade attacks, and cope with retarded middle boxes.
>
>
> -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin