Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation

Marsh Ray <marsh@extendedsubset.com> Fri, 29 January 2010 15:52 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 8383628C15F; Fri, 29 Jan 2010 07:52:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 bnpOsfY7LIuu; Fri, 29 Jan 2010 07:52:46 -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 7554F28C14B; Fri, 29 Jan 2010 07:52:46 -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 1Nat9g-000GcQ-DF; Fri, 29 Jan 2010 15:53:08 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C2F2E6048; Fri, 29 Jan 2010 15:53:06 +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: U2FsdGVkX18HHmwiUL3pqoC2mKdSTsQjtvugdelU/ak=
Message-ID: <4B630461.1030001@extendedsubset.com>
Date: Fri, 29 Jan 2010 09:53:05 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Stefan Santesson <stefan@aaa-sec.com>
References: <C7885EA3.7F9D%stefan@aaa-sec.com>
In-Reply-To: <C7885EA3.7F9D%stefan@aaa-sec.com>
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, ietf@ietf.org
Subject: Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation
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: Fri, 29 Jan 2010 15:52:47 -0000

Stefan Santesson wrote:
> This makes no sense to me.
> 
> Developers tend to live by the rule to be "liberal in what you accept" as it
> tends to generate less interop problems.

Not in my experience.

HTML is perhaps the ultimate example of a liberal implementation of a
spec. To this day, many years later, it's common to find pages that
render badly with one or more implementations.

Whenever an application is actively being "liberal in what it accepts",
the sending application is in fact relying on undocumented behavior.
This is what causes the ineterop problems, not strictness.

In practice, if protocol receiving applications are consistently strict
about what they accept, then mutant protocol sending applications do not
get out to pollute the ecosystem.

> It makes no sense to abort a TLS handshake just because it contains an SCSV
> if everything else is OK.

This is a cryptographic data security protocol for which
interoperability must be secondary to security. If anything is malformed
or suspicious, the handshake should be aborted.

> So This "MUST NOT" requirement will likely be
> ignored by some implementations.

They should expect the market to hold them accountable if problems result.

The implementers on this list have indicated they could produce
interoperable implementations of this spec. And they appear to have
proven it by demonstrating implementations which actually interoperate.

> 03 gives SCSV somewhat double and conflicting semantics.
> 
> 1) Present in an initial handshake it signals client support for secure
> renegotiation.
> 
> 2) Present in a renegotiation handshake it signals that the client DOES NOT
> support secure renegotiation (Handshake MUST be aborted).
> 
> I think this is asking for trouble.

Yep, it's an inelegant hack. None of this is how any of us would have
designed it that way from the beginning.

I would recommend that clients always send a proper RI extension and
don't even mess with sending SCSV. Extensions-intolerant servers should
just go away. Servers just treat SCSV like an empty RI (clearly wrong
for a renegotiation) without adding much complexity.

As for "[Upgraded] Clients which choose to renegotiate [] with an
un-upgraded server", they deserve whatever they get.

SCSV is just for those implementers that want to make insecure
connections with old and broken peers. That task has always involved
added complexity and they know the work they're buying for themselves.

- Marsh