Subject: [Geopriv] Requiring DNSSEC in draft-ietf-geopriv-lis-discovery-04

From: Cullen Jennings <[email-masked]>
Date: Tue, 4 Nov 2008 15:50:05 -0700

My read of the draft is that it requires implementation (but not  
deployment) of DNSSEC on end user devices. WIth my Cisco/Linksys hat  
on, I would like to say that is is extremely unlikely that vendors of  
small phone devices are going to do this any time soon. I would highly  
encourage the WG to not make this required.

sent with my individual contributor hat on,
Cullen
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Richard Barnes <[email-masked]>
Date: Tue, 04 Nov 2008 18:04:57 -0500

The appropriate reference for non-DNSSEC approaches to preventing 
attacks on the integrity of DNS transactions is probably 
draft-ietf-dnsext-forgery-resilience:
<http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-07>

--Richard

Cullen Jennings wrote:
> deployment) of DNSSEC on end user devices. WIth my Cisco/Linksys hat on, 
> I would like to say that is is extremely unlikely that vendors of small 
> phone devices are going to do this any time soon. I would highly

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 4 Nov 2008 17:14:32 -0600

Cullen is right.  I can't see DNSSEC being implemented.

Would the WG agree with removing the requirement for DNSSEC and instead referencing the forgery resilience draft?  Note that discovery is particularly susceptible to forgery.  Is this level of protection adequate, in light of the costs?

Cheers,
Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Barnes
> Sent: Wednesday, 5 November 2008 10:05 AM
> To: Cullen Jennings
> Cc: GEOPRIV
> Subject: Re: [Geopriv] Requiring DNSSEC indraft-ietf-geopriv-lis-
> discovery-04
> 
> on,

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Richard Barnes <[email-masked]>
Date: Tue, 04 Nov 2008 18:23:31 -0500

Well, you'll still have to get past SECDIR :)

The right approach is probably to document the levels of assurance the 
client gets out of each approach (nothing, forgery-resilience, DNSSEC), 
and RECOMMEND that the network support both forgery-resilience and DNSSEC.

--Ricahrd

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 5 Nov 2008 16:55:28 +0200

Hi Cullen,

I looked at
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lis-discovery-04.
txt and did not got the impression that DNSSec was mandatory to
implement. I believe that the document just does what all other
documents using DNS do and say "DNSSec provides security properties and
if you care about them you should be using it.". 

On the deployment: I do get the impression that the world is moving
towards DNSSec with the recent activities, with the next version of
Windows supporting DNSSec and the roots getting signed. 

Ciao
Hannes

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Cullen Jennings
>Sent: 05 November, 2008 00:50
>To: GEOPRIV
>Subject: [Geopriv] Requiring DNSSEC in 
>draft-ietf-geopriv-lis-discovery-04
>
>
>deployment) of DNSSEC on end user devices. WIth my 
>Cisco/Linksys hat on, I would like to say that is is extremely 
>unlikely that vendors of small phone devices are going to do 
>this any time soon. I would highly encourage the WG to not 
>make this required.
>
>sent with my individual contributor hat on, Cullen

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 5 Nov 2008 16:59:06 +0200

I recently had to review that document for the Transport Area
Directorate. It is a good document but largely refers to implementation
problems with DNS implementations.  The question for a GEOPRIV document
really is how far we have to go with referencing DNS security documents.

I am fine with an informative reference to this document but then we
should stop. 

>[mailto:[email-masked]] On Behalf Of ext Richard Barnes
>Sent: 05 November, 2008 01:05
>To: Cullen Jennings
>Cc: GEOPRIV
>Subject: Re: [Geopriv] Requiring DNSSEC 
>indraft-ietf-geopriv-lis-discovery-04
>
>The appropriate reference for non-DNSSEC approaches to 
>preventing attacks on the integrity of DNS transactions is probably

---

From: Peter Koch <[email-masked]>
Date: Tue, 11 Nov 2008 18:46:34 +0100

Hi,

> encourage the WG to not make this required.

I'm also not sure that DNSSEC can provide what's asked for here.
While at it, please find below a review of the draft through my DNS glasses:

> GEOPRIV                                                       M. Thomson
> Internet-Draft                                           J. Winterbottom
> Intended status: Standards Track                                  Andrew
> Expires: May 3, 2009                                    October 30, 2008
> 
> 
>         Discovering the Local Location Information Server (LIS)

> 4.  Determining the Access Network Domain Name

The basic criticism is that the document suggests there is an equivalent of
"network" and "domain" or "domain name".  This doesn't hold in practice and in
fact both are orthogonal concepts.  That said, both S-NAPTR and U-NAPTR are
prone to abuse in a service discovery context (as opposed to service location),
where one tries to publish information _for_ a certain target audience instead
of _about_ a domain (name).
Even with this set aside for a moment, I'd like to comment on some of the
specific approaches.

>    The U-NAPTR discovery method described in Section 3 requires that the
>    domain name applicable to the access network is known.  An
>    unconfigured host might not have this information, therefore it must
>    determine this value before the U-NAPTR method can be attempted.
> 
>    This section describes several methods for discovering a domain name
>    for the local access network.  Each method is attempted where
>    applicable until a domain name is derived.  If a domain name is
>    successfully derived but that domain name does not produce any
>    U-NAPTR records, alternative methods can be attempted to determine
>    additional domain names.  Reattempting with different methods is
>    particularly applicable when NAT is used, as is shown in
>    Section 4.2.1.

> 4.1.  DHCP Domain Name Option
> 
>    For IP version 4, Dynamic Host Configuration Protocol (DHCP) option
>    15 [RFC2131] includes the domain name suffix for the host.  If DHCP
>    and option 15 are available, this value should be used as input the
>    U-NAPTR procedure.
> 
>    Alternatively, a fully qualified domain name (FQDN) for the host
>    might be provided by the server ([RFC4702] for DHCPv4, [RFC4704] for
>    DHCPv6).  The domain part of the FQDN can be used as input to the
>    U-NAPTR resolution and is obtained by removing the first label.  If

While that's a common case, the "domain part" may also be equal to the
FQDN or differ by more than one label.

> 4.2.  Reverse DNS
> 
>    DNS "PTR" records in the "in-addr.arpa." domain can be used to
>    determine the domain name of a host, and therefore, the name of the
>    domain for that host.  The use of the "in-addr.arpa." domain is
>    described in [RFC1034] and results in the domain name of the host.
>    Likewise, IPv6 hosts use the "ip6.arpa." domain.  In the majority of
>    cases, the domain part of this name (everything excluding the first
>    label) is also the domain name for the access network.  Assuming that
>    this is true, this domain name can be used as input to the U-NAPTR
>    process.

This is a brave assumption that actually tries to overlay semantics
on the target of PTR RRs.  Also, it tacitly assumes that the host did
not provide a name of his own choosing for the DNS reverse mapping.
While this may work, it appears like a "hack" and should not be accepted
as an architectural principle.

>    For example, for an address of "192.0.2.3", if the "PTR" record at
>    "3.2.0.192.in-addr.arpa." refers to "h3-2-0-192.example.com.", this
>    results in a U-NAPTR search for "example.com."
> 
>    The DNS hierarchy does not necessarily directly map onto a network
>    topology (see [RFC4367]); therefore, this method MUST only be used
>    for the domain name determined by removing the first label only.
>    This method assumes that the access network provider also provides
>    the reverse DNS record and they control the domain that is indicated
>    in the "PTR" record.
> 
>    Furthermore, this method might not apply where a host is given a
>    domain name that is different from the domain name of the access
>    network.  This might occur in some hosting configurations, such as
>    where a number of web server hosts, with widely varying domain names,
>    are co-located.  From the above example, the access network provider
>    allocated "10.1.2.3" to the host; therefore, they also need to
>    control the DNS domain "example.com" and the associated NAPTR
>    records.  DNS Security Extensions (DNSSEC) [RFC4033] provides a
>    cryptographic means of validating this association, through data
>    origin authentication.

While these paragraphs already list the weaknesses, albeit without
conclusion, the proposed use of DNSSEC seems to demand a service that
DNSSEC cannot deliver.  First, DNSSEC is only about data origin authentication,
not control.  There is simply no information available who "controls" the
name space.  Second, and more importantly, the signing entities are the
zones themselves, i.e., each and every zone will have a key pair generated,
so there is no way that one could conclude "same key == same management".

> 5.  Overall Discovery Procedure
> 
>    To claim compliance with this document, a host MUST support both DHCP
>    discovery and U-NAPTR discovery.  Further, the host MUST support
>    retrieval of domain name from DHCP and reverse DNS, using a local
>    interface address and the reflexive transport address provided by
>    STUN.  Additional methods for determining the IP address of the host
>    in different network segments are optional.
> 
>    These individual components of discovery are combined into a single
>    discovery procedure.  Some networks maintain a topology analogous to
>    an onion and are comprised of layers, or segments, separating hosts
>    from the Internet through intermediate networks.  Applying the
>    individual discovery methods in the following order provides a higher
>    probability that a host discovers the LIS physically closest to it:
> 
>    1.  DHCP LIS URI Option
> 
>    2.  DNS U-NAPTR Discovery, using the domain name from:
> 
>        A.  DHCP Domain Name Option
> 
>        B.  Reverse DNS, using the IP address from:
> 
>            1.  the local network interface and immediate network segment
> 
>            2.  the public reflexive transport address, as revealed by
>                STUN
> 
>    3.  Alternative methods, including static configuration
> 
>    A host that has multiple network interfaces could potentially be
>    served by a different access network on each interface, each with a
>    different LIS.  The host SHOULD attempt to discover the LIS
>    applicable to each network interface, stopping when a LIS is
>    successfully discovered on any interface.
> 
>    A host that discovers a LIS URI MUST attempt to verify that the LIS
>    is able to provide location information.  For the HELD protocol, the
>    host MUST make a location request to the LIS.  If the LIS responds to
>    this request with the "notLocatable" error code (see Section 4.3.2 of
>    [I-D.ietf-geopriv-http-location-delivery]), the host MUST continue
>    the discovery process and not make further requests to that LIS on
>    that network interface.
> 
>    DHCP discovery MUST be attempted before DNS discovery.  This allows
>    the network access provider a direct and explicit means of
>    configuring a LIS address.  DNS discovery is used as a failsafe,
> 
> 
> 
> Thomson & Winterbottom     Expires May 3, 2009                 [Page 12]

> Internet-Draft                LIS Discovery                 October 2008
> 
> 
>    providing a means to discover a LIS where the DHCP infrastructure
>    does not support the LIS URI option.
> 
>    LIS discovery through DNS requires the host to determine the domain
>    name of the local access network.  Where DHCP is available, the DHCP
>    domain name option (Section 4.1) can be used to provide this
>    information.  If the domain name cannot be determined from DHCP, or
>    the resulting domain name fails to yield a valid LIS address then
>    reverse DNS is used.  Alternative methods for determining the domain
>    name MAY be used, providing they consider the guidance in
>    Section 4.2.2.
> 
>    Static host configuration MAY be used to provide a LIS address if
>    both DHCP and DNS methods fail.  Note however, that if a host has
>    moved from its customary location, static configuration might
>    indicate a LIS that is unable to provide a location.
> 
>    If the discovery process fails, user interaction is NOT RECOMMENDED.
>    The discovery process is not easily diagnosed by a user.
> 
>    The product of the LIS discovery process is an http: or https: URI.
>    Nothing distinguishes this URI from other URIs with the same scheme,
>    aside from the fact that it is the product of this process.  Only
>    URIs produced by the discovery process can be used for location
>    configuration using HELD.  URIs that are not a product of LIS
>    discovery MUST NOT be used for location configuration.

> 7.  Security Considerations

[...]

>    Reverse DNS is subject to the maintenance of the "in-addr.arpa." or
>    "ip6.arpa." domain and the integrity of the results that it provides.
>    DNSSEC [RFC4033] provides some measures that can improve the
>    reliability of DNS results.  In particular, DNSSEC SHOULD be applied
>    to ensure that the reverse DNS record and the resulting domain are
>    provided by the same entity before this method is used.  Without this
>    assurance, the host cannot be certain that the access network
>    provider has provided the NAPTR record for the domain name that is
>    provided.

See my earlier remark. DNSSEC cannot help here. All you could apply here is
a cross-check between the reverse mapping and forward resolution, which
would give you hints about data consistency.  This is often considered
a questionable practice and DNSSEC would only change little.

Remarks regarding the availability of DNSSEC, including validators on the
client or a trust relationship with a validating resolver, have already
been made.

Best regards,
   Peter

---

From: [email-masked]
Date: Wed, 12 Nov 2008 13:00:36 +0000

Peter Koch wrote:
> This is a brave assumption that actually tries to overlay
> semantics on the target of PTR RRs.  Also, it tacitly assumes
> that the host did not provide a name of his own choosing for
> the DNS reverse mapping.  While this may work, it appears
> like a "hack" and should not be accepted as an architectural
> principle.

I'm firmly with Peter on this one.

It's not at all uncommon (particularly amongst ISPs targetting businesses) 
for the ISP to put customer supplied names in the PTR RRs.  In some cases 
the ISP may even delegate the relevant portion of in-addr.arpa directly to 
the customer.

Ray

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211