Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

Kyle Hamilton <> Tue, 12 January 2010 23:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D37A73A68D1 for <>; Tue, 12 Jan 2010 15:55:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NDkww9ewwj0b for <>; Tue, 12 Jan 2010 15:55:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B65193A68CB for <>; Tue, 12 Jan 2010 15:55:37 -0800 (PST)
Received: by pzk32 with SMTP id 32so553214pzk.29 for <>; Tue, 12 Jan 2010 15:55:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RavlNcC6zDkrlpFm0XvVnWVJyrhABA8E5tC5VwABcYA=; b=aL5uVdibsvnj8FzMdUNrJSL6IxFgzgz/Pls/OH6dRAQ5bgG86ecRHHqpjYrHoSnSP+ kFQ/NZbNG7wm7j9eD06/5lnGgcYd3vHlv2xsTCy1MEhuNHN5stKGSYwqzBxX4Ww18gci PGNGUl1ARSIC3iwsm6Yu9KB9ZGgbKp9N0Bfws=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=V3ja8IQvyYLarrnr2DLbXsMvfhTaU9ZuWHb8zhZAojh7nCdFCzPnV4KmUthfS7z4Nl 7WGyRO5ih+VLo8BLjgEwxQ4qQ/Ku6Q8s7o2KyGY3grtUP/DmaBIXojrgW3FQlOIAEvMs 2B8/eNjdGigAtQjjMqSfLjqIbKD3VVypXDB8E=
MIME-Version: 1.0
Received: by with SMTP id 41mr3117866wfg.117.1263340532464; Tue, 12 Jan 2010 15:55:32 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Tue, 12 Jan 2010 15:55:32 -0800
Message-ID: <>
From: Kyle Hamilton <>
To: Marsh Ray <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: DPKemp <>, tls <>
Subject: Re: [TLS] SCSV vs RI when both specified. Was: 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: Tue, 12 Jan 2010 23:55:38 -0000

The only way to prevent a reneg-naïve client from creating any
security risk to the server is to:
1) enforce the highest security that anything on that server requires
as a prerequisite to *all* connections to that server, and
2) use mutual authentication instead of only authenticating one side.

The requirement: An unauthenticated client that sends a command to the
server that requires it to have higher access credentials than the
connection has cannot cause the server to initiate a renegotiation.

Not meeting that requirement is what got us into the problem in the first place.

I join Marsh in dissenting to that "safely" message, as there is NO
way to safely renegotiate unless both sides are mutually authenticated
before the first bytes are received by the server process (as a client
of the TLS implementation, since the TLS implementation handles the
crypto part of the transaction).  Even then, that is only as far as
the identification doesn't change.

(Note: Firefox specifically disables HTTP pipelining over TLS
connections by default.)

-Kyle H

On Tue, Jan 12, 2010 at 11:55 AM, Marsh Ray <> wrote:
> Martin Rex wrote:
>> There is a document, approved by the IESG, where both of you are
>> listed as document co-authors, and it says this:
>> 4.3. Server Considerations
>> If the client does not offer the "renegotiation_info" extension or
>> the TLS_RENEGO_PROTECTION_REQUEST SCSV then this indicates that the
>> client does not support secure renegotiation.  However, because the
>> above attack looks like two handshakes to the server, the server can
>> safely continue the connection as long as it does not allow the
>> client to renegotiate.
>> I'm fine with that "the server can safely continue the connection as
>> long as it does not allow the client to renegotiate."
> I'm not, and I argued against the inclusion of that language repeatedly.
> The explanation I was given, IIRC, was that it was just referring to
> "the above attack" which was the one simplest case to explain. It was
> not supposed to be exhaustive of all attacks.
> I firmly believe that the language "the server can safely continue the
> connection as long as it does not allow the client to renegotiate" is in
> error.
> It was not worth continuing to argue about if it delays the
> implementation of the fix (which is the same in any case).
>> I don't want to continue discussing this issue.
> Agreed.
> I'll just have to make my point with working exploit code.
> - Marsh
> _______________________________________________
> TLS mailing list