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

Michael Gray <mickgray@au1.ibm.com> Mon, 14 December 2009 02:35 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 2474828C0EE for <tls@core3.amsl.com>; Sun, 13 Dec 2009 18:35:46 -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 u8fydcqU7-PS for <tls@core3.amsl.com>; Sun, 13 Dec 2009 18:35:45 -0800 (PST)
Received: from e23smtp03.au.ibm.com (e23smtp03.au.ibm.com [202.81.31.145]) by core3.amsl.com (Postfix) with ESMTP id CD68128C0E9 for <tls@ietf.org>; Sun, 13 Dec 2009 18:35:44 -0800 (PST)
Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp03.au.ibm.com (8.14.3/8.13.1) with ESMTP id nBE2Wgsb004033 for <tls@ietf.org>; Mon, 14 Dec 2009 13:32:42 +1100
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBE2VX4U1466604 for <tls@ietf.org>; Mon, 14 Dec 2009 13:31:35 +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 nBE2ZRwB022418 for <tls@ietf.org>; Mon, 14 Dec 2009 13:35:27 +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 nBE2ZRNG022415; Mon, 14 Dec 2009 13:35:27 +1100
In-Reply-To: <4B21BFF5.2020909@jacaranda.org>
To: David-Sarah Hopwood <david-sarah@jacaranda.org>
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
Message-ID: <OF116A86AB.2ED8107A-ON4A25768B.007C62E6-4A25768C.000E34FF@au1.ibm.com>
From: Michael Gray <mickgray@au1.ibm.com>
Date: Mon, 14 Dec 2009 12:35:10 +1000
X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 14/12/2009 13:42:29
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 02:35:46 -0000

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

> Martin Rex wrote:
> > Michael Gray wrote:
> >>> in order to reliably provide this,
> >>>
> >>>   - MCSV is defined to represent an empty TLS extension RI
> >>>
> >>>   - MSCV MUST be included in *ALL* initial ClientHello handshakes
> >>>     messages _plus_ all renegotiation ClientHellos in backwards
> >>>     interop scenarios (independent of full handshake or session
resume).
> >>>
> >>>   - empty TLS extension RI MUST NOT be sent, ever!
> >>
> >> This looks good to me, the only thing I would change is I think MUST
NOT
> >> would be better as SHOULD NOT as the later requires that the
implementer
> >> examine the conditions and implications etc to make the best decision.
> >
> > You are right.  I'm sorry.  I got a little carried away.
> >
> > A SHOULD NOT for sending _empty_ TLS extension RI is more appropriate.
>
> Why? What is the point of allowing the client to send an empty extension,
> when a patched client MUST send the MSCV, and a patched server MUST use
> *only* the MSCV to determine whether the client is patched? You'd just be
> adding the option to send an extension that has no defined meaning.
>

This shows how hard it is to harmonize the two proposed specs.  What I want
to avoid is a change to the on the wire protocol being used in production
environments due to applying this fix.

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.

Naturally requiring only one signaling method is simpler and preferable
from an implementation and testing point of view.

- Mick

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