Re: [TLS] Quest for Unified Solution to TLS Renegotiation

Martin Rex <mrex@sap.com> Wed, 25 November 2009 22:06 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235323A6B89 for <tls@core3.amsl.com>; Wed, 25 Nov 2009 14:06:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.166
X-Spam-Level:
X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3kHpmKMMOhN for <tls@core3.amsl.com>; Wed, 25 Nov 2009 14:06:04 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 09C513A6B45 for <tls@ietf.org>; Wed, 25 Nov 2009 14:06:03 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAPM5v4c020439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 23:05:57 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911252205.nAPM5uCQ027921@fs4113.wdf.sap.corp>
To: mike-list@pobox.com
Date: Wed, 25 Nov 2009 23:05:56 +0100
In-Reply-To: <4B0D9B94.9080205@pobox.com> from "Michael D'Errico" at Nov 25, 9 01:03:16 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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, 25 Nov 2009 22:06:05 -0000

Michael D'Errico wrote:
> 
> I think that it would be good to find a unified solution that
> everybody is happy with, and believe that this may be it:
> 
> 
>    1) Client-to-Server signalling can be done in either of
>       two ways:
> 
>       A) an empty Secure_Renegotiation (SR) extension, or
>       B) a "magic" cipher suite
> 
>    2) Server-to-Client signal is always an empty SR extension
> 
>    3) Incorporate previous verify_data into Finished calc.
> 
> 
> The particulars:
> 
> A client that currently sends any other extensions MUST also
> send the empty SR extension.
> 
> A client that currently does not send any extensions MAY send
> the empty SR extension, or MAY send the magic cipher suite.


A client MUST send the magic cipher suite.  A client that sends
any TLS extension SHOULD send the the emtpy SR extension as well.

The server MUST check for the presence of the magic ciphersuite
and MUST use secure renegotiation when present.  The server
SHOULD NOT complain of absence of SR extension when the
magic ciphersuite is present.


-Martin