Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

mrex@sap.com (Martin Rex) Tue, 28 January 2014 03:31 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 1FC151A039B for <tls@ietfa.amsl.com>; Mon, 27 Jan 2014 19:31:49 -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 yDGmR-JWb0-h for <tls@ietfa.amsl.com>; Mon, 27 Jan 2014 19:31:46 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 956801A017F for <tls@ietf.org>; Mon, 27 Jan 2014 19:31:46 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s0S3VgJZ019971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Jan 2014 04:31:42 +0100 (MET)
In-Reply-To: <CAL9PXLzGTm-3Ciyg4trja1zYEmOOJ-FTd5zfSTOg95ukpadYPw@mail.gmail.com>
To: Adam Langley <agl@google.com>
Date: Tue, 28 Jan 2014 04:31:41 +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: <20140128033141.EEEDE1ABC9@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv
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, 28 Jan 2014 03:31:49 -0000

Adam Langley wrote:
> Martin Rex <mrex@sap.com> wrote:
>> A modified extension that allows the server to continue the handshake
>> with a TLSv1.2 ServerHello, could be processed transparently within
>> the TLS client implementation and provide immediate benefits to TLS clients
>> that do not have any application-level reconnect fallback.
> 
> The ServerHello could not contain options that the ClientHello didn't
> offer. For example, AES-GCM or even ECDHE (if the client fell back to
> SSLv3). Thus an attacker could still choose important features of the
> connection.

You really do not need to curtail your imagination and creativity so
badly.

If you have an urge to resend a ClientHello with TLS extensions,
how about extending this proposal to allow the client to do this
within the handshake rather then dropping the connection like
a hot potato and expecting the application to clean up the resulting
mess with an app-supplied reconnect fallback facility?


The negotiation could work like this:

Client is performing a fallback and stripping information from
ClientHello (such as TLS extensions or certain cipher suites)
that the client would prefer to use if availabe and marks that
omission with an SCSV.

Server checks the ClientHello, recognizes the SCSV and if the
server supports features beyond those currently present in
ClientHello _and_ features which would be preferable _to_the_server_ 
(such as ECC cipher, AES-GCM cipher suites, TLS signature extension),
then the server could return ServerHello with ServerHello.cipher_suite=SCSV
and ServerHello.server_version set to the highest TLS version supported
by the server directly followed by ServerHelloDone, and upon receiving
this, the client would simply restart the Handshake with a new
ClientHello handshake message that contains all the previously omitted
stuff.

In a number of situations, the server may simply want to continue
the handshake, when the server does not support any features beyond
what is offered in that fallback ClientHello, or when the choices present
in the fallback ClientHello meet the preferences configured by the
server administrator.   i.e. when the server admin has configured
to prefer TLS_RSA_WITH_AES_128_CBC_SHA, this cipher suite is
present in the fallback ClientHello and the server has only a
single cipher suite, then it wouldn't matter when
ClientHello.client_version is only TLSv1.1 or when there are
no TLS extensions in ClientHello, and no need to suggest resending
his ClientHello to the client.

i.e. the regular full TLS handshake:

  http://tools.ietf.org/html/rfc5246#page-36

     Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

             Figure 1.  Message flow for a full handshake


the fall-forward full TLS handshake: 

     Client                                               Server

      minimal ClientHello w/SCSV    -------->
                                                      ServerHello w/SCSV
                                   <--------      ServerHelloDone
      ClientHello                   -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

             Figure 1.  Message flow for a full handshake


-Martin