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

mrex@sap.com (Martin Rex) Tue, 26 November 2013 20:13 UTC

Return-Path: <mrex@sap.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 775E41ADF93 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 12:13:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-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 tQFH6BU8Zzkv for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 12:13:01 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 185D81ADF2F for <tls@ietf.org>; Tue, 26 Nov 2013 12:13:00 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAQKCwMg010868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Nov 2013 21:12:58 +0100 (MET)
In-Reply-To: <CAL9PXLyqDbOy7vEwNyJD=jwB_UD+QPn6q8a-WCfni3BwxHZT9w@mail.gmail.com>
To: Adam Langley <agl@google.com>
Date: Tue, 26 Nov 2013 21:12:58 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20131126201258.CD1E61AAF8@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
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
Reply-To: mrex@sap.com
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: Tue, 26 Nov 2013 20:13:03 -0000

Adam Langley wrote:
[ Charset UTF-8 unsupported, converting... ]
> On Mon, Nov 25, 2013 at 9:19 PM, Martin Rex <mrex@sap.com> wrote:
> > 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.
> 
> Backporting AES-GCM, ECDHE, etc all the way back to SSLv3 is a
> possibility if it comes to it.

Strictly speaking, there is no need to backport anything, if this
was implemented as an alternative fashion to negotiate the use
of TLSv1.2 protocol PDUs&semantics.

ECDHE is already allowed with TLSv1.0 and TLSv1.1, so the only thing that
is missing is permitting AES-GCM (i.e. the GenericAEADCipher PDU)
with TLSv1.0&TLSv1.1 -- which is an extremely trivial and straightforward
change -- half of the work is removing lines of the kind
  "if ( tls_version<TLS_VERSION_12 ) { goto abort_handshake; }"
in the code that implements the TLS record layer.


>
> However, it's a lot more work than the
> anti-fallback mechanisms currently under consideration so I'd want to
> exclude them first.

No, it should be negligible.  For a reasonably structured implementation
of TLSv1.2, it should be less changes than rfc5746 (renego)


> 
> I know know of a reason to believe that they would have less
> compatibility problems than an SCSV.

You're trying to mitigate the risks of reconnect fallbacks in clients,
and perpetuate the reconnect fallbacks, where as the correct fix is to
obviate the reconnect fallbacks.  Making AES-GCM and ECDHE more
backwards-interop friendly will also allow clients that do not
implement reconnect fallbacks, to use these features (=a reasonable
subset of them).


-Martin