IETF Logo Mail Archive

Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard

Michael D'Errico <mike-list@pobox.com> Wed, 02 December 2009 20:25 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 6EF6C3A6964 for <tls@core3.amsl.com>; Wed, 2 Dec 2009 12:25:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.519
X-Spam-Level:
X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 DfyQvKFwJcnQ for <tls@core3.amsl.com>; Wed, 2 Dec 2009 12:25:21 -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 89C8A3A6829 for <tls@ietf.org>; Wed, 2 Dec 2009 12:25:21 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 67322A3BFE for <tls@ietf.org>; Wed, 2 Dec 2009 15:25: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=DRYfnwKMcH4A mMLrocCa5lMLN24=; b=obFe8XQRBTtvyiZ+fmlzkp4IGieVV/Et0VNkgfsK9j8k 6ZGIYCXEx7rOxa/XO8ZqPI55d9OGREN91wi5hwan4CYCloMa/PyCv33cVP0MQuus 2PVKR0/peDsxIQSBQeopQnndCMAN4XXrvc+EFFHMg9fTO6hpXszpNp9JZEtaSwA=
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=OqlSpf v1IVl0JfJrV210ida4tPCkd11q6mu14zatJVz96sdOs1rhh5EPJKSPI76VO+TexI JKGvNYBPbEnflVpIuypgGcCY42jJJUj6MRLaphbTUgK6sl6/OqneqJb6HZtqJJjI vCcrtuqgyv7WBaGJsIHZZXBEldyEP+ixhu3NQ=
Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 63478A3BFD for <tls@ietf.org>; Wed, 2 Dec 2009 15:25:13 -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 061ADA3BFC for <tls@ietf.org>; Wed, 2 Dec 2009 15:25:12 -0500 (EST)
Message-ID: <4B16CD84.7020109@pobox.com>
Date: Wed, 02 Dec 2009 12:26:44 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: tls@ietf.org
References: <20091130153734.D44C63A6AA9@core3.amsl.com> <4B13F367.6040307@extendedsubset.com> <20091202200849.B69636C4367@kilo.networkresonance.com>
In-Reply-To: <20091202200849.B69636C4367@kilo.networkresonance.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: CBAC8E86-DF80-11DE-B029-EF34BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com
Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard
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, 02 Dec 2009 20:25:22 -0000

Eric Rescorla wrote:
> 
>>>    TLS clients which support this draft MUST generate either the
>>>
>>>    "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST
>>>    cipher suite with every ClientHello.
>> Can they generate both?
>>
>> If not, what does the server do if he receives both?
> 
> I see several possibilities:
> 
> - One or the other and the server MUST abort if he receives both. 
> - Either or both on initial handshakes, but RI only on rehandshakes
> - RI MUST be present on rehandshakes. The MCSV MAY be present
>   but MUST be ignored.
> 
> The last of these would obviously require slightly altering the
> "exactly the same" rule, so seems less desirable, but really any
> of these are easy to do. I think my preference would be for the
> first.

Option 3 is clearly better.  If a client sends the proper data within
the RI extension, it seems silly for the server to abort the connection
because of the presence of the cipher suite marker.  It is also easier
for a client to always send the cipher suite value rather than have a
conditional code path.

Mike

v2.23.0 | Report a Bug | By Email