IETF Logo Mail Archive

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

Marsh Ray <marsh@extendedsubset.com> Wed, 16 December 2009 15:50 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 79A073A68C9 for <tls@core3.amsl.com>; Wed, 16 Dec 2009 07:50:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.293
X-Spam-Level:
X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
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 jm4RsmCi01lw for <tls@core3.amsl.com>; Wed, 16 Dec 2009 07:50:08 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 968B73A6863 for <tls@ietf.org>; Wed, 16 Dec 2009 07:50:08 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NKw8O-000DWt-TX; Wed, 16 Dec 2009 15:49:53 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 9E4806678; Wed, 16 Dec 2009 15:49:50 +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: U2FsdGVkX1/9Z55OChpOPSEnkvyjYjhpi8pGskYCAVs=
Message-ID: <4B29019E.1090909@extendedsubset.com>
Date: Wed, 16 Dec 2009 09:49:50 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Martin Rex <mrex@sap.com>
References: <200912161530.nBGFU0av027619@fs4113.wdf.sap.corp>
In-Reply-To: <200912161530.nBGFU0av027619@fs4113.wdf.sap.corp>
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
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: Wed, 16 Dec 2009 15:50:09 -0000

Martin Rex wrote:
> Marsh Ray wrote:
>> I would like for the decisions we make today to allow the MCSV hack to
>> be retired at some point in the future. MCSV represents extra complexity
>> that we added as a concession for interoperability with obsolete and
>> out-of-spec systems.
> 
> MCSV is a very plain and simple backwards interoperability option,
> and it will, in fact, make implementations easier (less code),
> less bits-on-the-wire and more robust.

For the record, I have never supported using MCSV as a way for
implementors to avoid properly handling extensions or to save bits. I
have only supported it to help implementors and applications that did
not want to lead off the initial handshake with an extension due to the
fact that some servers in the wild enter into a slow fail condition.

Allowing receivers of a protocol element to make an assumption (because
the sender is supposed to send redundant signals) does not usually end
up making things more robust.

--- switching to another thread here ---

Martin Rex wrote:
> Pasi.Eronen@nokia.com wrote:
>> - The current draft doesn't clearly say what should be included in
>> legacy (insecure) renegotiation ClientHellos. I am not sure if we have
>> enough clear opinions to call consensus, but keeping it aligned with
>> the initial ClientHello (either MSCV or extension) seems to be one
>> simple approach (but I hope to see the actual text).
>
> Again, the choice is obvious: MCSV, *NO* extension.
>
> Anything else just makes no sense and may obviously cause interop
> problems for some backwards interop scenarios, because it is
> a backwards-incompatible change.

Martin is right about one thing here.

MCSV and/or the extension MUST be sent even on renegotiation hellos in
order to avoid a specific attack. It's a scenario that's already broken,
but nevertheless it is an attack involving two patched endpoints that
can be prevented.

The current draft has the following language:
>    TLS clients which support this draft MUST generate either the
>    "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST
>    cipher suite with every ClientHello.

I am hoping that a future revision will reinforce that it applies to
even supposed renegotiation hellos in compatible-insecure mode.

It's not so obvious to me that extension should not be sent though.
Spec'ing that would amount to blessing the behavior of old broken
systems. Elsewhere we have left that up to implementors whether or not
to send extensions.

> About the backwards interop scenarios in general:
>
> Can we please discontine the misleading terminology "lenient
client/server"
> and instead refer to the specific backwards interop scenarios that
> we address with a recommendation?
>
> (1)  updated client allowing initial handshakes with old servers
> (2)  updated client allowing renegotiation handshakes with old servers
> (3)  updated server allowing initial handshakes with old clients
> (4)  updated server allowing renegotiation handshakes with old clients

"Lenient" is the nice word for it, all four of those "backwards interop"
scenarios are just plain insecure.

- Marsh

v2.23.0 | Report a Bug | By Email