Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV

Michael Gray <mickgray@au1.ibm.com> Mon, 14 December 2009 04:55 UTC

Return-Path: <mickgray@au1.ibm.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 2B40E3A683D for <tls@core3.amsl.com>; Sun, 13 Dec 2009 20:55:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.595
X-Spam-Level:
X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 QamxSz1Hu6hh for <tls@core3.amsl.com>; Sun, 13 Dec 2009 20:55:39 -0800 (PST)
Received: from e23smtp01.au.ibm.com (e23smtp01.au.ibm.com [202.81.31.143]) by core3.amsl.com (Postfix) with ESMTP id 05FB83A67FC for <tls@ietf.org>; Sun, 13 Dec 2009 20:55:38 -0800 (PST)
Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245]) by e23smtp01.au.ibm.com (8.14.3/8.13.1) with ESMTP id nBE4rfiR027843 for <tls@ietf.org>; Mon, 14 Dec 2009 15:53:41 +1100
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBE4tNvT1863800 for <tls@ietf.org>; Mon, 14 Dec 2009 15:55:23 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nBE4tNZZ027885 for <tls@ietf.org>; Mon, 14 Dec 2009 15:55:23 +1100
Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av03.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nBE4tMXl027882; Mon, 14 Dec 2009 15:55:22 +1100
In-Reply-To: <4B25B362.1020408@jacaranda.org>
To: David-Sarah Hopwood <david-sarah@jacaranda.org>
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
Message-ID: <OF312C231D.2CFE4C95-ON4A25768C.0016800B-4A25768C.001B0563@au1.ibm.com>
From: Michael Gray <mickgray@au1.ibm.com>
Date: Mon, 14 Dec 2009 14:55:08 +1000
X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 14/12/2009 16:02:25
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Cc: tls@ietf.org
Subject: Re: [TLS] Analysis of Interop scenarios TLS extension RI w/MCSV
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, 14 Dec 2009 04:55:40 -0000

David-Sarah Hopwood <david-sarah@jacaranda.org> wrote:

> Michael Gray wrote:
> > I see two use cases here;
> >
> > A. Existing implementations that send extensions today and are
therefore
> > are fine to add this additional extension.  Note: this means they are
> > already sending extensions, not just extension capable.  By applying
this
> > fix nothing changes with the protocol being used.
> >
> > B. Existing implementations that do not send any extensions today and
as
> > such they must not change the protocol due to this fix, which means
they
> > can only safely use the MCSV as the signaling method.
> >
> > It seems to me that we simply need the appropriate wording to allow
> > implementers to decide the best strategy that needs to adopted based on
> > risk factors to deployed production environments rather than mandate A
> > which will break some production environments or mandate B which means
that
> > extension using systems must use the CipherSuite method.
>
> What is the disadvantage of extension-using systems having to use the
> CipherSuite method? I've heard only vague aesthetic objections so far;
> nothing concerned with more substantive factors such as code complexity,
> security, or interoperability.

Yes, I do not believe a technical objection to the CipherSuite method has
been presented, but rather it seems to me to be a question of technical
preference.

- Mick


> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls