Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt

Michael D'Errico <> Wed, 25 September 2013 18:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 65D8D21F9CC6 for <>; Wed, 25 Sep 2013 11:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PfnkBPRiSEZb for <>; Wed, 25 Sep 2013 11:57:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 95B2921F9D38 for <>; Wed, 25 Sep 2013 11:56:53 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 5C370DE94; Wed, 25 Sep 2013 14:56:50 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=LVAd3de9wbbV OiLN5vip5PzBI04=; b=lBkmobkKrOATJYwej3baheQIMyk4A49wIv+Uh6VjDxbs 4aQqisMseyKoQj3C0NEQbtjRrzWq8kOmPTD0f6txpULiAnSyQPrjrgSK9lZcGeoo N1gz6qHhuyDrw68wFhWJUdY7F7tAMTYbCmX27ZycanA0Fm+pyot7zm1Tqp62Tjk=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=T0dLBK SHvCWoNaLursNeyyFosf46DT/+rugDh4DhTwXg6N9sHj9uFwrLcO9UMtQmBmNhlN WPjZmYTaNA61ebaHdymg+KtLQkAbCZ1W7+KbuJP6x6FX892yqioH5HZOruZUqSP+ acdCh+YrPeYznSE3lkj/oul2F30Cwl91UfTH8=
Received: from (unknown []) by (Postfix) with ESMTP id 52AB6DE93; Wed, 25 Sep 2013 14:56:50 -0400 (EDT)
Received: from iMac.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6CE8CDE92; Wed, 25 Sep 2013 14:56:49 -0400 (EDT)
Message-ID: <>
Date: Wed, 25 Sep 2013 11:56:48 -0700
From: Michael D'Errico <>
User-Agent: Thunderbird (Macintosh/20100228)
MIME-Version: 1.0
To: Yaron Sheffer <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 3BD9C9FC-2614-11E3-B651-CE710E5B5709-38729857!
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-Mailman-Version: 2.1.12
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: Wed, 25 Sep 2013 18:57:11 -0000

Yaron Sheffer wrote:
> This discussion seems to really be about enforcing the following policy:
> If the client can speak TLS 1.X but the "network" (middlebox) only 
> allows TLS 1.Y, then, even though the server will happily negotiate TLS 
> 1.Y with other clients, it will reject this client and will not allow it 
> to connect from inside this network.

No.  A server that is happy to use TLS 1.Y wouldn't reject the clients
who first tried 1.X.  The discussion is about adding a mechanism for a
client to inform the server that it couldn't connect using a higher
version, and then also for the server to acknowledge that back to the

Such a mechanism would provide a way to detect problematic paths/routes,
i.e. middleboxes, and also any active downgrade attacks.


> Organizations often enforce weird and misguided policies on their users, 
> e.g. forcing them all to use IE6 so that "legacy applications" do not 
> need to be upgraded. Mind you, those older browsers only speak older 
> SSL/TLS versions and *their* connections will still go through! 
> Employing such middleboxes is just another policy of this type. Is it 
> really our business to counteract the organization's policy?
> Thanks,
>     Yaron
> On 09/25/2013 07:38 PM, Michael D'Errico wrote:
>> Adam Langley wrote:
>>> On Wed, Sep 25, 2013 at 7:03 AM, Bodo Moeller <> wrote:
>>>> So maybe the right fix to this kind of problem is to adapt an idea from
>>>> draft-rescorla-tls-version-cs-00 and create a signalling ciphersuite
>>>> value
>>>> that would *only* be used in SSL 3.0 connections by clients that have
>>>> downgraded, and tells the server "If you can read this, tear down the
>>>> connection because we shouldn't actually be using SSL 3.0 for this
>>>> connection"?
>>> (I think I would want such an SCSV to indicate TLS 1.2 support rather
>>> than TLS 1.0 support, but that's just a detail.)
>> Instead of particular versions, it seems to me that an indicator of "I
>> tried to connect using a higher version than I'm using now but had to
>> fall back to this verion" would cover any case now or later.
>> The server would respond with an extension value indicating whether it
>> intends to communicate over the channel using the negotiated version or
>> not.  (It may be OK with a TLS 1.2 -> TLS 1.1 downgrade, but not to 1.0
>> or SSLv3, for example.)  Both sides would continue the handshake through
>> completion to ensure that everything is legitimate.
>> Mike