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

"Blumenthal, Uri - 0662 - MITLL" <uri@ll.mit.edu> Mon, 21 December 2009 14:35 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 34F663A6767 for <tls@core3.amsl.com>; Mon, 21 Dec 2009 06:35:14 -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 GoQZ1HjmrkYS for <tls@core3.amsl.com>; Mon, 21 Dec 2009 06:35:13 -0800 (PST)
Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 46C0B3A67D9 for <tls@ietf.org>; Mon, 21 Dec 2009 06:35:12 -0800 (PST)
Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id nBLEYstH015481; Mon, 21 Dec 2009 09:34:54 -0500 (EST)
Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAJmaikl; Mon Dec 21 09:27:27 2009
Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Mon, 21 Dec 2009 09:27:27 -0500
From: "Blumenthal, Uri - 0662 - MITLL" <uri@ll.mit.edu>
To: "'Pasi.Eronen@nokia.com'" <Pasi.Eronen@nokia.com>, "'tls@ietf.org'" <tls@ietf.org>
Date: Mon, 21 Dec 2009 09:27:25 -0500
Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft
Thread-Index: AcqBxVzyjJ1EhMYoQwKb4uPMSg4flAAErZfdABDNn8AAC5uCIg==
Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE85401D@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: Mon, 21 Dec 2009 14:35:14 -0000

I see the reasoning, and while one could argue in favor of guessing - the logic presented is good enough (and thus there's no justification for re-opening this can and spending more time on it). 

I withdraw my objection.

Thanks!


----- Original Message -----
From: Pasi.Eronen@nokia.com <Pasi.Eronen@nokia.com>
To: Blumenthal, Uri - 0662 - MITLL; tls@ietf.org <tls@ietf.org>
Sent: Mon Dec 21 03:57:19 2009
Subject: RE: [TLS] SCSV vs RI when both specified. Was: Updated draft

Uri Blumenthal wrote:

> OK. Karlsruhe server time-outs on me, so no chance to get enlightened
> by checking that thread. Please indulge me: the one short compelling
> reason why we don't want to say "when two signals are present use this
> one and ignore the other" instead of "when two signals are present -
> abort connection" - is...?

Well, if the spec says "the client MUST not send two signals", then if
two signals are present, it's probably safer to abort (since the
client is not following the spec anyway, it's hard to guess
what its intent was...)

Best regards,
Pasi
(not wearing any hats)