On Tue, Mar 24, 2015 at 10:50:11PM +0000, Osterweil, Eric wrote:
> Given the discussion on milestones re: IPSEC DANE work at the beginning
> of the DANE session today we?d like to request working group adoption of
> the existing IPSECA document:
>
> https://tools.ietf.org/html/draft-osterweil-dane-ipsec-02
I find the abstract and introduction to be an impenetrable jumble
of obstruse jargon. These need radical surgery to make them clear
and concise.
EXAMPLE:
The suggested usage of this document is to aid in discovering
where OE IPsec tunnels exist, and to act as an out of band
verification substrate that can validate the certificates
received during IPsec key exchange.
First attempt at making it better:
This document explains how to use DANE/DNSSEC to discover
OE IPsec tunnels along with the associated authentication
keys.
Why is so much of the focus on DNS confidentiality? Is this the
primary use-case for opportunistic IPSEC? Is IPSEC in fact likely
to be used to add confidentiality to DNS? Is that what the document
is about?
Once the jargon is simplified, the technical content is rather
light. There is no detailed discussion of whether this is intended
to provide protection against passive attacks only, or also active
attacks. The text about what to do with "bogus" responses is
unclear.
Finally, what I think is the biggest issue:
--- IPSEC and forward DNS
[ The below was explained to me by Paul Wouters in London,
thanks Paul. Any mistakes in the below are mine, so if I've
got the wrong end of the stick, that's not Paul's fault. ]
Creating IPSEC security associations based on forward DNS names
is rather problematic. There is no discussion of the associated
issues. Suppose we have:
ns1.saint.example. IN A 192.0.2.1
_53.saint.example. IN IPSECA 0 1 1 <saintly-digest>
serving the saint.example domain. Clients secure their connections
to this nameserver by creating an IPSEC association with 192.0.2.1
using the given key material. Along comes:
ns1.evil.example. IN A 192.0.2.1
_53.evil.example. IN IPSECA 3 1 1 <evil-digest>
publishing the same IP address as a nameserver for his own evil.example
domain. Now clients create a replacement IPSEC tunnel to 192.0.2.1
(there can only be one) and suddenly evil.example is free to
intercept saint.example's traffic.
The many-to-one mapping from DNS domain names to IP addresses,
makes it unsafe to derive IPSEC keys from "forward" domain names.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
