Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Peter Gutmann <pgut001@cs.auckland.ac.nz> Fri, 11 November 2016 07:10 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 11C98129A0D for <tls@ietfa.amsl.com>; Thu, 10 Nov 2016 23:10:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.697
X-Spam-Level:
X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 2Sn0W25Xe2c0 for <tls@ietfa.amsl.com>; Thu, 10 Nov 2016 23:10:16 -0800 (PST)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1D1129519 for <tls@ietf.org>; Thu, 10 Nov 2016 23:10:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1478848215; x=1510384215; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ehxfls3zax88IO4E4x4SFcukwTnAiO81AuGzNkzoi8E=; b=QCHADdIrBFDB0i4+cROMgauvgASpoPmcDO0Hra91WA5fiWwc8UFMHDUD 7s5YpOl+Jjjairq8WauEo+baU/HR4Aiyw5aind42/scYWGaKRt391Z8/s h1dwkfeDKr3dNVosy69u+28eGcfY5OkEbLwQgCVnZZBfGKyuXWyPlcIJh RB0i4hMMRKamOnmHvKaCXc+htoGADRQ7L6sXPaLnllKOBiJWEgLD67fH9 +d22vtEhlBjnBfWsAgrfCVCMUmYMRSk3UHjhRaXiYgKMYv72tTs1A6LAH akv4kJ53I5KGZNfEyozdNGxyleQZTBjUayPxlISzBGg+nIWMWAssZXodn g==;
X-IronPort-AV: E=Sophos;i="5.31,620,1473076800"; d="scan'208";a="114726594"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing
Received: from uxcn13-ogg-b.uoa.auckland.ac.nz ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Nov 2016 20:10:10 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 11 Nov 2016 20:10:10 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Fri, 11 Nov 2016 20:10:10 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Benjamin Kaduk <bkaduk@akamai.com>, "mrex@sap.com" <mrex@sap.com>
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
Thread-Index: AQHSOdR09JVOl87da0itkD0J6z/Dh6DOi14AgAD/HACAAH7egIAACk2AgAGINYCAAAIugIABw0Qj
Date: Fri, 11 Nov 2016 07:10:09 +0000
Message-ID: <1478848205508.80812@cs.auckland.ac.nz>
References: <58fd43a5-fd20-b93c-fae0-845646a8062f@akamai.com>, <20161110171353.37D451A57D@ld9781.wdf.sap.corp>
In-Reply-To: <20161110171353.37D451A57D@ld9781.wdf.sap.corp>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mEbZiGwP_4_6yGgNWhDahZ-HALs>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 11 Nov 2016 07:10:23 -0000

Martin Rex <mrex@sap.com>; writes:

>There is a concept called "provable correctness", 

The problem with provable whatever is that it merely proves that, as far as
the provers can tell, the thing they're dealing with conforms to some abstract
model.  I don't think you can prove much about whatever hiding the ContentType
is supposed to achieve because there's no model for it that says, for example,
"for an attacker with these capabilities, under these conditions, the
following security guarantees are provided".

However, we do have a pile of empirical data showing that pretty much any
seems-like-a-good-idea traffic-hiding really only works until the moment
someone tries to attack it.  The best reference for this is "Peek-a-Boo, I
Still See You: Why Efficient Traffic Analysis Countermeasures Fail" by Dyer et
al.  So at the moment I'd say that if there's some measure that's completely
free (no downsides for anything else) then you may as well apply it because it
can't make things any worse, but not to say "let's do X because it seems like
a good idea" when it has no empirically-demonstrable benefit but lots of
drawbacks.

And it's the "empirically-demonstrable" that's important, Peek-a-Boo is chock
full of examples of things that seemed like a good idea but that don't
actually provide much, if any, benefit, while at the same time introducing all
sorts of downsides.

Peter.