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

Yaron Sheffer <yaronf.ietf@gmail.com> Wed, 25 September 2013 19:26 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 D635521F9E50 for <tls@ietfa.amsl.com>; Wed, 25 Sep 2013 12:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.494
X-Spam-Level:
X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 ttSKzydjLbWf for <tls@ietfa.amsl.com>; Wed, 25 Sep 2013 12:26:43 -0700 (PDT)
Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5C83A21F9E46 for <tls@ietf.org>; Wed, 25 Sep 2013 12:26:36 -0700 (PDT)
Received: by mail-ea0-f174.google.com with SMTP id z15so57455ead.5 for <tls@ietf.org>; Wed, 25 Sep 2013 12:26:34 -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=DFTgUCqkc1MEkikD629OlNB7yO7GzW9oxTKB9kaD22c=; b=v4/rYgh53XXDZGe00jF6zOL4CN+n/0sCOn7+jh2l5xo07h2avPUmCxTHBNr/6Xc4el dm74jk0XkfTFzHTd8wlA8Rl2Ng6r6+g3CuUIv1xh2cLIvYa50lg7kNi4a8yx76qe+TJm EHEwnBX/OaN8uSNovD0QBClGeGCOlzDsxV9TeNGQe6NKU3hoHgO/WcIX0cKQiXu6lUY3 ZX8BrH5fGOmA/Or4LMC27O+7dTmh+J5aIq1RkC/84iJrc9ouOCww59xzWjiLAyH5UH7o PMZNxVUfavXyfpRU7M8HuatDArSBgU5207gpzXIkUIbIfVDJTjNAutmUOYhiKpV8XQy+ xiQg==
X-Received: by 10.15.45.8 with SMTP id a8mr57778076eew.1.1380137194712; Wed, 25 Sep 2013 12:26:34 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id f49sm68919421eec.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Sep 2013 12:26:34 -0700 (PDT)
Message-ID: <524338E8.6010300@gmail.com>
Date: Wed, 25 Sep 2013 22:26:32 +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: Bodo Moeller <bmoeller@acm.org>
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> <CADMpkcLGRCORoqUTX45hXF5JqqFS-GTW+YzZ7XEKW-5rAFdbGg@mail.gmail.com>
In-Reply-To: <CADMpkcLGRCORoqUTX45hXF5JqqFS-GTW+YzZ7XEKW-5rAFdbGg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; 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 19:26:44 -0000

It's one thing to "detect" these cases. Such detection is probably more 
effective on the server side, where there are admins that look at log 
files. I agree we should be providing both sides with the information.

It's another thing to recommend that servers always drop such 
connections. I don't think we should do that.

Thanks,
	Yaron

On 09/25/2013 10:00 PM, Bodo Moeller wrote:
>
>     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?
>
>
> Certainly, because we don't know if "the organization" that's trying to
> downgrade your connection are your local network admins, or a foreign
> government agency.  This doesn't mean there couldn't be a knob allowing
> you (or your admins) to disable the security check, but the protocol
> should have means to detect this kind of problem.
>