Re: [DNSOP] Fwd: New Version Notification for draft-mglt-dnsop-dnssec-validator-requirements-02.txt

[Edward Lewis <[e-mail]>]

I wasn’t aware this was in progress, I’m glad to see it.
DNSOP                                                    D. Migault (Ed)
Internet-Draft                                                  Ericsson
Intended status: Standards Track                       February 16, 2015
Expires: August 20, 2015


                     DNSSEC Validators Requirements
         draft-mglt-dnsop-dnssec-validator-requirements-02.txt

I was going to insert detailed comments, but they got too long.IMHO, a
manageable DNSSEC validator must do this:

1) Implement RFC 5011
2) Accommodate remote authorized management (get, set) of Trust Anchors
3) Accommodate remote authorized management of its validator clock
4) Accommodate remote authorized management of Negative Trust Anchors
5) Accommodate remote authorized management of data in any cache

Looking at section 9 of the document to compare the requirements I’ve put
above:
Requirement 1:  DNSSEC validator MUST be provided means to appropriately
update their time.

That I agree with (my #3)

Requirement 2:  DNSSEC Validator MUST be able to check the validity of
their Trust Anchor KSKs.

The problem here is that the validator can verify that their Trust Anchors
are sane but the validator can’t reliably make a conclusion if there’s a
problem.

Requirement 3:  DNSSEC Validator MUST be able to retrieve their Trust
Anchor KSKs.

This sounds like a bad idea, unless “retrieve” means go get it via an
appropriate “software update.”
And, this will come up - trust anchors are not KSKs and ZSKs, they are
SEPs and there’s no protocol distinction between KSK and ZSK in
validation.  This point will be come more of an issue with the next bunch
of requirements.

Requirement 4:  DNSSEC Validator MUST be able to be informed a ZSK MUST be
flushed from cache.
Requirement 5:  DNSSEC Validator MUST be able to be informed a KSK MUST be
flushed from cache.

Cache flushing is not specific to DNSSEC. Worse yet, in my mind, once a
validator passes judgement on a set of data and the data is entered in the
good cache or bad cache, the validator’s job is done.  Getting the
validator into the business of managing the cache leads to these issues:

What if a key in the chain expires or TTL’s out of the cache?  I believe
that should not cause the validated data set to be discarded too.  (Or the
SSH session tunnel that resulted from an address record lookup torn down.)
 What if the request to flush is unauthorized, resulting in a denial of
service on the validator (having to relearn the keys) or just an
unavailability of the data tossed needlessly.  A lot of what ifs involved.
 The net recommendation is to separate cache management from validation.

Requirement 6:  DNSSEC Validator MUST be able to be informed a KSK SHOULD
be trusted as a Trust Anchor KSK.

Has to be done out of band.

Requirement 7:  DNSSEC Validator MUST be able to be informed that a KSK or
a ZSK MUST NOT be used for RRSIG validation.

Once upon a time we tried to make up a authorization model for DNSSEC -
who was allowed to sign for what.  It’s a hard problem and we never solved
it.  (We being some DARPA sponsored researchers.)  Designating a key to
not be used - the closest is a negative trust anchor but that doesn’t
delete a key.  Perhaps an authorized flushing of a domain (name) and then
having to learn the data authenticated by the new key set is the way out.
This would be acceptable since the authority “is facing bigger problems”.

Requirement 8:  The DNSSEC Validator MUST be able to be informed that a
KSK or a ZSK is known "back to secure".

Out of band, has to be.

Requirement 9:  DNSSEC Validator MUST be able to be provided KSK for
private use.
Requirement 10:  DNSSEC Validator MUST be able to be provided ZSK for
private use.

These would be trust anchors - SEP’s.

There’s only so much you can do in terms of managing security of a system
from within the system.  It’s more likely that general screw ups will
cause problems than over attacks on the keys themselves.  With the
recommendation that DNSSEC validation be done closer to the application
(I’ll not qualify that recommendation other than to say I’ve heard it),
it’s ever more necessary to manage the validators in a scaleable and
obvious way.

On the one hand there’s a desire to decrease central authority.  On the
other hand, most users don’t want to take on the responsibility (that
includes me) of managing the minutia of their security.  I don’t seen an
easy compromise between the two.

###############  Below was my first attempt to comment, leaving it for
whatever it’s worth.


Internet-Draft        DNSSEC Validator Requirements        February 2015

2.  Introduction

…
   Currently few efforts have been made to describe mechanisms that
   guarantee how a DNSSEC validator can be provisioned with the
   appropriated KSKs and time so that DNSSEC validation can always be

Ed: SEPs, not KSKs.  Secure Entry Points is the proper term.…

Migault (Ed)             Expires August 20, 2015                [Page 2]
Internet-Draft        DNSSEC Validator Requirements        February 2015

3.  Terminology

   This document uses the following terminology:

   - DNSSEC Validator:  the entity that performs DNSSEC resolution and
         performs signature validation.

Ed: It’s more than “signature" validation.  I’d just drop the adjective.
As one example, you also have to show that the NSEC(3) records prove the
right point, and another example, show that the signature is generated by
an appropriate authority.4.  Time derivation and absence of Real Time Clock

5.  Unplugged devices during Trust Anchor KSKs roll over

Ed: SEPs! Not KSKs

Migault (Ed)             Expires August 20, 2015                [Page 3]
Internet-Draft        DNSSEC Validator Requirements        February 2015

   Requirement 2: DNSSEC Validator MUST be able to check the validity of
   their Trust Anchor KSKs.

Ed: I firmly believe that compliance with RFC 5011 is needed as a MUST.
It’s a Full Standard, for one thing.  And when it comes time to roll the
root zone SEP (KSK), validators that don’t have 5011 will require manual
intervention.  I single out the root zone because there’s no DS record for
it.A device booted from cold storage can check to see if the DS records
correspond to the SEPs it holds, but not for the root zone.  Of course, if
the DS records do not correspond, you can’t draw any conclusions, but if
they do the device knows it’s initial state is secure (or somewhat).If
there’s disagreement, then there’s no fool-proof way to update the trust
anchors.  So for this requirement, the result is “yep, check” or “we may
have a problem.”   

   Requirement 3: DNSSEC Validator MUST be able to retrieve their Trust
   Anchor KSKs.

I’m not sure how to interpret that requirement.  Do you mean that it
should be possible to query a validator for it’s trust anchor set?  Or do
you mean that the validator can retrieve trust anchors over the network?6.
 Emergency Key rollover


   Requirement 4: DNSSEC Validator MUST be able to be informed a ZSK
   MUST be flushed from cache.

Ed: This can backfire.  The signal has to be authenticated and pass an
authorization test, lest this just be a massive DOS vector.  (My
explanation below applies to Req 5 too.)IMHO, there only difference
between an emergency key rollover and a regular key rollover is simply
that the former is unscheduled while the latter is.  Given that the
average validator won’t know the schedule for key rollovers, there’s no
difference between emergency and not.  So I’d discard the
distinction.There’s a need to remove bad data from the cache, and it’s not
restricted to DNSKEYs or RRSIGs.  It’s anytime an zone loads bad data -
bad NS set, bad address records, etc.  While a zone administrator will
know to signal when this happens, they can’t enumerate the validators that
have the bad information.  (No, no you can’t - even if think you can scour
the query packet IP addresses you don’t know what forwarding had happened
or what source address forgery happened.)I can’t think of any in-band way
to fix this.  Out-of-band, sure, but not in-band.

   Requirement 6: DNSSEC Validator MUST be able to be informed a KSK
   SHOULD be trusted as a Trust Anchor KSK.

Ed: I suppose I should ask “informed” by whom?  The zone administrator -
no.  The validator administrator - yes.  (As in local policy rulz.)
Problem is - who’s the validator admin?7.  Invalid RRSIG

   Requirement 7: DNSSEC Validator MUST be able to be informed that a
   KSK or a ZSK MUST NOT be used for RRSIG validation.  Unlike
   "flushing", "MUST NOT be used" means the issue is not a
   synchronization issue, but that legitimate keys are invalid.  Such
   Keys are known as Negative Trust Anchors
   [I-D.livingood-negative-trust-anchors].

Ed: “legitimate keys are invalid” doesn’t read well.  What if I scrape
keys from last year’s zone file and try to reply them.  The keys will not
be valid (assuming a rollover schedule on a monthly or quarterly basis).
But are they legitimate?
 

At this point I gave up on trying to pick points...