Hi Phil,
[Replying from jabley@xxxxxxxxxxx rather than joe.abley@xxxxxxxxx, since the former is the address which is subscribed to the ietf@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf