Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03

"Valery Smyslov" <svanru@gmail.com> Fri, 02 September 2016 18:46 UTC

Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EF31288B8 for <ipsec@ietfa.amsl.com>; Fri, 2 Sep 2016 11:46:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.59
X-Spam-Level:
X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: DNS error: query timed out)" header.d=gmail.com
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 ey6rz1b0fkwU for <ipsec@ietfa.amsl.com>; Fri, 2 Sep 2016 11:45:49 -0700 (PDT)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 B0E05126B6D for <ipsec@ietf.org>; Fri, 2 Sep 2016 11:45:48 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id p41so71304179lfi.1 for <ipsec@ietf.org>; Fri, 02 Sep 2016 11:45:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=9cnzlFliZoH7Q703KdhkOlKylP+/lB8WDz2OZBqfPUw=; b=SVsrWyiWf1SkmfNog/bDTtw5xNWz617G3VVbx0VgpIa0VaDUl6JBdl4lgtW1iGaucO 8+UTmbf+mCMW5u0d3P+LquEmgkV09DsJL55QnoR7HO4V+XXmTZL80DmTo4ZjXP2yi/ZG wPwOqoF63DNMnkqQzeR1e23rVeXqTRy3ORt+/36MtEAXbQ9FMM/U1fumrwwU8Y5E+aww T0zXGN8SXXLA0ojsyi1JL35qAkT1E6UXchku9IlRJNCE5SrWupxBG7mzldQATcM74ly/ jHxjmXVwr/FEDnkvEcwyYT0/RMWJ12GscrdGHSX9oRYhUpGa0ata/Fff2aqEko5c1JxM DlsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=9cnzlFliZoH7Q703KdhkOlKylP+/lB8WDz2OZBqfPUw=; b=bVcJ2Bd4WTe1z9dwpP5gWqapTrqbt1OV/YNFybZUGeEYyxlPRA3O7gF4KOPBPSgjNM j9pSX5RWmvX0seVtU5Gxk+EDWViBxNPfobheWcVd2AnX3vPI0Vu0vYtwxQL19x6BFbVV 2gVLjkmd5HhIQvQ09xZCbhRJfx5anlyZ61qLhRj61IWaqiSdS7JTF4Uwovi1fGq1GkaP HdDN5BmCLSxgudGfwzaTpzLXD2ti7oPol3l/y/MMFQCfQg7Lz/lfrGVegenGsmj/dprB LzG+6IMce26+PeV+n+7oxOSrB7bheUZ5ecb/2DC+WfCepKlqXfHFnjivq+dQPey6F6Xm 9rlQ==
X-Gm-Message-State: AE9vXwOzvHBe+YfjsnY/KT2Gf3hyBT/xDYXH0IVM2GDCrrdg8czZNYOoKvN41cP5tHQr0A==
X-Received: by 10.25.162.17 with SMTP id l17mr6349044lfe.125.1472841946804; Fri, 02 Sep 2016 11:45:46 -0700 (PDT)
Received: from chichi (ppp83-237-163-119.pppoe.mtu-net.ru. [83.237.163.119]) by smtp.gmail.com with ESMTPSA id 89sm141535lfq.39.2016.09.02.11.45.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 02 Sep 2016 11:45:46 -0700 (PDT)
Message-ID: <9CFB7B2AECC942E5A955BDE66B64E9DE@chichi>
From: Valery Smyslov <svanru@gmail.com>
To: Paul Wouters <paul@nohats.ca>, Yaron Sheffer <yaronf.ietf@gmail.com>
References: <alpine.LRH.2.20.1609012243220.29817@bofh.nohats.ca> <860ec25d-033d-b12d-541c-423caf3803d7@gmail.com> <16FF5F35-21F7-4789-84CF-5BB99645B13B@nohats.ca> <7e5bc7f3-9fe5-aa54-1d2f-be7da324250d@gmail.com> <E61A523F76664C3CADE5BB495F003AE1@buildpc> <e6d2a06d-76da-7be8-cfc3-246d0c4b1344@gmail.com>
In-Reply-To: <e6d2a06d-76da-7be8-cfc3-246d0c4b1344@gmail.com>
Date: Fri, 02 Sep 2016 21:45:40 +0300
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"; reply-type="response"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/d7coF3oqeVEZLH5WROVkj22s-9E>
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Sep 2016 18:46:13 -0000

> Hi Valery,
> 
> Yes, these are lossy algorithms, but the TLS/HTTP attacks are all with 
> lossless algorithms. And as far as I know, they are applicable to any 
> situation where here is an attacker that can force traffic on the wire, 
> mixed with other, non-attacker controlled traffic. So IMO they are not 
> restricted to just HTTP.

The attacks using compression known to me (e.g. CRIME) rely on the ability
for an attacker to observe the difference in the length of messages (caused by applying 
compression) after each attempt. However, in case of ESP there are obstacles for doing that. 
First, ESP has a mandatory padding that is applied even in case of stream ciphers
(in this case the packet is aligned to a 4 bytes boundary). This makes it more
difficult for an attacker to catch a difference in lengthes. Then, ESP includes
an optional TFC padding feature that makes the above attack infeasable, because each
ESP packet will have either the same size or randomly adjusted size.
And ESP compression could help applying TFC padding without consuming
considerable anount of additional bandwidth.

Regards,
Valery.

> Thanks,
> Yaron