[RSSAC Caucus] [Non-DoD Source] Re: Rogue Operator Work Party: Source of zone data

[Renard, Kenneth D CTR USARMY CCDC C5ISR (USA)]

Regardless of the ability to detect a modified response (such as non-validating resolvers), we have determined that it would be _rogue_ for an RSO to serve modified zone data.  An intermediate source introduces additional risk of modification and, in the past was interpreted as a pre-cursor to using an alternate root zone.

The sense that I'm getting is that "as long as the data served is correct, it's not rogue".  Any other interpretations or opinions would be appreciated.

Thanks!

Ken Renard
S&TCD Contractor – ICF
Sustaining Base Network Assurance Branch 
C5ISR Center, Space and Terrestrial Communications Directorate
Office:  443-395-7809
kenneth.d.renard.ctr at mail.mil
 

On 10/6/20, 9:11 PM, "P Vixie" <paul at redbarn.org> wrote:

    Mukund Sivaraman writes:

    > On Tue, Oct 06, 2020 at 02:15:21PM -0700, P Vixie wrote:
    >> ... 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).

    this never mattered, and doesn't matter now. if the subzone isn't signed,  
    all hell will break loose, regardless of what's in the root zone. if it is  
    signed, then the DS RRs in the root zone must match the DNSKEY in the  
    subzone. i think we have to stop treating unsigned NS RRs as a shiny  
    object; if they posed any problem to authenticity of DNS content, it would  
    be a very big problem, in no way limited to the topic we are discussing  
    here.

    > 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.

    icann knows they cannot make zone changes of this kind with short  
    turnaround. if this is a bigger problem then they know about, then the dns  
    technical community should document it in an RFC and bring it to icann's  
    attention.

    > 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.

    zone-digest doesn't solve any problem that dnssec has. it's for axfr  
    initiator auditing. if you think the root zone should use zone-digest as a  
    sort of belt+suspenders audit check, i'd be interested to see your proposal.

    vixie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5162 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20201007/6f0c9276/smime.p7s>