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

Michael D'Errico <mike-list@pobox.com> Wed, 25 September 2013 18:57 UTC

Return-Path: <mike-list@pobox.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D8D21F9CC6 for <tls@ietfa.amsl.com>; Wed, 25 Sep 2013 11:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level:
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfnkBPRiSEZb for <tls@ietfa.amsl.com>; Wed, 25 Sep 2013 11:57:06 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 95B2921F9D38 for <tls@ietf.org>; Wed, 25 Sep 2013 11:56:53 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 5C370DE94; Wed, 25 Sep 2013 14:56:50 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; 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; d=pobox.com; 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 a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 52AB6DE93; Wed, 25 Sep 2013 14:56:50 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 6CE8CDE92; Wed, 25 Sep 2013 14:56:49 -0400 (EDT)
Message-ID: <524331F0.1090905@pobox.com>
Date: Wed, 25 Sep 2013 11:56:48 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Yaron Sheffer <yaronf.ietf@gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz> <CADMpkcJtp-+P8CFn_K7uptXtorYom0ALdaUn6xB16JFZSHoBtg@mail.gmail.com> <CAMfhd9U2eBdeO4MuDBW9hcuxzu0sttkifySSHJp9=bm5n3NNEg@mail.gmail.com> <5243119D.4070001@pobox.com> <524321C1.5080001@gmail.com>
In-Reply-To: <524321C1.5080001@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 3BD9C9FC-2614-11E3-B651-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: tls@ietf.org
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 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
client.

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

Mike



> 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 <bmoeller@acm.org> 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