ietf
[Top] [All Lists]

Re: Last Call: draft-jabley-reverse-servers (Nameservers for IPv4 and IPv6 Reverse Zones) to Proposed Standard

2010-01-04 19:22:17
Hi Phil,

[Replying from jabley(_at_)hopcount(_dot_)ca rather than 
joe(_dot_)abley(_at_)icann(_dot_)org, since the former is the address which is 
subscribed to the ietf(_at_)ietf(_dot_)org list.]

On 2010-01-04, at 16:46, Phil Pennock wrote:

On 2010-01-04 at 06:08 -0800, The IESG wrote:
The IESG has received a request from an individual submitter to consider 
the following document:

- 'Nameservers for IPv4 and IPv6 Reverse Zones '
  <draft-jabley-reverse-servers-01.txt> as a Proposed Standard

First an editorial nit, there's an arithmetic error.  Then a security
nit.

  The non-compressed representation of A.IP6-SERVERS.ARPA fills (1 + 1)
  + (10 + 1) + (4 + 1) + 1 = 19 bytes.

"IP6-SERVERS" is 11 characters long.  The encoded sequence is 20 octets,
not 19.

This then leads into adjustments to the relevant table below, with
{A-F}.IP6-SERVERS.ARPA totalling 40 octets.

Thanks!

Security nit: the Security Considerations section states that there are
no new security considerations.  This is false.  Currently, five diverse
names control the top-level delegation and in the event of a major
dispute, the geopolitical diversity of the chosen names means that one
rogue actor can be partially inhibited by a split -- the same protection
that was afforded by the original choice of root nameserver operators.

I think you are in part conflating consistency of name with appointment of 
nameserver operators.

The root zone is served by nameservers which are individually operated by 
twelve different organisations; however, they are all named under the single 
domain ROOT-SERVERS.NET.

ICANN anticipates a similar, multi-organisational approach to selection of 
nameserver operators for the reverse DNS zones. The details of that are 
out-of-scope for this document, but themselves are not choices that will be 
made unilaterally. Changes to infrastructural zones in the DNS such as the root 
and ARPA zones are subject to procedural oversight (e.g. as specified in the 
IANA Functions Contract) and incorporate widespread review.

[...]

For the root zone, the actual NS records and glue used are widely spread
amongst resolvers, so the same hijack is infeasible.

Note that this is not entirely true. The hints files (and the addresses 
specified within those hints files) are widely distributed amongst resolvers, 
but those addresses are only used for priming queries. The act of priming 
amounts to far more centralised distribution of addresses.

[...]

This draft represents a change in the threat boundaries for a unilateral
future power-grab over the reverse DNS.  I'm not deliberately impugning
any of the current operators, ICANN or anyone else who reads this and is
offended; organisations can be replaced, 5, 20 or 50 years from now and
the centralised control remains.  Postel's dispersion of control should
not be so readily undone piecemeal.

At the very least, surely this warrants discussion in the Security
Considerations?

Capture of the reverse DNS without failure of systems and processes which 
control changes to the root zone would require collusion between all 
organisations responsible for serving IN-ADDR.ARPA and IP6.ARPA, and also of 
the process by which the ARPA zone is modified to change the corresponding glue 
records installed there (i.e. IAB, the IANA functions operator, NTIA and 
VeriSign).

Although the threat boundary is different in this case than in the status quo, 
it's not clear to me that the risk of capture is increased.

If you could recast your thoughts in light of my comments above, that would be 
instructive for me.

Thanks,


Joe
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>