Re: [dane] Bootstrapping IPSec from DNSSSEC/DANE

Alex Maurin <coyo@darkdna.net> Tue, 01 October 2013 23:00 UTC

Return-Path: <coyo@darkdna.net>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77AE1F0EE6 for <dane@ietfa.amsl.com>; Tue, 1 Oct 2013 16:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level:
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
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 2uEK5DqzBEjA for <dane@ietfa.amsl.com>; Tue, 1 Oct 2013 16:00:21 -0700 (PDT)
Received: from ryujin.darkdna.net (ryujin.darkdna.net [69.164.196.21]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD1F21F9C12 for <dane@ietf.org>; Tue, 1 Oct 2013 15:59:59 -0700 (PDT)
Received: from localhost (otohime.ddna [172.16.0.13]) by ryujin.darkdna.net (Postfix) with ESMTP id 3cqGCJ3D7pz4w3D for <dane@ietf.org>; Tue, 1 Oct 2013 17:59:56 -0500 (CDT)
X-Virus-Scanned: amavisd-new at darkdna.net
Received: from ryujin.darkdna.net ([172.16.0.1]) by localhost (otohime.darkdna.net [172.16.0.13]) (amavisd-new, port 10026) with LMTP id a9c6wDE0cdEY for <dane@ietf.org>; Tue, 1 Oct 2013 17:59:54 -0500 (CDT)
Received: from smtp-auth.darkdna.net (smtp-auth.darkdna.net [2600:3c00::2:f123]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: coyo@darkdna.net) by ryujin.darkdna.net (Postfix) with ESMTPSA id 3c qGCG2Xblz4vyk for <dane@ietf.org>; Tue, 1 Oct 2013 17:59:53 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=darkdna.net; s=mail; t=1380668394; bh=aLVuymxsgUiI6txp/R1bQ92kGqSI8NqhByin/OKT2lM=; h=Date:From:To:Subject:References:In-Reply-To; b=NZlSNYcNwzrNJc6M5XNkqBK/O2VR4x//XGzjHLWsQMvZEQTjGTVYgEHpIlrty2j28 uBKN3qQFe02XhwhVrDC3PHkwoOD7Wn36APWTwPjsLYH23+BI3DUYJ1HRNEUnvO0J2i I/WAAHoOiPgMJrfcV64ozTQEel9mBeSFqGnDVAbk=
Message-ID: <524B53E2.1040205@darkdna.net>
Date: Tue, 01 Oct 2013 17:59:46 -0500
From: Alex Maurin <coyo@darkdna.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: dane@ietf.org
References: <7039763.53681380486188849.JavaMail.www@wwinf3715>
In-Reply-To: <7039763.53681380486188849.JavaMail.www@wwinf3715>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [dane] Bootstrapping IPSec from DNSSSEC/DANE
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Oct 2013 23:00:32 -0000

On 9/29/2013 3:23 PM, david.lloyd@fsmail.net wrote:
> There's not much to it...  Basically, we have three independent groups who have certificate-based IPSec (on IPv6), and now they'd like occasionally to connect to each other.  The obvious solution is to cross-sign certificates, but we have also recently implemented DNSSEC, so I was wondering if there was a better/another way.  Or maybe: I have a shiny new hammer called DNSSEC, and a lot of things are starting to look like nails.

I think the same.

DNSSEC, especially combined with DANE, makes a lot of things begin to 
look like nails.

A nice example, when combined with PGP-DNS and IPsec, would be trivial 
VoIP encryption.

> In terms of getting IPSec based off DNSSEC, the two RFCs 4025 and 4322 actually do pretty much what I want (plus or minus that it'll look very different to the way I am configuring TLS DANE).  I am going to see if I can get those to work.
>
>
> For the other things that were talked about:
>
> Mobile devices and NATs	- It is	true that reverse lookup is inappropriate for these scenarios, but ultimately this is just a rejig of the problem that the incoming ipaddress is not particularly useful in these scenarios.  If a server wishes to verify such connecting clients, it'll have to choose something else as an identifier (and thus it falls back into the traditional CA/Kerebros setup)
>
> Reverse	DNS being poorly supported by iSPs - To	be honest, this	is less	of a problem for me as I only have an internal deployment, so I can do that I like (in-addr.arpa is ultimately just a convention, anyone could run a reverse DNS system that actually works properly).  Most of my ip addresses are not routable from the public internet anyway.  It did lead me to the somewhat more philosophical question of what it means to "own" an ipaddress if I can't associate my public keys with a secure central registry...
Where did you get a silly idea like that? Obviously ICANN and the 
largest carriers own them.

If we based IP ownership on SHA-3-512 hashes of PGP certs, however... 
but I doubt anyone would go along with that.

> So I think that	the answer is that I can do this with existing technology, with some basic restrictions in that I'll need to be running my own reverse DNS lookup for my deployment - which seems entirely sensible as I want to have control over which ip addresses "exist" in my environment.
This sort of thinking makes me reconsider the concept of community 
petnaming.