Re: [dnsext] Clarifying the mandatory algorithm rules

[Brian Dickson <[e-mail]>]

I don't think the example is complete or accurate enough, since the
security at the delegation step depends on the parent's algorithms,
not the child's.

See below in-line for additional comments...

On Thu, Nov 18, 2010 at 4:37 PM, Ondřej Surý <[e-mail]> wrote:
> Wouter, Jelte,
>
> On 18.11.2010 15:33, Jelte Jansen wrote:
>>
>> IMHO, we should either do downgrade protection for all cases
>
> I suggest we properly define what a "downgrade protection" is and how does
> it protect the zone.  I've fallen for this trap too and it helped me a lot
> to write it down.
>
> Let's define (I skip KSK and ZSK for sake of sanity and I skip RFC5011 for
> the same reason):
>
> Algorithm A is supported.
> Algorithm B is also supported.
>
> Zone X has following properties:
>  1) DS record for algorithm A
1a) Signatures for DS(A), using DNSKEY(PA),DNSKEY(PB) (parent alg A
and parent alg B) -- may not be the same as A and B
>  2) DNSKEY in apex for algorithm A - DNSKEY(A)
>  3) Signatures with DNSKEY(A)
>
> Zone Y has following properties:
>  1) DS record for algorithm A
1a) Signatures for DS(A), using DNSKEY(PA),DNSKEY(PB) (id.)
>  2) DNSKEY in apex for algorithm A - DNSKEY(A)
>  3) DNSKEY in apex for algorithm B - DNSKEY(B)
>  4) Signatures with DNSKEY(A) and DNSKEY(B)
>
> What you are saying is that Zone Y is more secure than Zone X.  And I don't
> think so, because there is a step when you rely only on algorithm A.

NB - the DS does not use the algorithms, it uses (orthogonal to
algorithms) hashes.
If the hash used is more secure than A, then Y is more secure than X.

> Now let's add:
>
> Zone Z has following properties
>  1) DS record for algorithm A
>  2) DS record for algorithm B
>  3) DNSKEY in apex for algorithm A - DNSKEY(A)
>  4) DNSKEY in apex for algorithm B - DNSKEY(B)
>  5) Signatures with DNSKEY(A) and DNSKEY(B)

Here is where the example definitely helps in at least presenting the
components for comparison.

If something is seen on the wire in zone Z, without the signature
DNSKEY(B), it might be the result of a downgrade.
I.e., if A is weak, and the signature based on DNSKEY(A) can be
spoofed, this needs to be protected against.
This also means the signatures over the DNSKEYs at the apex similarly
need downgrade protection, and can only be used/trusted,
if they all match those found in the corresponding DS set of the parent.

If the parent DS is not the source of the list of algorithms which
must all be used for signing everything in the zone, downgrades are
possible.

I think there is wiggle room for the addition of new DNSKEYs and
algorithms, via the ZSK/KSK linkage, that differs slightly.

I.e. KSK must match DS for algorithms, and ZSK must match RRSIG for
algorithms. It is possible that algorithms present in ZSKs are not
present in KSKs.
And in such a case, unbound is correct and bind is incorrect, IMHO.

Brian

> I think that only Zone Z is more secure than Zone X and Zone Y.  And because
> you don't have to keep both DS records for algorithm A and algorithm B in
> the parent zone (ie. you can just exchange the DS) then the key algorithm
> rollover can be less painful.
>
> I would even suggest that the condition of "having the chain of trust" from
> TA to the key with a specific algorithm also applies for Sam's case for
> introducing the new "unknown" algorithm.  But I haven't given it much
> thought and I rather thing it through more before coming to any conclusion.
>
> Ondrej
> --
>  Ondřej Surý
>  vedoucí výzkumu/Head of R&D department
>  -------------------------------------------
>  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
>  Americka 23, 120 00 Praha 2, Czech Republic
>  mailto:[e-mail]    http://nic.cz/
>  tel:[phone]       fax:[phone]
>  -------------------------------------------
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
>