Subject: [dnsext] Unknown DNSKEY flags

From: [email-masked]
Date: Wed, 11 Feb 2009 12:22:13 +0000

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Hi - 

I'm developing a DNSSEC validating resolver in Ruby (using my dnsruby 
library). I was slightly confused by some of the wording in RFC 4034, and 
was hoping for guidance.

Basically, I'm not quite sure what to do if I receive a DNSKEY RR with 
unknown flag bits set. RFC 4034 (section 2.1.1) says :

Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
   creation of the DNSKEY RR and MUST be ignored upon receipt.

So, do I ignore these bits, and still use the key to verify RRSIGs? The 
RFC seems to suggest that Postel's law is appropriate here.

Or do I decide that the key is in some way dodgy, and, after accepting it, 
refuse to use it to verify RRSIGs?

Thanks!

Alex.

--
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: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 11 Feb 2009 14:31:53 +0100

Hi Alex,

Use the key without looking at the bits. Thus, you verify RRSIGs and do
other stuff as usual.

This is how I read 4034, implemented in unbound.

Best regards,
   Wouter

> RFC seems to suggest that Postel's law is appropriate here.

Yes

> refuse to use it to verify RRSIGs?

No

---

From: Edward Lewis <[email-masked]>
Date: Wed, 11 Feb 2009 10:08:32 -0500

>>  RFC seems to suggest that Postel's law is appropriate here.

The logic is - if in the future the bits take on meaning and keys 
appear with a set of the bits set to 1 the software written now will 
not alter what it does.  Furthermore, the new semantics assigned to 
the bits will (have to) be backwards compatible with old software.

>>  refuse to use it to verify RRSIGs?

No, no.  Software "trying too hard" to be helpful has proven to cause 
problems in the past.  Overly tightened security can make a system 
brittle and crack, like over tightening nuts and bolts can cause 
problems (strip the bolt threads, bolt head, tear the fabric 
[wood/metal] it is binding, etc.).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Never confuse activity with progress.  Activity pays more.

---

From: Michael Graff <[email-masked]>
Date: Wed, 11 Feb 2009 09:27:43 -0600

Edward Lewis wrote:
> The logic is - if in the future the bits take on meaning and keys appear
> with a set of the bits set to 1 the software written now will not alter
> what it does.  Furthermore, the new semantics assigned to the bits will
> (have to) be backwards compatible with old software.

What if a bit is defined which means "this key is revoked."

For instance, what happened in RFC 5011?

- --Michael

---

From: Edward Lewis <[email-masked]>
Date: Wed, 11 Feb 2009 11:03:02 -0500

>What if a bit is defined which means "this key is revoked."

When we did the background for DNSSEC, we considered such 
possibilities - that is - tightening security once something was 
fielded.  We knew that it is not possible to tighten something, only 
loosen it when faced with an open source/open audience software 
distribution.

This is one reason RFC 3008 was written - tightening the authority 
model - before there was a chance of widespread deployment.  Now, 
seriously, we know in the year 2000 we were still way ahead of any 
dnssec deployment but at the time we thought it would come faster.

When designing a protocol, a correct design will be slightly tighter 
than needed and loosened as required.  The same principle of over 
tightening applies.  But you also have to give clients incentive to 
upgrade older versions - an incentive is less security hassles, a 
disincentive is more restriction.

(Admittedly, if we could get the fit right...but then that is why 
hardware stores sell "shims."  [Yes, undergoing house renovations now 
and there are shims helping install doors in the house.])

>For instance, what happened in RFC 5011?

Note from the abstract:

    This mechanism will require changes to resolver management behavior
    (but not resolver resolution behavior), and the addition of a single
    flag bit to the DNSKEY record.

It's arguable that this addition goes against the principles above, 
but splitting hairs, it doesn't.  (I.e., a long thread can go back 
and forth on this, but I don't really have the time.)

Current resolver management is manual, this defines the first 
automated mechanism for this.  So in a way this isn't a retrenchment. 
The incentive to upgrade is to remove the manual labor.  This doesn't 
chance the validation process, a trust anchor is still a trust anchor.

The same considerations are written into the first specification of 
the SEP bit (RFC 3757):

    The flag bit is intended to assist in operational procedures to
    correctly generate DS resource records, or to indicate what DNSKEYs
    are intended for static configuration.  The flag bit is not to be
    used in the DNS verification protocol.

 From the abstract.  We knew then that the SEP bit couldn't help the 
old validators out there.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 11 Feb 2009 08:43:46 -0800

>>>>> On Wed, 11 Feb 2009 10:08:32 -0500, Edward Lewis <[email-masked]> said:

EL> The logic is - if in the future the bits take on meaning and keys
EL> appear with a set of the bits set to 1 the software written now will
EL> not alter what it does.  Furthermore, the new semantics assigned to
EL> the bits will (have to) be backwards compatible with old software.

The other way commonly used to talk about extensions is "criticality".

All the DNSSKEY bits are "non-critical" and don't need to be understood.
Unlike other protocols/data-structures that have a way to flag
extensions as "critical" which means "you must fail if you don't
understand this".  DNSKEYs don't have a mechanism to signal a
critical-bit.  They're all non-critical.
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 11 Feb 2009 18:19:08 +0100

How about the KeyID?

If you do not pay attention to the unknown flags do you allow them to  
be varied during their lifetime or do you assume to be 'fixed' (are  
not modified during their lifetime)

I would assume that what-ever the flags are they will be 'fixed'  
during the lifetime of the key or, when changed, the keys cannot for  
validation by any implementation that is not aware of the meaning of  
the flag.

correct assumption?

[top-post]

--Olaf

On 11 feb 2009, at 14:31, W.C.A. Wijngaards wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Alex,
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmS00kACgkQkDLqNwOhpPjFmwCgmFXh6+267TRSXr3b/27OLZgK
> +4gAn0ofbBwN2kcsgHYCtvSh18aRstZ4
> =jPGp
> -----END PGP SIGNATURE-----
>
> --

-----------------------------------------------------------
Olaf M. Kolkman                        NLnet Labs
                                        Science Park 140,
http://www.nlnetlabs.nl/               1098 XG Amsterdam

NB: The street at which our offices are located has been
renamed to the above.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 11 Feb 2009 12:46:59 -0500

In algorithm 1, the key's identifier (KeyID or keytag) isn't derived 
from the flags.  I don't know the history of why the newer algorithms 
have different derivations of this.

 From section 4.1.6. of RFC 2535 (since obsoleted):
    "For algorithm 1
    (MD5/RSA) as defined in [RFC 2537], it is the next to the bottom two
    octets of the public key modulus needed to decode the signature
    field.  That is to say, the most significant 16 of the least
    significant 24 bits of the modulus in network (big endian) order. For
    all other algorithms, including private algorithms, it is calculated
    as a simple checksum of the KEY RR as described in Appendix C."

I faintly recollect there was a discussion whether the keytag was to 
be the RDATA or just the key guts.  But I wasn't working on the icky 
crypto. ;)

But yeah, that's an issue...

At 18:19 +0100 2/11/09, Olaf Kolkman wrote:
>How about the KeyID?
>
>If you do not pay attention to the unknown flags do you allow them 
>to be varied during their lifetime or do you assume to be 'fixed' 
>(are not modified during their lifetime)
>
>content-type: application/pgp-signature; x-mac-type=70674453;
>	name=PGP.sig
>content-description: This is a digitally signed message part
>content-disposition: inline; filename=PGP.sig
>content-transfer-encoding: 7bit
>
>Attachment converted: Macintosh HD:PGP 676.sig (pgDS/    ) (00309E10)