Re: [TLS] Updated draft

Michael D'Errico <> Fri, 18 December 2009 17:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E679C3A69D0 for <>; Fri, 18 Dec 2009 09:17:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A6Yt6UUyThIp for <>; Fri, 18 Dec 2009 09:17:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B2B363A6930 for <>; Fri, 18 Dec 2009 09:17:15 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id 83F1B8935C for <>; Fri, 18 Dec 2009 12:17:00 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=IWehX5Wm2pBL gmn2W85NWaoS/i4=; b=GPWW3m1qaS9axZ0261Wb88H45zkB5COGaG6blpq5bxK0 JurxFoxMbD3gEkkKRttmCr5RLmJD2TCBSURSBY66+hRMc0fGbSdYX0fmYeb8CnK2 y1zTNvdrjPDoLptIR2irEbkMXLr4FOZjVueEwYbWRflO7/gkQ4huV6qFEXFnG/4=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=GuNn17 uMua98ZE3aFdOSSz5SU5r5sMgBtzMOqBuNi7idR96wpMxEMXz434jHzUdCCIdB2o PIZPjsLdRzMzOpm/uYcTKP+zPPMZdgE4Sahw0i0VHzD7KPSFUopLNzRLTcKc6OSQ 8IJ6a0Pb/xVhQaMyFm1yrHBxXUnLGsz8Df4N8=
Received: from a-pb-sasl-quonix. (unknown []) by (Postfix) with ESMTP id 7E5668935B for <>; Fri, 18 Dec 2009 12:17:00 -0500 (EST)
Received: from administrators-macbook-pro.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id B70358935A for <>; Fri, 18 Dec 2009 12:16:59 -0500 (EST)
Message-ID: <>
Date: Fri, 18 Dec 2009 09:18:48 -0800
From: Michael D'Errico <>
User-Agent: Thunderbird (Macintosh/20090812)
MIME-Version: 1.0
To: TLS Mailing List <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 2734A368-EBF9-11DE-ADAE-DC0DEE7EF46B-38729857!
Subject: Re: [TLS] Updated draft
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Dec 2009 17:17:52 -0000

I disagree with Pasi and with the current wording in the draft.  That
was the reason I sent the message.  I'd like to see this changed.  I
have implemented the spec, and see that it creates a MUST NOT that is

The current draft suggests that if a server sees SCSV in cipher suites
and then sees RI in the ClientHello.extensions, it must abort the
handshake!  That is not necessary at all.  The RI simply overrides the
SCSV if it contains any data.  It is trivial for a server to handle
receiving both:

    - if SCSV is encountered, set a flag
    - if RI is encountered, set the same flag and extract the data

These happily coexist with no special cases, so requiring an abort is
not a good idea; it just adds complexity.

The problem appears to be the statement that SCSV is equivalent to an
empty RI, and thus would be a conflict if there was also an RI with
data.  This can be fixed by saying that SCSV is to be ignored when an
RI is also received.


Eric Rescorla wrote:
> At Thu, 17 Dec 2009 10:09:11 -0800,
> Michael D'Errico wrote:
>> s/signalling/signaling/g
>> In section 4 it says:
>>     Because the SCSV is equivalent to an empty "renegotiation_info"
>>     extension, any ClientHello used for secure renegotiation MUST include
>>     the "renegotiation_info" extension and not the SCSV.
>> I would rather see the text say that "an RI extension takes precedence
>> over the SCSV" than to say that you must not send SCSV when you send RI.
>> It is easier for a client to simply include SCSV in every ClientHello.
>> It is also trivial for a server to handle this, as I pointed out in my
>> last message.
> This implements the following point from Pasi's message.
>   - 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.
> It's of course possible I misunderstood.
> -Ekr