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

Michael D'Errico <mike-list@pobox.com> Wed, 25 September 2013 16:39 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 4B9C321F9BC2 for <tls@ietfa.amsl.com>; Wed, 25 Sep 2013 09:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.565
X-Spam-Level:
X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 fwFzLQn58mrn for <tls@ietfa.amsl.com>; Wed, 25 Sep 2013 09:38:59 -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 70E9411E812C for <tls@ietf.org>; Wed, 25 Sep 2013 09:38:59 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 82F0FD336; Wed, 25 Sep 2013 12:38:58 -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=k/LYnYoMA6LJ ivFHr4uqdQrFH/w=; b=OQtoU+hXrPXl/jicVHjRWy9OD06IPrlilf0KeUqA1Vkw uQk2LtmqdQ5WKIiY4K+GfL/iFKVZc4X+5AhaJrVRRLSZLmk/0SlLyxID8OOON34q oCPV0XZ4QU31RTus2VTQHIIiZWTiXbcN4vr2d7u4olEl9bt9C9Xv3eRbYnPbMI0=
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=ETZlpg C+iJhGiHO4PklDOG09LPa/r7cuUN0DTYih2QS9WUtgfStFLnxfh5tyMhUO6kbhYZ sJYsJQeKaJ2HrYhry/Un0oIgDLjE/LzEC0MsUKR4goSgpKQbK3MPi1PF+RwVnWoV HK/VLkkdZanEOjD6R/F7PYmGif8Oa3dw/eCAM=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 6FE84D335; Wed, 25 Sep 2013 12:38:58 -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 894FED334; Wed, 25 Sep 2013 12:38:57 -0400 (EDT)
Message-ID: <5243119D.4070001@pobox.com>
Date: Wed, 25 Sep 2013 09:38:53 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Adam Langley <agl@imperialviolet.org>
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz> <CADMpkcJtp-+P8CFn_K7uptXtorYom0ALdaUn6xB16JFZSHoBtg@mail.gmail.com> <CAMfhd9U2eBdeO4MuDBW9hcuxzu0sttkifySSHJp9=bm5n3NNEg@mail.gmail.com>
In-Reply-To: <CAMfhd9U2eBdeO4MuDBW9hcuxzu0sttkifySSHJp9=bm5n3NNEg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: F972F088-2600-11E3-B10F-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
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 16:39:04 -0000

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