Re: [Hipsec] IPCOMP support in HIP

Robert Moskowitz <rgm@htt-consult.com> Thu, 10 March 2016 20:13 UTC

Return-Path: <rgm@htt-consult.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825AB12DCA9 for <hipsec@ietfa.amsl.com>; Thu, 10 Mar 2016 12:13:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 JT17FXz3JVEH for <hipsec@ietfa.amsl.com>; Thu, 10 Mar 2016 12:13:33 -0800 (PST)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6604412DCA8 for <hipsec@ietf.org>; Thu, 10 Mar 2016 12:13:33 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 77BDD6220D for <hipsec@ietf.org>; Thu, 10 Mar 2016 15:13:32 -0500 (EST)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gv+EkvECL8sg for <hipsec@ietf.org>; Thu, 10 Mar 2016 15:13:27 -0500 (EST)
Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2A3D16220C for <hipsec@ietf.org>; Thu, 10 Mar 2016 15:13:27 -0500 (EST)
To: hipsec@ietf.org
References: <56E03F56.5040300@htt-consult.com> <56E176AB.5070709@htt-consult.com> <20160310191041.GA14546@cowbell.employees.org>
From: Robert Moskowitz <rgm@htt-consult.com>
Message-ID: <56E1D565.5060605@htt-consult.com>
Date: Thu, 10 Mar 2016 15:13:25 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <20160310191041.GA14546@cowbell.employees.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/E0kmWJ1j7srZb7nAMXbvZRgCVPk>
Subject: Re: [Hipsec] IPCOMP support in HIP
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2016 20:13:34 -0000

I have looked at both the CRIME and BREACH attacks and neither would 
work against IPCOMP within ESP.  TLS and HTTP compression are softly done...

It DOES change some of my thoughts about compression as a XML option for 
use in DOTS.  That is pretty much what CRIME is attacking. Rather you 
have to take your outer envelope that contains your XML and compress the 
whole thing.

On 03/10/2016 02:10 PM, Derek Fawcus wrote:
> On Thu, Mar 10, 2016 at 08:29:15AM -0500, Robert Moskowitz wrote:
>> I have found comp in TLS, RFC 3749, so HIP's ESP is the only one missing
>> compression.  How did I miss that?  It should have been included in 7402
>> as an option within ESP.
> Hasn't use of compression with TLS largely been abandoned now?
> Simply because one or more of the recently published exploits depended upon
> it,  such that now one is recommended to disable compression?
>
> So if TLS is avoiding compression,  why is normal IPsec still using it?
> It is because the compositions of compression and encryption used in IPsec
> are safe,  or has no simply tried (or not published) such attacks for IPsec?
>
> DF
>