Re: [TLS] SCSV vs RI when both specified. Was: Updated draft
Marsh Ray <marsh@extendedsubset.com> Tue, 22 December 2009 16:40 UTC
Return-Path: <marsh@extendedsubset.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 0873C3A6A1B for <tls@core3.amsl.com>; Tue, 22 Dec 2009 08:40:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.592
X-Spam-Level:
X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 PMCl83YF8Aoo for <tls@core3.amsl.com>; Tue, 22 Dec 2009 08:40:45 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 0DF8A3A6A18 for <tls@ietf.org>; Tue, 22 Dec 2009 08:40:44 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NN7me-000NpW-0S; Tue, 22 Dec 2009 16:40:28 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8A7AF603A; Tue, 22 Dec 2009 16:40:26 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19PX4Zg7cpMj++UzMhcX8tmvMuSVdEMRyk=
Message-ID: <4B30F67D.1030807@extendedsubset.com>
Date: Tue, 22 Dec 2009 10:40:29 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "Blumenthal, Uri - 0662 - MITLL" <uri@ll.mit.edu>
References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854020@LLE2K7-BE01.mitll.ad.local>
In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854020@LLE2K7-BE01.mitll.ad.local>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "'tls@ietf.org'" <tls@ietf.org>
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: Tue, 22 Dec 2009 16:40:46 -0000
Blumenthal, Uri - 0662 - MITLL wrote: > Is this why soldiers in the field switch off their accredited > certified secure comm gear (which won't talk when things look the > least bit funny?) That's something of a complex question in general. It might be instructive to run down the problems with specific cases though. > and turn to cell phones? As for them the need to > communicate usually does NOT take a back seat. Perhaps the priorities of the soldiers in the field are not in perfect alignment with those who specified the equipment? > We are talking hypothetically of course rather than about this > particular TLS decision, which might well be the right choice. Even when the goal is successful communcation, my experience is the opposite. Paradoxically, it seems that the stricter implementations are expected to be about data they receive, the better they will interoperate in the wild. When receivers are "lenient", senders grow up and get shipped counting on that undocumented behavior. Later receivers come along which are not as lenient, or lenient in different ways, and things break. Compare TLS and HTML: Both were largely driven by Netscape early on. TLS is relatively strict, whereas HTML was intentionally loose. TLS has had a few interop issues, but mainly it's deciding how far back to support old versions. You implementers of course know of some bugs. We've expended a huge amount of effort to work around the few extension-intolerant servers out there, but it sounds like that originated from a document versioning mixup more than anything. HTML, on the other hand, well, it looked to me like Netscape (and later Microsoft) attempted to use its undocumented rendering behavior as some kind of perverse competitive advantage. It was lenient in all sorts of ways and the result is varying degrees of 'quirks mode', which is still with us today. - Marsh > ----- Original Message ----- From: Marsh Ray > <marsh@extendedsubset.com> To: Blumenthal, Uri - 0662 - MITLL Cc: > 'tls@ietf.org' <tls@ietf.org> Sent: Mon Dec 21 11:28:29 2009 Subject: > Re: [TLS] SCSV vs RI when both specified. Was: Updated draft > > 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. > > TLS is a cryptographic data security protocol. > > "Allowing entities to communicate" takes a back seat to the primary > goal of preventing unauthorized communication. > >> 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". > > How about "remote endpoint doesn't pass the bozo test"? > >> Personal curiosity - what kind of work do you do? (Feel free to >> answer in a private email or to ignore altogether.) > > I do software development (and security research) work on > PhoneFactor, a product/service for doing two-factor authentication > with ordinary phones. > >> 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?! > > Yes, I care greatly that the peer refuses any connection that looks > the least bit funny. > > - Marsh > > _______________________________________________ TLS mailing list > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Michael D'Errico
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Michael D'Errico
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Steve Checkoway
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Steve Checkoway
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Steve Checkoway
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Pasi.Eronen
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Yoav Nir
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Michael D'Errico
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Dr Stephen Henson
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Michael D'Errico
- Re: [TLS] SCSV vs RI when both specified - consen… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified - consen… Nasko Oskov
- Re: [TLS] SCSV vs RI when both specified - consen… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified - consen… Michael D'Errico
- Re: [TLS] SCSV vs RI when both specified - consen… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Yoav Nir
- Re: [TLS] SCSV vs RI when both specified - consen… Yoav Nir
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Kemp, David P.
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Ben Laurie
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Kemp, David P.
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Steve Dispensa
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Kemp, David P.
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Kemp, David P.
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Martin Rex
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Marsh Ray
- Re: [TLS] SCSV vs RI when both specified. Was: Up… Kyle Hamilton