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

Sun Oct 11 13:06:01 UTC 2020

Hi Ken,
Yes in one sense if it is not modified or tampered with might not rouge as
no one would be able to tell the difference but clearly if it was
modified it becomes an obvious rouge. But to be safe, I think classifying
ANY intermediate as rouge would be the best option.
AK

On Wed, Oct 7, 2020 at 11:53 PM Paul Muchene <Paul.Muchene at icann.org> wrote:

> 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
>
>
> 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
> _______________________________________________
> 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) and
> the website Terms of Service (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.
>
>
> _______________________________________________
> 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) and
> the website Terms of Service (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.

-- 
Website <http://www.unilorin.edu.ng>, Weekly Bulletin 
<http://www.unilorin.edu.ng/index.php/bulletin> UGPortal 
<http://uilugportal.unilorin.edu.ng/> PGPortal 
<https://uilpgportal.unilorin.edu.ng/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20201011/6cb328bc/attachment-0001.html>