Re: [dnsext] Clarifying the mandatory algorithm rules

["Jeffrey A. Williams" <[e-mail]>]

Jelte and all,


-----Original Message-----
>From: Jelte Jansen <[e-mail]>
>Sent: Nov 18, 2010 8:33 AM
>To: Samuel Weiler <[e-mail]>
>Cc: [e-mail]
>Subject: Re: [dnsext] Clarifying the mandatory algorithm rules
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 11/18/2010 12:02 PM, Samuel Weiler wrote:
>> 
>> CZNIC published a DNSKEY for a "new" algorithm without simultaneously
>> publishing the corresponding RRSIGs.  Unbound started rejecting answers
>> from .cz because the zone didn't also include the new RRSIGs, even
>> though Unbound fully supported the old algorithm and the RRSIGs for that
>> old algorithm were present in the zone.
>> 
>> These rules are indeed for zone operators and/or signers and do not need
>> to be enforced by a validator.  While I haven't worked through the
>
>So what you're saying is that validators should not check for something
>because the signer (or the operator) might not be following the spec and
>that may break stuff?
>
>Or, more generally, why say that you MUST do a, then say that you
>SHOULD/MAY NOT check whether A was done?
>
>IMHO, we should either do downgrade protection for all cases (which is
>how i interpret the rfc too, and yes i am aware that this makes
>algorithm rolls a PITA, but see below), and not just a specific subset,
>or leave it out completely.

FWIW, I believe that the middle ground here is that we MUST do
downgrade protection, but limit how long that will remain in place.
>
>btw. the 'loose' interpretation would still make the hypothetical case
>fail where the *old* algorithm is not supported by a validator, but the
>new one is. And if algorithms are going to be obsoleted, perhaps that
>case will not be that hypothetical in the future. But perhaps that is
>exactly why that text is there (and why, whether or not validators check
>for it, the procedure that triggered this round of discussion was still
>wrong).

  Not supporting and 'old' alg. is simply wrong for obvious reasons.
And the validator MUST check for it and recognize the 'old' alg. If
the resolver is change to disallow for this than that needs to be fixed
or changed/changed back to allowing for the 'old' alg. but only for some
limited amount of time.
>
>Jelte
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.10 (GNU/Linux)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>iEYEARECAAYFAkzlOSYACgkQ4nZCKsdOncUrkwCfUskCLn2WsKjpCVMkYl09bAO1
>aNYAoN2QD1vBczvhOEEdvtFnd9UYOIbj
>=HXF4
>-----END PGP SIGNATURE-----
>_______________________________________________
>dnsext mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dnsext

Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402 
E-Mail [e-mail]
Phone: [phone]