[Last-Call] Re: Dnsdir last call review of draft-ietf-dnsop-must-not-sha1-03

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Florian Obser via Datatracker <noreply@xxxxxxxx> writes:

> Issue
> =====
> | 2.  Deprecating RSASHA1 and RSASHA1-NSEC3-SHA1 algorithms in DNSSEC
> |   Validating resolvers MUST continue to support validation using these
> |   algorithms as they are diminishing in use but still actively in use
> |   for some domains as of this publication.  Thus, validating resolvers
> |   MAY treat RRSIG records created from DNSKEY records using these
> |   algorithms as an unsupported algorithm.
> 
> Éric flagged the previous wording in his AD review of version -02. I
> still do not get what the new wording is trying to say. How does one
> MAY do a thing that one MUST do at the same time? Are you maybe trying
> to say that a validating resolver has two choices:
> 1. Implement RSASHA1 and RSASHA1-NSEC3-SHA1 and do proper validation
> 2. Stop implementing RSASHA1 and RSASHA1-NSEC3-SHA1 and treat the
>    answer as insecure
> But a validating resolver MUST NOT treat an answer as bogus solely
> because it uses RSASHA1 or RSASHA1-NSEC3-SHA1.
> 
> Once that issue is resolved the document is ready to go.

So the current text now says this, which came out of a previous
iteration about this wording (which I agree is tricky to get right):

    Validating resolver implementations MUST continue to support
    validation using these algorithms as they are diminishing in use but
    still actively in use for some domains as of this publication.
    Because of RSASHA1 and RSASHA1-NSEC3-SHA1's non-zero use, deployed
    validating resolvers MAY by configured to continue to validate RRSIG
    records that use these algorithms.  Validating resolvers deployed in
    more security strict environments MAY wish to treat these RRSIG
    records as an unsupported algorithm.

We believe this new wording handles this issue

-- 
Wes Hardaker
USC/ISI

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux