On Thu, May 7, 2020 at 8:34 AM Shumon Huque <shu...@gmail.com> wrote:
> On Wed, May 6, 2020 at 4:49 AM Stephane Bortzmeyer <bortzme...@nic.fr>
> wrote:
>
>> On Mon, May 04, 2020 at 03:08:20PM -0400,
>> Tim Wicinski <tjw.i...@gmail.com> wrote
>> a message of 64 lines which said:
>>
>> > This starts a Call for Adoption for
>> > draft-mglt-dnsop-dnssec-validator-requirements
>>
>> I think it is important to have such a document, because DNSSEC
>> failures may seriously endanger the deployment of DNSSEC (which is
>> already too low). The current draft seems a good starting point and I
>> support its adoption.
>>
>
> I also support adoption and will review/contribute etc.
>
> I'm willing to review. Let's start immediately with -09:
>>
>> draft-ietf-dnsop-extended-error (recently approved by the IESG) should
>> be mentioned, since one of the biggest operational problem with DNSSEC
>> is the difficulty to understand why a resolver returns a SERVFAIL to
>> you.
>>
>
> Yup.
>
> > More often, to date, failed validation is due to operator error and
>> > not an attempt to forge data.
>>
>> It can be a bug in software, too. Specially with complicated things
>> like NSEC3+optout+ENT+dynupdate :-{
>>
>
> Yes, unfortunately I concur. My experience recently deploying DNSSEC
> for a large organization made it clear to me that even recent versions of
> mature DNS implementations often have a variety of operationally
> impacting DNSSEC bugs.
>
> The draft apparently do not mention advices on expiration slack (such
>> as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a
>> consensus on (I quote Unbound documentation) "The signature inception
>> and expiration dates are allowed to be off by 10% of the signature
>> lifetime"?
>>
>
> RFC 6781 Section 4.4.2 (Signature Validity Periods) does mention having
> a reasonable signature inception offset, but recommends no value. It does
> not mention a signature expiration skew. It would be good to treat this
> subject in the document. Personally, I would prefer a fixed value (~ 5 to
> 10 minutes) rather than a percentage. Otherwise, the validator may be using
> a possibly unacceptably small or large skew values depending on the
> validity
> interval.
>
I agree. The amount a clock is likely to be out of sync is not related to
the signature lifetime in any way. A fixed value based on likely clock
skew or operational experience would be better.
(Just my opinion, not meaning to sound like an authority on the subject.)
--
Bob Harold
>
> > However, a DNSSEC validator is not able to determine other than by
>> > trying whether a signature scheme is supported by the authoritative
>> > server.
>>
>> This one is unclear. First, the signer is not always an authoritative
>> server, signature can be done offline. Second, querying the DNSKEY is
>> enough, no? (Or querying the signatures, but I assume a zone won't
>> publish a DNSKEY without being able to sign with this algorithm.)
>>
>
> As the spec is currently written, yes, the DNSKEY RRset will give this
> information.
>
> Shumon
>
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
