IETF Logo Mail Archive

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

Steve Checkoway <s@pahtak.org> Sat, 19 December 2009 08:47 UTC

Return-Path: <s@pahtak.org>
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 2F83B3A6A2E for <tls@core3.amsl.com>; Sat, 19 Dec 2009 00:47:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level:
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599]
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 NaLgKRtIKB+C for <tls@core3.amsl.com>; Sat, 19 Dec 2009 00:47:07 -0800 (PST)
Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 4DF2B3A6967 for <tls@ietf.org>; Sat, 19 Dec 2009 00:47:07 -0800 (PST)
Received: by gxk28 with SMTP id 28so3704306gxk.9 for <tls@ietf.org>; Sat, 19 Dec 2009 00:46:49 -0800 (PST)
Received: by 10.150.48.29 with SMTP id v29mr6028385ybv.200.1261212409640; Sat, 19 Dec 2009 00:46:49 -0800 (PST)
Received: from lonely.pahtak.org (ip68-107-82-55.sd.sd.cox.net [68.107.82.55]) by mx.google.com with ESMTPS id 22sm2816341iwn.4.2009.12.19.00.46.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 19 Dec 2009 00:46:48 -0800 (PST)
Received: from dualg5.pahtak.org (dualg5.pahtak.org [192.168.1.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by lonely.pahtak.org (Postfix) with ESMTPSA id 5D9F25C26D; Sat, 19 Dec 2009 00:46:46 -0800 (PST)
Message-Id: <668916E2-787C-44B2-9577-707FD1611E45@pahtak.org>
From: Steve Checkoway <s@pahtak.org>
To: TLS Mailing List <tls@ietf.org>
In-Reply-To: <4B2BEE01.90700@pobox.com>
Content-Type: multipart/signed; boundary="Apple-Mail-25--562635596"; micalg="sha1"; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sat, 19 Dec 2009 00:46:45 -0800
References: <200912181944.nBIJiLMU005565@fs4113.wdf.sap.corp> <4B2BE246.9040307@extendedsubset.com> <4B2BE7EC.7010309@pobox.com> <4B2BEA09.2030307@extendedsubset.com> <4B2BEE01.90700@pobox.com>
X-Mailer: Apple Mail (2.936)
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 08:47:08 -0000

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