[TLS] Comments on draft-rescorla-tls-renegotiate.txt
David-Sarah Hopwood <david-sarah@jacaranda.org> Sat, 07 November 2009 06:18 UTC
Return-Path: <djhopwood@googlemail.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 CB5543A6A18 for <tls@core3.amsl.com>; Fri, 6 Nov 2009 22:18:14 -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=[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 9kvCvO9+2sD6 for <tls@core3.amsl.com>; Fri, 6 Nov 2009 22:18:13 -0800 (PST)
Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 443A23A6A26 for <tls@ietf.org>; Fri, 6 Nov 2009 22:18:13 -0800 (PST)
Received: by ewy3 with SMTP id 3so1710950ewy.37 for <tls@ietf.org>; Fri, 06 Nov 2009 22:18:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type; bh=CLhTl8dAfaGGElb8iamHI/Xz125EcCE/6GApBtXlSp8=; b=SzvXt6cbWb10E+AX7DlN6Z9JJdxCOX+SFJEiA2EnSmdQoE1klqeJ3lxwO2f8n3KaON fsdzdas4k/haVAvFDP/M/3ws/InnQR/jJP/ND2EcJwDwjHRgzQuBRTO43/utgMSmas/k PD2D8ZQ0tU3SVTsiG0ARHANMCcvZu8Ks5J/1E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type; b=JsJuuGP5ygZCRaUceZfrwsBil1+Gm/ouECNRt6PxuB4f9Nh2n/uohhmC7HkoC4otJi cns11qikBppK7hIevNGmBSeDNaKDAs6lIvhymkJJtw7QRdaHo30NcYl7BFc/FqGJl2wa 0Hq4f+pD/gb0xjxvSVQPRikmtgcotTGSI+YJ4=
Received: by 10.213.68.143 with SMTP id v15mr346043ebi.45.1257574713585; Fri, 06 Nov 2009 22:18:33 -0800 (PST)
Received: from ?192.168.0.2? (5e025226.bb.sky.com [94.2.82.38]) by mx.google.com with ESMTPS id 7sm457243eyb.16.2009.11.06.22.18.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 06 Nov 2009 22:18:33 -0800 (PST)
Sender: David-Sarah Hopwood <djhopwood@googlemail.com>
Message-ID: <4AF5112E.2070809@jacaranda.org>
Date: Sat, 07 Nov 2009 06:18:22 +0000
From: David-Sarah Hopwood <david-sarah@jacaranda.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: tls@ietf.org
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------enig12E331B6CDC592B8905C717A"
Subject: [TLS] Comments on draft-rescorla-tls-renegotiate.txt
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: Sat, 07 Nov 2009 06:24:05 -0000
Comments on https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt Overall I think this draft is a good solution to the identified security problem. The draft defines an extension that affects renegotiation, which might be perceived to conflict with RFC 3546 section 2.3: Finally note that all the extensions defined in this document are relevant only when a session is initiated. However, a client that requests resumption of a session does not in general know whether the server will accept this request, and therefore it SHOULD send an extended client hello if it would normally do so for a new session. If the resumption request is denied, then a new set of extensions will be negotiated as normal. If, on the other hand, the older session is resumed, then the server MUST ignore extensions appearing in the client hello, and send a server hello containing no extensions; in this case the extension functionality negotiated during the original session initiation is applied to the resumed session. The intent of this restriction (that "the server MUST ignore extensions appearing in the client hello, and send a server hello containing no extensions" when a session is resumed) was that it would potentially simplify security analysis of TLS, by justifying an assumption that the extension-based options used in a session stay the same across resumptions (see <http://thread.gmane.org/gmane.ietf.tls/429>). It wasn't intended (at least not by me, as one of the authors of RFC 3546) to preclude the definition of extensions that are specifically designed to affect renegotiation. But since it could be interpreted that way, I think that the draft should explicitly clarify this point. Another issue is that a server that supports the extension can refuse the renegotiation. The current draft is not clear about what the client and server behaviour should be in that case. Suggestion: If a ClientHello that is requesting to resume a previous session contains a Renegotiation_Info extension, and the server supports the extension but wishes to refuse the renegotiation, it SHOULD reply with a zero-length Renegotiation_Info. If a client that is requesting to resume a session receives a zero-length Renegotiation_Info without a no_renegotiation alert, it MUST abort the handshake. If it receives both a zero-length Renegotiation_Info and a no_renegotiation alert, then the fact that the Renegotiation_Info contents do not match the previous session's verify_data values should not be considered a reason for the client to abort. Note that one legitimate reason for refusing a renegotiation is that the old session has expired, in which case the server is likely to have forgotten the client and server verify_data values for that session. Nevertheless it SHOULD reply with a Renegotiation_Info to indicate that it supports the extension. For the same reason, when the server refuses a renegotiation it may not have the ability to check that the contents of the client's Renegotiation_Info were correct. Therefore, there should be no requirement for the server to check the contents in that case. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
- [TLS] Comments on draft-rescorla-tls-renegotiate.… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Michael D'Errico
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Martin Rex