[TLS] interoperability and security guarantees [was: Re: Confirming consensus about one]

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 27 January 2010 22:35 UTC

Return-Path: <dkg@fifthhorseman.net>
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 6C2B33A69D0 for <tls@core3.amsl.com>; Wed, 27 Jan 2010 14:35:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 G8ipdPbBRNgr for <tls@core3.amsl.com>; Wed, 27 Jan 2010 14:35:50 -0800 (PST)
Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by core3.amsl.com (Postfix) with SMTP id 56F503A635F for <tls@ietf.org>; Wed, 27 Jan 2010 14:35:50 -0800 (PST)
Received: (qmail 91411 invoked from network); 27 Jan 2010 22:36:05 -0000
Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay01.pair.com with SMTP; 27 Jan 2010 22:36:05 -0000
X-pair-Authenticated: 216.254.70.154
Message-ID: <4B60BFCE.8000605@fifthhorseman.net>
Date: Wed, 27 Jan 2010 17:35:58 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109)
MIME-Version: 1.0
To: tls@ietf.org
References: <201001272116.o0RLG69w008492@fs4113.wdf.sap.corp>
In-Reply-To: <201001272116.o0RLG69w008492@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9; url=http://fifthhorseman.net/dkg.gpg
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigD07E4AC377FEFDC271795C67"
Subject: [TLS] interoperability and security guarantees [was: Re: Confirming consensus about one]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: tls@ietf.org
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, 27 Jan 2010 22:35:51 -0000

On 01/27/2010 04:16 PM, Martin Rex wrote:
> Providing the interoperability in the protocol is the task of
> the IETF TLS WG, implementing interoperability with the installed
> base correctly is the task for the TLS implementor,
> and deciding and configuring whether interoperability with
> old peers on renegotiation handshakes is necessary, is the task
> of the consumer of the technology (configurable policy options).

Martin, you seem very concerned with interoperability, and i appreciate
your advocacy for that concern.  I also value interoperability, and want
to see a smoothly phased-in transition.  However, the TLS working group
is not *only* about interoperability; it is also about how to offer
well-vetted, well-understood, comprehensible communications security
properties to the users of TLS.

It's clear from this discussion that the communications security
properties that earlier (uh, make that "all existing") versions of TLS
offered were either simply wrong, or at least very widely misunderstood
by not only users of TLS but also many TLS implementers.

Having simple and clear rules for implementers to follow will produce
less-buggy software, which will improve our ability as a WG to fulfill
the promises of private and authenticated communication that have been
made from the beginning of the standard.

The part you're arguing about (MUST NOT show SCSV during non-empty RI,
as i understand it) may or may not overstep the bounds outlined in RFC
2119; but it does not affect the security guarantees, and it is
relatively easy to implement either way.   But we can't resolve the
clear outstanding security flaws in the protocol while we're still
quibbling about this sort of detail.  From what i can see, nearly
everyone else has moved on to building and testing interoperable
implementations, whether they agree with the MUST NOT or not.

That's not happening because they don't care about interoperability.
They care about interoperability *and* about offering functional
security capabilities to their users.

If i agree with you that the MUST NOT seems a bit excessive, can you
agree with me that it doesn't actually alter the security guarantees one
way or another?  Can we then move on, accept that the standard might be
a bit stricter than it needs to be, and implement it anyway?  I favor
publishing the -03 as it is because it looks like it resolves the
problem at hand, not because i think it has every word written in the
best possible way.

The bottom line is that *all* TLS (and SSL!) implementations need
patching.  The sooner we agree on what those patches should do, the
sooner we can start rolling them out, and the sooner we can get back to
the guarantees we thought we had with TLS in the first place.

Regards,

	--dkg