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

Steve Checkoway <s@pahtak.org> Sun, 20 December 2009 15:12 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 4AF4E3A6819 for <tls@core3.amsl.com>; Sun, 20 Dec 2009 07:12:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.42
X-Spam-Level:
X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 JHPNS7RqrR1D for <tls@core3.amsl.com>; Sun, 20 Dec 2009 07:12:49 -0800 (PST)
Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 210923A688C for <tls@ietf.org>; Sun, 20 Dec 2009 07:12:49 -0800 (PST)
Received: by pxi9 with SMTP id 9so3196061pxi.32 for <tls@ietf.org>; Sun, 20 Dec 2009 07:12:31 -0800 (PST)
Received: by 10.114.2.29 with SMTP id 29mr3502403wab.48.1261321950976; Sun, 20 Dec 2009 07:12:30 -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 21sm4399157pzk.3.2009.12.20.07.12.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 20 Dec 2009 07:12:29 -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 8AF8B5C26D; Sun, 20 Dec 2009 07:12:28 -0800 (PST)
Message-Id: <4F7AF248-A0E4-4EBE-82BB-F243F35FD9C2@pahtak.org>
From: Steve Checkoway <s@pahtak.org>
To: TLS Mailing List <tls@ietf.org>
In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854013@LLE2K7-BE01.mitll.ad.local>
Content-Type: multipart/signed; boundary="Apple-Mail-26--453093176"; micalg="sha1"; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sun, 20 Dec 2009 07:12:28 -0800
References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854013@LLE2K7-BE01.mitll.ad.local>
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: Sun, 20 Dec 2009 15:12:50 -0000

On Dec 19, 2009, at 8:31 PM, Blumenthal, Uri - 0662 - MITLL wrote:

> The only purpose of any protocol is to allow entities to communicate  
> (under a given set of constraints). Thus every effort SHOULD be  
> invested to provide this capability whenever possible. If the  
> protocol spec demands aborting connection, it better have a damn  
> good reason to do so - and more substantive than "some Steve decided  
> it doesn't really matter to him if the peers connect or not".

My point was merely that publication and subsequent implementation of  
the fix is more important than worrying about the specifics of what  
happens when two signals are used (as long as it is clearly specified,  
of course). Others may feel differently.

> I'm shocked that nobody else seems to pick on this. Is it that mid- 
> weekend thing, or am I the only one who cares whether the peer would  
> establish or refuse connection?!


There seem to be roughly 20 emails in this thread and its predecessor  
"Updated draft" talking about this starting with <http://www.imc.org/ietf-tls/mail-archive/msg11433.html 
 >.

-- 
Steve Checkoway

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