Subject: Re: Install DNS mappings based on TLS/IPsec?

From: Brian E Carpenter <[email-masked]>
Date: Sun, 04 Jul 2004 10:43:04 +0200

Iljitsch,

Are you suggesting that the multi6 solution should have a strict
dependency on using TLS or IPSEC?

    Brian

Iljitsch van Beijnum wrote:
> One of the problems we may have to solve is a mapping system from an 
> identifier to a set of locators, or from a single locator to the full 
> set. A straightforward way to do this would be routable IP address -> 
> FQDN -> full set of routable IP addresses. Unfortunately, this requires 
> that both the forward and reverse DNS trees are populated properly. This 
> in itself is somewhat hard (but doable for well-managed sites, if not 
> for ad-hoc and "basement multihoming" situations). However, without full 
> deployment of DNSSEC this information isn't particularly trustworthy.
> 
> It occurs to me that there may be an alternative way to make these FQDN 
> <-> address mappings available: they can be negotiated as part of the 
> IPsec or TLS negotiations. Think about it: TLS already verifies 
> ownership of a FQDN, so after that any FQDN -> address mappings that are 
> provided are supposedly trustworthy, and more so than information 
> learned through unprotected DNS queries.
> 
> In many cases, a reverse lookup (address -> FQDN) isn't necessary, but 
> if it is, things get more complicated. It's not inconceivable that 
> someone would want to override valid reverse mapping information in the 
> DNS with invalid information negotiatated with IPsec/TLS. For instance, 
> I may have a valid certificate for justforkicks.net and I could tell you 
> that the addresses that belong to Google actually map to 
> justforkicks.net and then any time Google spiders your website my domain 
> name shows up in your logs. Not immediately fatal, but problematic 
> nonetheless. This problem can be solved in one of two ways:
> 
> 1. only allow installing reverse mapping if there aren't any present in 
> the DNS
> 2. only allow installing reverse mapping for addresses that wouldn't 
> normally be used for non-MH purposes
> 
> An example of the addresses under 2. could be RFC 3041 addresses. Those 
> can be used for non-MH purposes, but presumably not for anything that 
> would be bothered by injecting false reverse DNS information. I.e. as 
> long as people don't use RFC 3041 addresses for anything worth MH 
> protection there is no problem. Another choice would be addresses 
> derived from EUI-64s with the u/l flag set to global and the group bit 
> set. There is currently no reasonable way that such addresses show up by 
> accidentt.
> 
> I think that such a mechanism would very nicely compliment a NOID-like 
> solution, as it effectively removes dependency on the DNS for a large 
> number of applications. At the same time, the solution in question can 
> be deployed without having to wait for this mechanism to be implemented; 
> it can be put to use as soon as it's available, in the mean time there's 
> the DNS.
> 
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 4 Jul 2004 11:55:36 +0200

> dependency on using TLS or IPSEC?

Certainly not. I'm saying two things:

- if the DNS doesn't work, discover information that would normally be 
in the DNS through the TLS or IKE negotiation, and
- the DNS is often insecure, so let the TLS or IKE derived information 
override it to increase security

But if TLS/IPsec aren't used, the information is taken from the DNS.