Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC
Pekka Nikander <pekka.nikander@nomadiclab.com> Wed, 30 May 2007 08:20 UTC
Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJQ0-0008Lk-UC; Wed, 30 May 2007 04:20:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJPy-0008JM-A3; Wed, 30 May 2007 04:20:30 -0400
Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtJPx-0003dQ-RW; Wed, 30 May 2007 04:20:30 -0400
Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0E58F212E13; Wed, 30 May 2007 11:20:28 +0300 (EEST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id A2AE3212DFC; Wed, 30 May 2007 11:20:27 +0300 (EEST)
In-Reply-To: <Pine.LNX.4.64.0705292246010.10757@netcore.fi>
References: <E1Hnaws-0006TN-7V@stiedprstage1.ietf.org> <Pine.LNX.4.64.0705290821170.13396@netcore.fi> <6498B3B5-3627-4959-9051-3C288647C97D@nomadiclab.com> <Pine.LNX.4.64.0705292246010.10757@netcore.fi>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <1E351801-AD14-4F2D-9ACD-1357D855EF3F@nomadiclab.com>
Content-Transfer-Encoding: 7bit
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
Date: Wed, 30 May 2007 11:20:26 +0300
To: Pekka Savola <pekkas@netcore.fi>
X-Mailer: Apple Mail (2.752.3)
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: hipsec@ietf.org, ietf@ietf.org
Subject: Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org
>>> 1) what if HIP RRs are not queried first? > > I have personally no big problems if the spec were to say that "HIP- > after-A-or-AAAA" were to be left out of scope of this document. > > However, what I'm a bit uncomfortable with is that this assumption > is apparently made in Section 3, "Usage Scenarios", which seems to > be a section with no normative content. As such I believe such a > statement/assumption (if made) should be made in a more prominent > place in the spec. A suitable restriction of the scope, at an appropriate place, would be fine with me. >>> 3) a premature optimization of HIT lookup tags >>> >>> Upon return of a HIP RR, a host MUST always calculate the HI- >>> derivative HIT to be used in the HIP exchange, as specified in >>> Section 3 of the HIP base specification [I-D.ietf-hip-base], >>> while >>> the HIT possibly embedded along SHOULD only be used as an >>> optimization (e.g. table lookup). >>> .. and in section 8.2: >>> >>> [...] This is why a HIP >>> end-node implementation SHOULD NOT authenticate its HIP peers >>> based >>> solely on a HIT retrieved from the DNS, but SHOULD rather use HI- >>> based authentication. >>> ==> this seems like a premature optimization. >> >> Note that these RRs may need to be indexed also by other boxes but >> the end-nodes. For them, using the HIT as an index and doing a >> simple memory comparison instead of calculating a hash may be a >> win. Further note that both the sections you quote above discuss >> only host/end-note behaviour. > > This is makes me even more afraid. If most end-nodes use mechanism > A but others are expected to maybe use another mechanism B, I > foresee problems with both mechanisms especially in middleboxes. > It certainly won't improve the reliability of the protocol.. So, maybe add a paragraph about the usability of the HIT for middle boxes. IIRC, the context of discussion was HIP-aware firewalls. Such firewalls could simply snoop HIT RRs as they pass by (or even query them if there is a suitable reverse DNS hierarchy, which the draft does NOT specify, IIRC). Then, when they see HIP I2/R2 packets passing by, they could use the cached keys, as indexed by the HITs, to verify the signatures in the messages. For such use, I don't see any need of verifying the cryptographic relationship between the HIT and HI. If the signatures in the I2/R2 don't match, then the firewall doesn't open the connection, and it is the user's problem. No security dangers, AFAICS. Indeed, it would be beneficial if the firewall did NOT try to establish any crypto relationship between the HIT and HI, since that would allow the relationship to evolve without mandating firewall code updates. >>> 2) what are the threats if HIT is used as-is without >>> hash-checking (as allowed by the spec at the moment) when a) the >>> DNS-HIT >>> points to something used by another HI, and b) the DNS-HIT >>> doesn't exist. >> >> I don't understand what you are saying here. > > Maybe I was trying to be too terse or I'm missing an assumption > about how HIT vs HI is validated in other parts of HIP infrastructure. > > Let's say I publish a HIPRR with HIT=hash(Y) and HI=X. Someone else > has HI=Y, and I choose HIT above so that HIT=hash(Y), i.e., create > an intentional conflict. > > Given that the spec does not mandate that the implementations check > that HIT will correspond to the HI, what's going to happen in this > case? You will fail to gain the channel binding property of HIP. In other words, you shoot to your own foot. > Will a middlebox overwrite the index at hash(Y) with HI=X? If yes, > what is the result? Will it be a DoS on the host that used HI=Y? Well, nothing if the middlebox is implemented correctly. HIT collisions are possible, anyway. Hence, in such a case the middlebox should cache both HI=X and HI=Y, indexed by the HIT. The fact that HIT!=hash(X) shouldn't matter. --Pekka _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: Last Call: draft-ietf-hip-dns (Host Identity … Pekka Savola
- Re: Last Call: draft-ietf-hip-dns (Host Identity … Stephane Bortzmeyer
- Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (H… Pekka Nikander
- Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (H… Pekka Savola
- Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (H… Pekka Nikander