Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

mrex@sap.com (Martin Rex) Mon, 29 September 2014 19:48 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 ECC7D1A9308 for <tls@ietfa.amsl.com>; Mon, 29 Sep 2014 12:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 eHU8eJtQwswM for <tls@ietfa.amsl.com>; Mon, 29 Sep 2014 12:48:47 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7131ABD3D for <tls@ietf.org>; Mon, 29 Sep 2014 12:48:46 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id C20AD6ECFD; Mon, 29 Sep 2014 21:48:44 +0200 (CEST)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id B0146419AD; Mon, 29 Sep 2014 21:48:44 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id A88F51AE89; Mon, 29 Sep 2014 21:48:44 +0200 (CEST)
In-Reply-To: <CABkgnnWo9KGMkRrmA0wkJ5Dfnzh2Vo-cveCe_UeH71F8K_4oWw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 29 Sep 2014 21:48:44 +0200
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: <20140929194844.A88F51AE89@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ruYHBKll-o9G6fHGVk_AjtGLg3s
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00
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: Mon, 29 Sep 2014 19:48:49 -0000

Martin Thomson wrote:
> 
> The draft requires that downgrade on resumption attempts (yes, you are
> completely correct) is not guarded.

Today's servers are permitted to completely ignore resumption requests
(and perform a full handshake instead) for protocol versions other than
the version that was used to create the (cached) session.  

Allowing resumption of cached sessions with different parameters
(such as a different protocol version or different cipher suite)
would look more like a server bug to me.

Or could this actually be abused as a "feature":
1. create a new TLS session with TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
   with a Windows 2008R2 Server (IIS).

2. propose resumption with the previously created session, but
   try to make server resume with TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256

for processing resumption, the key exchange portion of the cipher suite
would technically not strictly be necessary.  But the server may have
groomed his list of supported cipher suites (not having an ECDSA cert)...


-Martin