Re: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation detail

"Yngve Nysaeter Pettersen" <yngve@opera.com> Wed, 27 January 2010 13:17 UTC

Return-Path: <yngve@opera.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 0BE983A693F; Wed, 27 Jan 2010 05:17:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 IvBxEOULIuum; Wed, 27 Jan 2010 05:17:32 -0800 (PST)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id E6A353A6948; Wed, 27 Jan 2010 05:17:31 -0800 (PST)
Received: from killashandra.oslo.osa (pat-tdc.opera.com [213.236.208.22]) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0RDEGnq026519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Jan 2010 13:14:17 GMT
Date: Wed, 27 Jan 2010 14:17:41 +0100
To: tls@ietf.org, ietf@ietf.org
From: "Yngve Nysaeter Pettersen" <yngve@opera.com>
Organization: Opera Software
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
MIME-Version: 1.0
References: <808FD6E27AD4884E94820BC333B2DB775841199A56@NOK-EUMSG-01.mgdnok.nokia.com>
Content-Transfer-Encoding: 7bit
Message-ID: <op.u660jrvmvqd7e2@killashandra.oslo.osa>
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775841199A56@NOK-EUMSG-01.mgdnok.nokia.com>
User-Agent: Opera Mail/9.65 (Win32)
Subject: Re: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation detail
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: yngve@opera.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, 27 Jan 2010 13:17:33 -0000

I prefer publishing the specification as-is.


Additional comment:

The SCSV is a temporary fallback, one that will not be needed when clients  
enter strict mode, since when that happens servers have to support the RI  
extension.  Its use should therefore be kept to the minimum needed to  
provide the extra security it is designed to provide.

IMO the only situations in which the SCSV should be sent are:

    1) Initial connections when the server is known to not tolerate TLS  
Extensions, or this is not known, and
    2) During renegotiation with a server known not to support the RI  
extension _and_ that does not tolerate TLS Extensions, just in case this  
is a MITM attack and the real server actually supports RI, in which case  
we want the connection shut down. If the server tolerates extensions then  
only the RI extension should be sent.


On Tue, 26 Jan 2010 09:49:06 +0100, <Pasi.Eronen@nokia.com>; wrote:

> If the recent discussions have caused you to change your mind (or we
> have interpreted your preference incorrectly, or you were not on
> either list), please send an email to the TLS WG mailing list by
> Tuesday February 2nd. In your reply, please include one of the
> following:
>
>    (1) I prefer publishing the specification as-is.
>   (2) I prefer *NOT* publishing the specification as-is, and instead
>    prefer changing the text so that including the SCSV in secure
>    renegotiation ClientHellos is allowed (but not required).