[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