IETF Logo Mail Archive

Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

"Blumenthal, Uri - 0662 - MITLL" <uri@ll.mit.edu> Sat, 19 December 2009 13:28 UTC

Return-Path: <uri@ll.mit.edu>
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 A2C8F3A68B3 for <tls@core3.amsl.com>; Sat, 19 Dec 2009 05:28:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 W+k1IENj11EX for <tls@core3.amsl.com>; Sat, 19 Dec 2009 05:28:10 -0800 (PST)
Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id BBB623A6953 for <tls@ietf.org>; Sat, 19 Dec 2009 05:28:10 -0800 (PST)
Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nBJDRrQf028581 for <tls@ietf.org>; Sat, 19 Dec 2009 08:27:53 -0500 (EST)
Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAA54aya2; Sat Dec 19 08:24:15 2009
Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Sat, 19 Dec 2009 08:24:15 -0500
From: "Blumenthal, Uri - 0662 - MITLL" <uri@ll.mit.edu>
To: "'tls@ietf.org'" <tls@ietf.org>
Date: Sat, 19 Dec 2009 08:24:14 -0500
Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft
Thread-Index: AcqAh9cpjxcz0TqVTsK1VI3qDexK4gAJrfWS
Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE85400B@LLE2K7-BE01.mitll.ad.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Sat, 19 Dec 2009 13:28:11 -0000

You're saying it's not important whether the protocol spec demands aborting the connection or not?!  As long as the processing amount to arrive at the decision is about the same?

And yes I would hold the publication to clear up this issue.

----- Original Message -----
From: tls-bounces@ietf.org <tls-bounces@ietf.org>
To: TLS Mailing List <tls@ietf.org>
Sent: Sat Dec 19 03:46:45 2009
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft


On Dec 18, 2009, at 1:02 PM, Michael D'Errico wrote:

> My two sentences describe everything you need to know:
>
>   SCSV absent,  RI absent:   hide the kids
>   SCSV absent,  RI present:  same as RI
>   SCSV present, RI absent:   same as empty RI
>   SCSV present, RI present:  same as RI (SCSV ignored)
>
> Why do you want the last one to be "ABORT!!"?


It's pretty clear (to me) that it doesn't matter if the last one is  
allowed or not, as long as the spec makes a clear decision. It's  
roughly the same amount of code (plus or minus a conditional and an  
alert). The four conditions have to be tested regardless of how it's  
defined.

Is this point really so important that it's worth holding up  
publication and subsequent implementation? I say it is not.

-- 
Steve Checkoway

     "Anyone who says that the solution is to educate the users
     hasn't ever met an actual user." -- Bruce Schneier

v2.23.0 | Report a Bug | By Email