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

Wed Oct 7 22:53:32 UTC 2020

Ken, 

As long as the intermediate source hasn’t modified nor tampered with data from the root zone (by verifying the DNSSEC records), then I don’t think it should be classified as rogue.

Best, 

Paul Muchene

> On Oct 7, 2020, at 3:36 PM, Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) via rssac-caucus <rssac-caucus at icann.org> wrote:
> 
> 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 <mailto:kenneth.d.renard.ctr at mail.mil>
> 
> 
> On 10/6/20, 9:11 PM, "P Vixie" <paul at redbarn.org <mailto: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
> _______________________________________________
> rssac-caucus mailing list
> rssac-caucus at icann.org
> https://mm.icann.org/mailman/listinfo/rssac-caucus
> 
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20201007/2e250696/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2546 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20201007/2e250696/smime-0001.p7s>