Sean will be taking over my DISCUSS (and you'll have to continue the
discussion with him), but I would like to note that I would really
like to see better arguments than "it's simpler to implement with some
HTTP libraries" for ignoring this important security advice from RFC
3958. To me it looks like someone implementing HELD and this discovery
mechanism can pick one of the many libraries that does support this,
and this is not something that e.g. would have to work with all
currently deployed web browsers.
LoST had a quite reasonable description (RFC 5222, Section 18) why the
approach recommended in RFC 3958 would not actually work in the
deployment scenarios envisioned for LoST. But it seems the deployment
considerations would HELD would be quite different, and the same
argument does not apply here.
Best regards,
Pasi
> -----Original Message-----
> From: ext Thomson, Martin [mailto:Martin.Thomson@andrew.com]
> Sent: 19 March, 2010 02:24
> To: geopriv@ietf.org
> Cc: Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: Domain name authentication in draft-ietf-geopriv-lis-discovery
>
> Geopriv folks,
>
> With respect to Pasi's DISCUSS on discovery, I've discussed this
> with Richard and he suggested that I attempt to close this issue
> before the meeting.
>
> I propose to alter the existing text on this section as below.
>
> If, however, you feel that authenticating based on the AUS (the
> U-NAPTR input) as described in RFC 3958 is a better solution, don't
> refrain from letting the WG know this. Input either way would be
> greatly appreciated.
>
>
> (After removing the DNSSEC note prior to this)
>
> [...] Using the
> domain name in the URI is more compatible with existing HTTP client
> software, which authenticate servers based on the domain name in the
> URI.
>
>+ LIS authentication based on the domain name from the URI depends on
>+ integrity protection of the DNS queries used in U-NAPTR resolution. DNS
>+ security (DNSSEC) [RFC4033] provides some integrity protection for DNS
>+ records. Alternatively, if authoritative servers and resolvers are
>+ located within the access network, physical or link layer security might
<+ be employed to protect against modification of DNS records.
>
> This is consistent with the recommendations for DHCP, where we are
> relying on similar mechanisms.
--Martin
...
> > -----Original Message-----
> > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
> > Sent: Thursday, 18 March 2010 4:42 AM
> > To: Thomson, Martin; iesg@ietf.org
> > Cc: geopriv@ietf.org
> > Subject: RE: DISCUSS and COMMENT: draft-ietf-geopriv-lis-discovery
...
> >
> > I agree that ease of implementation is an important concern.
> However,
> > for HELD one would think that security is also an important concern.
> > Unlike normal HTTPS, the current draft essentially assumes that DNS
> is
> > secure -- otherwise, the client cannot really authenticate the LIS.
> >
> > While DHCP is also relying on a "secure network" to some degree, the
> > draft does note that the input to U-NAPTR resolution could come from
> > other (possibly more secure) sources.
> >
> > The correct approach to NAPTR resolution and TLS certificates
> (compare
> > NAPTR input against the certificate) is also used in other places
> > (like draft-ietf-sip-domain-certs), so it's clearly not impossible to
> > implement either.
> >
> > I would hope this topic gets discussed in the GEOPRIV WG in Anaheim.
> >
> > If others agree that it's OK to assume a "secure network" (even
> > when DHCP is not used), then at the very least, the document needs
> > to much more clearly highlight this assumption (and the resulting
> > limited applicability).
> >
> > Best regards,
> > Pasi
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
