Re: Clarifying the mandatory algorithm rules

That's a good change.  Yep, it isn't "specification language worthy."

At 22:08 +0200 3/31/11, Matthijs Mekking wrote:
>
>I would than say "it can expect to find" (not make it a rfc 2119 term)
>

--

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

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Re: Draft minutes from IETF-80

Paul,

Thanks for taking notes.

The notes contain the following:

> Jaap Akkerhuis: ICANN is going to do a five-phase(?) study on
>          specific language variants
> 	The study is pretty undefined
> 	Not optimistic that we will get anything useful from the discussions

The ICANN project is not structured as five phases, but as five case 
studies, as part of a proposed plan to develop an "initial Issues Report".

Comments on the proposed plan (attached) are due by April 6th.

Eric

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Re: Report from the chairs for IETF 80

On Mon, 28 Mar 2011, Matthijs Mekking wrote:

> I think it would also be good if we could come to a consensus on 
> clarifying how the resolver should interpret section 2.2 (RFC 4035) 
> (see the discussion on 'Clarifying the mandatory algorithm rules').

I agree.

Matthijs, Mark Andrews, and I spent some time earlier this week trying 
to reach an understanding.  Matthijs's post earlier this week tries to 
summarize that discussion, but I'll post shortly with some more words 
on the topic.

-- Sam

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Re: Clarifying the mandatory algorithm rules

As in my last message, Matthijs, Mark Andrews, and I spent some time 
today trying to understand each other.  This is the first of three 
posts trying to capture our understandings.

I believe we're in agreement about the mandatory algorithm rules in
rfc4035 and the general direction in which they should be clarified.
There are two proposals for changing these rules, which I'm describing
in separate notes.  I think we should resolve both now so that we only
have to make the clarification once.  Please respond to each of those
notes separately with your opinions on each.

I'll restate the current (clarified) rules here, though the actual
clarification text will probably look more like what I posted in
November.  Think of this more as a starting point for considering the
two proposals that follow than as final text to be added to
dnssec-bis-updates.

    The DS RRset and DNSKEY RRset are used to signal which algorithms
    are used to sign a zone.  The pressence of an algorithm in a zone's
    DS or DNSKEY RRset set signals that that algorithm is used to sign
    the entire zone.

    When signed, a zone MUST include a DNSKEY for each algorithm
    present in the zone's DS RRset and expected trust anchors for the
    zone.  The zone must also be signed with each algorithm (though not
    each key) present in the DNSKEY RRset.  It is possible to add
    algorithms at the DNSKEY that aren't in the DS record, but not
    vice-versa.

    [The above is all clarification -- the below is arguably a change,

MAR proposal #1: Algorithm downgrade protection

This is a proposed change in DNSSECbis that arguably changes the 
mandatory algorithm rules.  I'm posting this as a summary of what I 
understand some may support, I don't support this change myself. 
Please post in this thread with your support or lack thereof.

In order to provide some protection against algorithm downgrade[1], 
we're defining a mechanism for zone signers to signal to validators 
that a SET of algorithms should ALL be checked, when possible, before 
determining that an answer from the zone is Secure.  Specifically, 
we're overloading the DS RRset to do that signalling.

Validators SHOULD check signatures from all algorithms present in a 
zone's DS RRset or trust anchors before declaring an answer from the 
zone to be Secure.  If it is impossible to validate an answer with one 
or more of those algorithms, the answer SHOULD be treated as Bogus.

This is a subset of the checks unbound was performing that let to the 
discovery of the problems with .cz's algorithm roll process.

Please post in this thread with your support or objections.
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Re: MAR proposal #1: Algorithm downgrade protection

On Fri, 1 Apr 2011, Samuel Weiler wrote:

> In order to provide some protection against algorithm 
> downgrade[1]...

I forgot to provide the footnote in my first message:

[1] Acknowledging that some algorithms may eventually become weak, but
such weaknesses may not be as clear and binary as "yesterday the
algorithm was secure and today it is totally broken", a zone signer
might wish to provide signatures from a more secure algorithm so that
newer validators can be protected while simultaneously providing older
(weak) signatures for the benefit of validators that have not been
upgraded.  Without a signaling mechanism such a this, a validator
supporting both old and new algorithms may find itself accepting
forged answers signed only with the old (and broken!) algorithm.

Alternatives to this mechanism include disabling the broken algorithm
in the validator (which could unnecessarily prevent validation of
zones that haven't signed with something stronger) or implementing a
preference system in the validator (e.g. "if the zone is signed with
WeakAlgA and StrongAlgB, ONLY check the signatures from StrongAlgB").

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

MAR proposal #2: Allowing pre-publishing of DNSKEYs

This is a proposed change in DNSSECbis that changes the mandatory 
algorithm rules.  I'm posting this as a summary of what I understand 
some may support; I don't support this change myself. Please post in 
this thread with your support or lack thereof.

For additional operational and zone-signing flexibility, particularly
to allow the publication of a DNSKEY of a new algorithm before a zone
is fully signed with that algorithm, we propose to change these rules
to use ONLY the DS RRset for algorithm signalling, not the DNSKEY
RRset.

Zones will be required to be signed with each algorithm (though not
necessarily eack key) present in the zone's DS RRset or configured
trust anchors.

My opinion:

In retrospect, we probably could have used this mechanism when we 
first wrote these rules -- the choice to use both DS and DNSKEY for 
signalling may have been an artifact of history.  As it is, this 
change may cause zones signed under these new rules to fail validation 
in deployed code, including unbound.  That alone is enough to lead me 
to oppose this change.

-- Sam
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Re: MAR proposal #1: Algorithm downgrade protection

At 10:24 -0400 4/1/11, Samuel Weiler wrote:
>This is a proposed change in DNSSECbis that arguably changes the 
>mandatory algorithm rules.  I'm posting this as a summary of what I 
>understand some may support, I don't support this change myself. 
>Please post in this thread with your support or lack thereof.
>
>
>In order to provide some protection against algorithm downgrade[1], 
>we're defining a mechanism for zone signers to signal to validators 
>that a SET of algorithms should ALL be checked, when possible, 
>before determining that an answer from the zone is Secure. 
>Specifically, we're overloading the DS RRset to do that signalling.
>
>Validators SHOULD check signatures from all algorithms present in a 
>zone's DS RRset or trust anchors before declaring an answer from the 
>zone to be Secure.  If it is impossible to validate an answer with 
>one or more of those algorithms, the answer SHOULD be treated as 
>Bogus.
>
>This is a subset of the checks unbound was performing that let to 
>the discovery of the problems with .cz's algorithm roll process.
>
>Please post in this thread with your support or objections.

IMHO, algorithm downgrade protection is not a goal of DNSSEC. 
Further, there is no way an algorithm downgrade attack can succeed.

Presuming validation, when a resolver receives an answer section 
containing an RRset matching it's query, a resolver has to determine 
if the data is known to be insecure or is supposed to be secured.

Re: MAR proposal #2: Allowing pre-publishing of DNSKEYs

At 10:28 -0400 4/1/11, Samuel Weiler wrote:

>Zones will be required to be signed with each algorithm (though not
>necessarily eack key) present in the zone's DS RRset or configured
>trust anchors.

Looking at my previous message, this probably makes sense.

Just like NS sets - if the cut point NS set is a subset of the 
corresponding apex NS set things work out, if the algorithms in the 
DS set are a subset of the algorithms in the corresponding DNSKEY 
set, things work out.  And the flexibility to allow a change to be 
made on one side happen non-atomically with a change on the other 
side can proceed.

This works for adding and subtracting.

If I add an NS to the child and then the parent, no lame servers.  If 
I subtract the NS from the parent and then from the child, no lame 
servers.  I make the change in a different order between adds and 
deletes, but the same result, the upper is a subset of the lower.
--

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

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"
_______________________________________________
dnsext mailing list

Re: MAR proposal #1: Algorithm downgrade protection

I don't thing one should be checking the presence of all algorithms
in the DS RRset for accepting the answer as valid however there is
some benefit in checking that all algorithms in the DS RRset are
present for cache acceptance when there is a down stream validator
which may have a different set of algorithms it supports.

One may want to tag a answer without all the algorithms in the DS
RRset and not return it to DO=1 queries.  Such a answer is perfectly
fine for DO=0 queries and non EDNS queries.

--

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka <at> isc.org
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext