Re: [Hipsec] additional comments on latest RFC5201-bis draft

Robert Moskowitz <rgm@htt-consult.com> Tue, 10 September 2013 20:01 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 27B6C11E8101 for <hipsec@ietfa.amsl.com>; Tue, 10 Sep 2013 13:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 3sUvpRNzz5H3 for <hipsec@ietfa.amsl.com>; Tue, 10 Sep 2013 13:01:03 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id CCD9C11E8125 for <hipsec@ietf.org>; Tue, 10 Sep 2013 12:59:57 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 4092C62A7A; Tue, 10 Sep 2013 19:59:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at localhost
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8F2AKb-yCFt; Tue, 10 Sep 2013 15:59:33 -0400 (EDT)
Received: from lx120e2.htt-consult.com (lx120e2.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id F29D76340F; Tue, 10 Sep 2013 15:59:29 -0400 (EDT)
Message-ID: <522F7A21.5040301@htt-consult.com>
Date: Tue, 10 Sep 2013 15:59:29 -0400
From: Robert Moskowitz <rgm@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Miika Komu <mkomu@cs.hut.fi>
References: <C018CAF7B620E64D87620E581C4E6BB9020D80@XCH-BLV-104.nw.nos.boeing.com> <522ED092.2070402@cs.hut.fi>
In-Reply-To: <522ED092.2070402@cs.hut.fi>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: HIP <hipsec@ietf.org>, "'Anders_Brandt@sigmadesigns.com'" <Anders_Brandt@sigmadesigns.com>
Subject: Re: [Hipsec] additional comments on latest RFC5201-bis draft
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 10 Sep 2013 20:01:05 -0000

On 09/10/2013 03:56 AM, Miika Komu wrote:
> Hi,
>
> On 09/09/2013 07:50 AM, Henderson, Thomas R wrote:
>> Last week I published a new version of RFC5201-bis:
>> http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-13
>>
>> This was mainly to address ID-nits and prepare the draft for the next 
>> stage of the review process. However, I also received a number of 
>> comments from Anders Brandt (cc'ed) on the version-12 draft. The 
>> purely editorial ones were included in version-13, but I decided to 
>> post a few for review on the list.
>>
>> In the interest of expediency, I'd like to suggest that we aim for 
>> resolving all of these within the next two weeks.
>>
>> 1) Section 4.1, the statement is made:
>>
>> "As a result, it is believed that the HIP opportunistic mode is at 
>> least as secure as current IP."
>>
>> Anders questioned what this statement means. Further clarifications 
>> are needed here.
>
> I would just suggest combining this sentence with the previous 
> paragraph. Alternatively, this could perhaps be rephrased as:
>
> As a result, opportunistic mode in HIP offers a "better than nothing" 
> security model. Initially, a base exchange authenticated in the 
> opportunistic mode involves a leap of faith subject man-in-the-middle 
> attacks, but subsequent datagrams related to the same HIP association 
> cannot be compromised by a new man-in-the-middle attack. Thus, it can 
> be stated that opportunistic mode in HIP is at least as secure as 
> unprotected IP-based communications.

+10000 :)

I really like this way of putting it. The MITM has one chance only and 
then must ALWAYS be in the middle. So maybe something else is needed 
that if the MITM "steps away", the attack is exposed after the fact?