Re: [TLS] draft-ietf-tls-renegotation: next steps

Michael D'Errico <mike-list@pobox.com> Wed, 16 December 2009 16:53 UTC

Return-Path: <mike-list@pobox.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 F04DA3A6774; Wed, 16 Dec 2009 08:53:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.528
X-Spam-Level:
X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 gmcdWbJWRXNU; Wed, 16 Dec 2009 08:53:28 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id DB0693A67A4; Wed, 16 Dec 2009 08:53:27 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id B6DEAA70E2; Wed, 16 Dec 2009 11:53:13 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=y4LcOwyDlKxU Hyvh7C+RDCfDYfg=; b=oz6yZ4GE7opNU4lYFkHPmv/ezEm9kwo30VOY0pw4Hxef ZKJ+7Lm3l67nikIpVgsXvKbhLZvVDCVMWG+uQS1j6ZbCN/jolnxiiEzoZ5ZpT2e9 tXxHjM7XkMJjlNLAlhHMnFYFwF3aeIpCRxu3b1csBs7CVAwGCM0FBQdu3BEfzts=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=cPH+QH HWlZzApeyMScTVFp3mePLXk7SUT/XPASBGYBAOva97r9TcqO8ZfdUnnWENJf9Ixn EeS6zM9UZgPkd83aM1id6fRm4APFEXsTTSZSDW5tKT6isqThPVkenVHy0iAG4zLI u4GrsQbEPm5NJW+6MTznyD5IMcYVmgefAsl+4=
Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id A2B2CA70E1; Wed, 16 Dec 2009 11:53:12 -0500 (EST)
Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id BB68CA70E0; Wed, 16 Dec 2009 11:53:10 -0500 (EST)
Message-ID: <4B2910E9.8040106@pobox.com>
Date: Wed, 16 Dec 2009 08:55:05 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: ietf@ietf.org, tls@ietf.org
References: <808FD6E27AD4884E94820BC333B2DB774F31F17456@NOK-EUMSG-01.mgdnok.nokia.com>
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774F31F17456@NOK-EUMSG-01.mgdnok.nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 7F4F664C-EA63-11DE-A893-B34DBBB5EC2E-38729857!a-pb-sasl-sd.pobox.com
Subject: Re: [TLS] draft-ietf-tls-renegotation: next steps
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 16:53:29 -0000

Pasi.Eronen@nokia.com wrote:
> (wearing IETF Security Area Director hat)
> 
> - Whether to prohibit sending the extension (in initial ClientHello),
> or require the magic cipher suite even if the extension is sent (in
> initial ClientHello): The consensus is again a bit rougher than we'd
> normally hope to see, but the current text (either is allowed) has
> more support (about 2/3 vs. 1/3), so we keep it. And again, I believe
> most participants prefer make some decision over continuing the
> discussion.

There is no need to prohibit sending an empty RI in an initial Client
Hello.  Would a server be required to abort if it received it?  That
doesn't seem like a good design.

I've implemented RI + MCSV and the logic I used was to have a boolean
for whether the peer is patched, plus a string to hold the received
renegotiation_info.  When a ClientHello is being processed, the flag
is set to false and the string is cleared.  Then if the MCSV is seen
in the cipher suite list, the flag is set to true.  Then when parsing
the extensions, if RI is encountered, the flag is set to true and the
renegotiation_info is extracted into the string.  There is no need to
have special cases for initial vs. renegotiation handshakes.

> - There was some discussion on whether to add the magic cipher suite
> to patched renegotiation ClientHellos (in addition to the extension),
> too. I believe rough consensus is not to do this.

There is no need to prohibit sending the MCSV in a renegotiation Client
Hello.  Using the same logic above, all that it does is flip a bit in
the server's state.  If the client believes it is doing a renegotiation,
then it will also send RI with verify_data, which will get processed as
above.

> - There was discussion about adding another C->S signaling method
> using the proposed version: if proposed version >= 1.3, and the
> negotiated version is <= 1.2, it means the client supports this draft
> (what happens if negotiated version is >= 1.3 would be specified in
> the TLS 1.3 spec). This would allow TLS >=1.3 clients to remove other
> signaling (magic cipher suite/extension) from initial ClientHellos
> (but requires extra code in the server). As Tom Petch (and others)
> noted, if we want to do this, it has to be done now (and can't be done
> when doing TLS 1.3). There was relatively little support for doing
> this, and rough consensus seems to keep the spec as is in this regard.

As a practical matter, any TLS 1.3 code will need to still send RI and
MCSV since it will surely encounter older servers for a long while
after that spec gets published.  So it seems that this is unnecessary.

Mike