[RSSAC Caucus] Rogue Operator Work Party: Source of zone data

[Mukund Sivaraman]

On Tue, Oct 06, 2020 at 02:15:21PM -0700, P Vixie wrote:
> Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) via rssac-caucus writes:
> 
> > ...
> > The question to the group is: “Would using an intermediate source of
> > root zone data, by itself, be considered a ROGUE operation?”  Regardless
> > of who the intermediate is…, regardless of the authenticity of the zone
> > data…
> 
> in my opinion, no. carrier pigeon, /dev/random, hostile nation-state actor,
> none of that matters. if it's dnssec-authentic using the icann key, then the
> publication of such data is in-bounds and not-rogue. source, including
> intermediaries, no longer matters. that's the underlying meaning of dnssec.

The root zone is not entirely signed by DNSSEC (NS records at zonecuts
and address glue have no signatures, which could be changed to deny
service to specific TLDs).

We mention DNSSEC to indicate security but there are details that can be
misused. DNSSEC does not prevent replay for as long as the RRSIGs on the
data they cover are valid (it needs to be able to replay so data can be
served from secondaries and caches). As an example, consider the
following NSEC in the root zone at the time this email was written
(20201006223000):

com.                    86400   IN      NSEC    comcast. NS DS RRSIG NSEC
com.                    86400   IN      RRSIG   NSEC 8 1 86400 20201019200000 20201006190000 26116 <snip>

As you know, these records can be used as part of a negative proof to
prove that there can be no other name between "com." and
"comcast.". Consider now (20201006223000), the expiry time of the RRSIG
vs. the TTL of the RRsets. If ICANN introduces a new TLD between "com."
and "comcast."  today and distributes that zone via zone transfer, an
intermediate source or on-path attacker can use the insecurity proof
previously obtained above to deny access to the new TLD till 2020-10-19,
which will verify with a DNSSEC validator. 2020-10-19 is relatively a
longer time away, even compared to the SOA.expire field's value in the
root zone.

I agree that where the root zone or the root keys are sourced from
should not matter as long as they can be authenticated as correct and
current. draft-ietf-dnsop-dns-zone-digest-11 could be useful for this
with its RRSIG's expiry limited suitably.

> Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) via rssac-caucus writes:
> The question to the group is: “Would using an intermediate source of
> root zone data, by itself, be considered a ROGUE operation?” 
> Regardless of who the intermediate is…, regardless of the authenticity
> of the zone data…

If it is provably current and authentic by some mechanism, the
source/transport/etc. don't matter.

As an analogy, this is one of the main features of DNSSEC for individual
positive and negative responses, and other forms of application of
crypto such as PGP, that: it doesn't matter who you get the data from or
how as long as it is provable that the data is current and authentic.

		Mukund
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20201007/89ce8cab/signature-0001.asc>