Re: [TLS] Analysis of encrypting the headers - what is the length
Bryan A Ford <brynosaurus@gmail.com> Sun, 06 December 2015 09:22 UTC
Return-Path: <brynosaurus@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F421A88A9 for <tls@ietfa.amsl.com>; Sun, 6 Dec 2015 01:22:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7E9nCYl_QOy for <tls@ietfa.amsl.com>; Sun, 6 Dec 2015 01:22:01 -0800 (PST)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0081A88B2 for <tls@ietf.org>; Sun, 6 Dec 2015 01:21:55 -0800 (PST)
Received: by wmec201 with SMTP id c201so127472765wme.0 for <tls@ietf.org>; Sun, 06 Dec 2015 01:21:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=4NLqfl+7ZF0a7dZ2Fmolqltjhg99Re/jexBBjmpQuT4=; b=BW1VFVbqszMosQV9dJShhGbDaZs+vYC6U69pDmqH9i6L3dEcHj2bbRcLYDOmFdUGLm ABMwFKX0E0FQ+ttn5igHx0kbM6FBGxO43Zji0whDCDTXRKln8XTldwm1F+mZFuF8Cw9x ScsaE8IUQ/MLc9FKu4GaKm7OcgV2+2/EP+zwL0MrueKv7/ewPB4OB6wp7gPOmrP1u3vK hWZ6OtP31D/LWv98zFtP2qMr/jvoRGQEy9AIOE/QnPxaSJw1I1OENbcBCj6APLWTpdb0 570xlHKkCfHHfSzHX53XGbzCzz8ybhCB+lrv+vcfiTWvMpxMGcdYyEAujeNVT+VEi7zk vLxw==
X-Received: by 10.195.18.6 with SMTP id gi6mr29199778wjd.83.1449393713521; Sun, 06 Dec 2015 01:21:53 -0800 (PST)
Received: from proz.dclient.lsne.ch (85-218-12-53.dclient.lsne.ch. [85.218.12.53]) by smtp.gmail.com with ESMTPSA id h4sm19702769wjx.41.2015.12.06.01.21.51 for <tls@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Dec 2015 01:21:51 -0800 (PST)
To: tls@ietf.org
References: <11f501d12ed6$41150270$c33f0750$@augustcellars.com>
From: Bryan A Ford <brynosaurus@gmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <5663FE47.1050106@gmail.com>
Date: Sun, 06 Dec 2015 10:22:15 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <11f501d12ed6$41150270$c33f0750$@augustcellars.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms090702080005030704040406"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/o5p5LrBV0CY4Ux8cfa34YBXTvJM>
Subject: Re: [TLS] Analysis of encrypting the headers - what is the length
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 06 Dec 2015 09:22:07 -0000
On 12/4/15 9:56 PM, Jim Schaad wrote: > I will start by re-iterating my initial position that I would prefer that > the DTLS and TLS analysis is going to be the same in terms of masking the > header information. So I decided to do some thought experiments about what > happens if the length were to be encrypted and how many different situations > does this not appear to help the situation. Why are you fixated on enumerating different situations where encrypting headers doesn't help, while completely ignoring situations where it can help? You could draw up an infinite list of scenarios in both categories. No security provision will address every possible attack scenario - padding definitely doesn't either! - but both header encryption and padding are complementary provisions that each make attacks more difficult for attackers in different ways. B
- [TLS] Analysis of encrypting the headers - what i… Jim Schaad
- Re: [TLS] Analysis of encrypting the headers - wh… Christian Huitema
- Re: [TLS] Analysis of encrypting the headers - wh… Bryan A Ford
- Re: [TLS] Analysis of encrypting the headers - wh… Jim Schaad