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

Yaron Sheffer <yaronf.ietf@gmail.com> Wed, 25 September 2013 17:47 UTC

Return-Path: <yaronf.ietf@gmail.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 AEDEF21F99DC for <tls@ietfa.amsl.com>; Wed, 25 Sep 2013 10:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.486
X-Spam-Level:
X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 1ZLOcT6XZ0lq for <tls@ietfa.amsl.com>; Wed, 25 Sep 2013 10:47:51 -0700 (PDT)
Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id CA29F21F96B1 for <tls@ietf.org>; Wed, 25 Sep 2013 10:47:48 -0700 (PDT)
Received: by mail-ea0-f176.google.com with SMTP id q16so3369306ead.35 for <tls@ietf.org>; Wed, 25 Sep 2013 10:47:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=MLRo5GU0pVyyahRC/umr9flwKyoie1fvttF9Sey6G54=; b=IFP8z7eNdmP/jUF0HkCW7EMM6PPM9ovNGEoneMTAEg9/49ojlqi1fqxRg3gFUWqUjA Fu5QhHgqiTlBp7K04PFsWsA73YXN3PMVBZ1J7sEbM1iVyoUJTA5mLgAKbSt7XO9zgkw0 rjrDrXuRQpCp+XrPdXjtL9X2NQhe0uBUEZWRk5holvQjbZC4wWE29nLSsZ9XH8t7lbOg +PffJLelIGq0WMZxonSPkB244PG1kFkHhnOR7GGOm0J4jrNW5k7TLu2ltqCs6Bt0UUGh +ws7a36Ag5H7CeaL9HYTwa5oMNZgMxKi4nuMpSLxvrqUBrcpwrwFMZB6WYUayDEFeRZY kclg==
X-Received: by 10.14.224.198 with SMTP id x46mr5903567eep.53.1380131267749; Wed, 25 Sep 2013 10:47:47 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id x47sm68035400eea.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Sep 2013 10:47:47 -0700 (PDT)
Message-ID: <524321C1.5080001@gmail.com>
Date: Wed, 25 Sep 2013 20:47:45 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Michael D'Errico <mike-list@pobox.com>, Adam Langley <agl@imperialviolet.org>
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz> <CADMpkcJtp-+P8CFn_K7uptXtorYom0ALdaUn6xB16JFZSHoBtg@mail.gmail.com> <CAMfhd9U2eBdeO4MuDBW9hcuxzu0sttkifySSHJp9=bm5n3NNEg@mail.gmail.com> <5243119D.4070001@pobox.com>
In-Reply-To: <5243119D.4070001@pobox.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "<tls@ietf.org>" <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 17:47:51 -0000

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.

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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls