Subject: Issue for discussion in draft-ietf-dnsext-dnssec-rsasha256

From: Andrew Sullivan <[email-masked]>
Date: Mon, 16 Jun 2008 17:57:42 -0400

Dear colleagues,

Jelte Jansen (the current editor of
draft-ietf-dnsext-dnssec-rsasha256) was going on vacation, but he
asked me to raise the following issue on the list so that he could
attempt to deal with it when he returns.  Please comment.  Anything
unclear about the outline below is undoubtedly my fault, and
not Jelte's.

In draft-ietf-dnsext-dnssec-rsasha256-04, we have at present the
following text in section 5.1:

   If both RSA/SHA-2 and RSA/SHA-1 RRSIG resource records are available
   for a certain RRset, with a secure path to their keys, the validator
   SHOULD ignore the SHA-1 signature.  If the RSA/SHA-2 signature does
   not verify the data, and the RSA/SHA-1 signature does, the validator
   SHOULD mark the data with the security status from the RSA/SHA-2
   signature.

The text may be inconsistent with the current text in RFC 4035,
section 5.3.1.  This is a variant of the issue we've been discussing
lately with respect to Trust Anchors.  

The current I-D text entails behaviour that might surprise some
administrators.  Suppose that a validator knows about SHA-2
signatures, and receives an RRset with both SHA-1 and SHA-2 RRSIG
resource records.  If for some innocent reason the validator cannot at
that moment validate the SHA-2 signature but _could_ validate the
SHA-1 signature, the validator would nevertheless have to treat the
RRset as bogus by virtue of the SHA-2 failure.

Since the DNSKEY has to have been verified anyway, one could argue
that there is no problem to solve here, and the text could be
removed.

Others might argue that the presence of the two signatures could be a
sign of a downgrade attack.  That is the reasoning behind including
this text in the first place.

It appears there are three options:

1.  Remove the text.  It's not needed.

2.  Keep the text, and mark the current document as updating RFC4035,
because it is changing the rules of section 5.3.1 of RFC4035.

3.  Keep the text, and don't do anything else.  This text is not
changing the meaning of RFC4035, and there's nothing in RFC4035 or any
of the other DNSSEC RFCs to require validators to follow the trust
chain using every available algorithm they support.

The editor tells me he'd appreciate comments to the list about this
issue.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Jun 2008 20:08:48 -0700

At 5:57 PM -0400 6/16/08, Andrew Sullivan wrote:
>section 5.3.1.

It is also inconsistent with itself. Let's say I have two RRSIG 
resource records, one RSA/SHA-2 and one base on RSA/SHA-1. According 
to the first sentence, I really have just one to consider, the former 
one. Therefore, in the second sentence, "and the RSA/SHA-1 signature 
does" can never be true because I have already ignored that signature.

>sign of a downgrade attack.

Quite true. The presence of two signatures that have different 
security properties *always* could be a sign of a downgrade attack. 
For example, I have two RRSIG resource records, one RSA-1024/SHA-2 
and one base on RSA-2048/SHA-2. This could be a downgrade attack 
because Mallory has broken RSA-1024. Or, RSA-2048-KEYA/SHA-2 and 
RSA-2048-KEYB/SHA-2; Mallory could have social engineered getting the 
private part of KEYB. Or ECDSA-256/SHA-2 and RSA-2048/SHA-2. Or ...

Either cover all the crypto downgrade cases, or cover none. It is 
impossible to cover them all. In specific, even though many people 
believe that SHA-2 is stronger than SHA-1 for preimage attacks (the 
ones we care about), no one has even a shred of proof of that. 
Something in SHA-2 could actually make preimage attacks easier than 
for SHA-1 and we won't know it for ten years. That's unlikely, but 
possible. If we bake in "ignore RSA/SHA-1 if there is an RSA/SHA-2" 
with no firm proof, we can things worse, not better.

The alternative is to rely on the community to hear if there is ever 
a preimage attack on SHA-1 that affects signatures, and to then move 
rapidly to SHA-2. Ditto for RSA-1024. And so on.

Put another way, if there is a good* preimage attack on SHA-1, DNSSEC 
is low on the list of our worries. As long as we have a transition 
mechanism *in place* for SHA-2, the attack can be thwarted in a short 
period of time.

>1.  Remove the text.  It's not needed.

Plus, strongly encourage adoption of the document. Test often. 
Publicly wag fingers at implementations that cannot support RSA/SHA-2 
within a year of the standard being published. Every few years, 
consider deprecating RSA/SHA-1 to a SHOULD and promoting RSA/SHA-2 to 
a MUST for DNSSEC (yes, it's grandstanding, but it helps).

(* "Good" means "reduces the effective strength from 160 to 80 or 
less". An attack that reduces it from 160 to 110, for example, is 
really impressive academically but doesn't help Mallory in the 
slightest because he cannot do 2^110 operations during the lifetime 
of the key (or the solar system...).)

--Paul Hoffman, Director
--VPN Consortium

---

From: Edward Lewis <[email-masked]>
Date: Tue, 17 Jun 2008 07:33:49 -0400

>lately with respect to Trust Anchors.

I'd boil this problem down to - what was not anticipated during the 
development of DNSSEC was that some cryptographic protections are 
better than others.  We had always assumed any cryptographic 
operation had the same meaning as any other.  We did, for a time, 
measure the length of chains, but that was a measure of the number of 
operations and not the value of an individual operation.

There's no guarantee that if there is a SHA-1 and SHA-2 for a set of 
data that you will see both (better stated - you will notice of one 
is missing).  The signatures ensure the RRSet's integrity but do not 
protect the RRSet plus signatures.  And there's no way in DNSSEC to 
try to retrieve a (suspected) missing signature.

>RRset as bogus by virtue of the SHA-2 failure.

Besides administrators - what about implementers?

What if the failure is that the SHA-2 inception time is in the future 
and the SHA-1 validates now?  (Let's assume the local clock is 
correct, but, you can see how this can be done by taking over the 
system clock...oh, wait, if that happens your DNS problems are not 
the most important.)

>this text in the first place.

I think this is a problem rooted in "slapped on security" - when ever 
I have seen security bolted onto an existing system there is always 
the uncertainty that it might be stripped off on the way because the 
system also has to look like the old days for an old days element 
(client).

Secondly, the problem is rooted in that there's a conflict between 
cryptographic algorithm "instability" and the stability needed in 
infrastructure code.  Even a strong-today cryptographic algorithm 
eventually becomes a weak-today algorithm.  We infrastructure folks 
aren't too used to putting in "succession planning" into our 
protocols to account for mechanisms that fade in value.  (EDNSx 
anyone?)

What I am trying to say is that any good solution here is doomed.  I 
think we have to stick with the "OR" principle or else we risk 
cutting people off the network.  DNSSEC shouldn't cause outages 
because of cryptographic book keeping mistakes.

>chain using every available algorithm they support.

I think the proposed text is wrong, it is conflict with 4035's "OR" 
principle.  However, noting the situation described as exceptional 
may hint to an implementor to log this or even try to integrate with 
some management console and report it via SNMP.  A lot of times it 
helps to have knowledge of these things going to security experts 
even if it doesn't cut the user off the network.

>The editor tells me he'd appreciate comments to the list about this

He better bring back presents for the WG.  Or at least send a postcard.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

---

From: Scott Rose <[email-masked]>
Date: Tue, 17 Jun 2008 08:34:30 -0400

> lately with respect to Trust Anchors.  

Sounds like something we would have punted (in the old days) as "local 
policy".  :)

> 1.  Remove the text.  It's not needed.
This sounds the easiest.  It might lead to some confusing for 
implementors, but by now most implementors know enough about security to 
  ask someone who knows more about security :)

> chain using every available algorithm they support.
#3 might be confusing to people who don't know DNSSEC RFC's inside an out.

I don't think the text is inconsistent with Section 5.3.1, but I don't 
think the text is necessary either.  So I can live with #1.

Scott

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------