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