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

"Kemp, David P." <DPKemp@missi.ncsc.mil> Tue, 22 December 2009 17:27 UTC

Return-Path: <DPKemp@missi.ncsc.mil>
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 C7F353A693E for <tls@core3.amsl.com>; Tue, 22 Dec 2009 09:27:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.066
X-Spam-Level:
X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 cdlSGiUeoE1m for <tls@core3.amsl.com>; Tue, 22 Dec 2009 09:27:38 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id CC8843A6866 for <tls@ietf.org>; Tue, 22 Dec 2009 09:27:37 -0800 (PST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 22 Dec 2009 12:19:45 -0500
Message-ID: <200912221727.nBMHRKde023850@stingray.missi.ncsc.mil>
In-Reply-To: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854020@LLE2K7-BE01.mitll.ad.local>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] SCSV vs RI when both specified. Was: Updated draft
thread-index: AcqCWqP/QuwhCp6SRzqJOmVfUsOLZQAZubFlABlzwAA=
References: <90E934FC4BBC1946B3C27E673B4DB0E4A7EE854020@LLE2K7-BE01.mitll.ad.local>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: tls@ietf.org
X-OriginalArrivalTime: 22 Dec 2009 17:27:44.0812 (UTC) FILETIME=[12A58EC0:01CA832C]
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 17:27:38 -0000

Speaking of the STU-III (which is the latest secure telephone I had a
hand in - back in the 1980s), there is a difference between 1) switching
off secure mode, and 2) accepting a connection with a bozo peer while
perceiving the connection to be secure.

Both communicating and accurate security awareness are necessary; those
requirements do not conflict.

Dave


-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
Blumenthal, Uri - 0662 - MITLL
Sent: Monday, December 21, 2009 11:45 PM
To: 'tls@ietf.org'
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

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?) and turn to cell phones? As for them the need to communicate
usually does NOT take a back seat.

We are talking hypothetically of course rather than about this
particular TLS decision, which might well be the right choice.


----- 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