Subject: Re: [dnsext] Clarifying the mandatory algorithm rules

From: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 18 Nov 2010 11:18:30 -0600 (GMT-06:00)

Jelte and all,

-----Original Message-----
>From: Jelte Jansen <[email-masked]>
>Sent: Nov 18, 2010 8:33 AM
>To: Samuel Weiler <[email-masked]>
>Cc: [email-masked]
>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
>[email-masked]
>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 [email-masked]
Phone: 214-244-4827

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 18 Nov 2010 11:42:12 -0600 (GMT-06:00)

Phillip and all,

-----Original Message-----
From: Phillip Hallam-Baker
Sent: Nov 18, 2010 7:46 AM
To: "W.C.A. Wijngaards"
Cc: [email-masked]
Subject: Re: [dnsext] Clarifying the mandatory algorithm rules

I can't quite understand why we would make a change to require acceptance of the unsigned zone in this case.

1) What is easier, for operators to change their behavior and sign before they publish keys or for resolvers to change their behavior.

2) What is more secure, to protect against the downgrade attack or to allow it for the sake of incompetent signers?

Wait a second here.  If there are incompetant signers for 'old' alg's. than there will likely be similar for 'Approved'

newer/different Alg's.  So niether is MORE secure than the other.

3) What is more sustainable? If the WG accepts this change, what is the probability others will implement a choice that appears eccentric and wrong?

Well I am often accused of being 'Eccentric', so I guess I would be wrong fairly often. >;)

Absent a really compelling reason to allow for zones to be signed in this way, I can't see why we would not change the operations section rather than the validation. Is there any reason that the operators cannot publish the signatures before the keys?

No.  But some operators are little more than the old term 'Tape Apes', even still.

The problem of what relying applications should to do when a zone is incorrectly signed is much more general than this one example and one that I don't think has been fully considered by those advocating end-to-end DNSSEC design with the validation taking place at the relying application.

This is a general problem in cryptographic protocols: if there is no possibility of an attack succeeding, there is no point in attempting the attack. Therefore the probability that a signature is failing because of an attack falls to zero and the overwhelming likelihood is that the cause of any failure is misconfiguration.

Sound logic here.  BUT, there is no such thing as an attack proof crypto protocol.  And it is very

unlikely that in my lifetime there ever will be.

There are controls that can be implemented to mitigate this but they depend on having more state information than an endpoint can acquire on its own.

Agreed.

On Thu, Nov 18, 2010 at 7:02 AM, W.C.A. Wijngaards <[email-masked]> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Sam,

You seem to want to enforce an original idea (which Mark understood
perfectly, it seems), about protection from signature-missing.  This is
not what RFC4035 says.

On 11/18/2010 12:37 PM, Samuel Weiler wrote:
> On Thu, 18 Nov 2010, Ond?ej Sur? wrote:

> This is a different sort of downgrade attack than the one these rules
> were designed to protect against.  Indeed, to address this attack within
> the protocol, we'd need to require resolvers to check EVERY algorithm's
> signature (if they can).  We didn't do that before, and it's probably
> unwise to make that change now.

That is what unbound does.  And it gets algorithm downgrade protection
security as a benefit (for the algorithms that it implements).

Since owners MUST sign their zone correctly, I see no need to specify a
MUST accept missing signatures if you implement the other algorithm?
Why do you want to allow inproperly-signed zones?  It will break
resolvers that implement only a subset of algorithms?

> Indeed, for the attack you're describing, the resolver would need to be
> involved, and it would need to change.

Unbound would not need to change.  Today, if people sign their zones
properly, this is compatible with BIND and Unbound.

Because it is unknown if future algorithm numbers may allow signatures
to be absent; unbound does not check if signatures are missing for
algorithms that it does not implement (and anyway a spoofed signature
would trivially get accepted since it cannot validate).

> The downgrade attack that led to this is documented in a message to
> namedroppers on 13 August 2003, Subject line "DNSSECbis Q-2: degradation
> attack".  With the archives off-line, perhaps I should resend it.

No.

Best regards,
Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkzlFe0ACgkQkDLqNwOhpPjODACcCjh2uSefIUiMUdTtpJit9yfa
5fEAn2aYmizlQcZm4sJVQgjfFv/FJSEj
=I/FY
-----END PGP SIGNATURE-----

--
Website: http://hallambaker.com/

Regards,
Jeffrey A. Williams

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 18 Nov 2010 11:45:02 -0600 (GMT-06:00)

Florian and all,

SHA-1 was broken aroud 3 years ago now.  1024k keysize was
not long ago broken by the University of Mich. 

-----Original Message-----
>From: Florian Weimer <[email-masked]>
>Sent: Nov 18, 2010 8:05 AM
>To: "W.C.A. Wijngaards" <[email-masked]>
>Cc: [email-masked]
>* W. C. A. Wijngaards:
>And I don't see any other way to get a priori downgrade protection.
>There is no ordering of algorithm strengths.  For example, we don't
>know if SHA-1 or SHA-256 will be broken first.
>
>A posterio, you can drop validation for known-to-be-broken algorithms.
>But even that might be not so easy because it's somewhat subjective
>when an algorithm is broken.
>
>-- 
>Florian Weimer                <[email-masked]>
>BFK edv-consulting GmbH       http://www.bfk.de/
>Kriegsstraße 100              tel: +49-721-96201-1
>D-76133 Karlsruhe             fax: +49-721-96201-99

Regards,
Jeffrey A. Williams