[dnsext] Robustness & Extensibility -- was: Re: Clarifying the mandatory algorithm rules

[Alfred Hönes <[e-mail]>]

At Thu, 18 Nov 2010 15:33:11 +0100 , Jelte Jansen wrote:

> [...]
>
> Or, more generally, why say that you MUST do a, then say that you
> SHOULD/MAY NOT check whether A was done?
>
> [...]


Isn't that simply a basic corollary of Jon Postel's robustness
principle?


We frequently say:
     [the originator] MUST set xxxxx to yyyyyy.
and:
     [the recipient] MUST ignore xxxxx.

IMO, this is a basic principle that allows a smooth path forward
for the introduction of new protocol elements.

In the case discussed here, introduction of a new crypto-algorithm
into a DNSSEC-signed DNS zone, a similar application of the robustness
principle seems appropriate.
Unless the recipient (= validator) is *required* (by policy, or
lack of support of the previously used crypto-algorithm) to validate
signatures based on the new algorithm, any other working validation
path should suffice.
It is up to the zone maintainer/signer to decide when they deem the
old algorithm insecure enough to regard its usage as a downgrade
attack: they just have to retire the corresponding keys and signatures.
At that time, they cut off the tail of validators that do not support
the new crypto.
Until that is done, these will be able validate, and it makes no
sense to expect other validators to regard that validation path as
insufficient -- there's no point in regarding the old way as
insecure for some validators and secure for other validators.


Cf. the principles in X.509 / PKIX:  Absent specific local policy,
*any* validatable certification path from an available trust anchor
to a given certificate under consideration is acceptable.
(RFC 5280 explicitely tells you to try the next possible cert path
whenever validation of a candidate cert path fails, for any reason.)
Here, "validatable" includes built-in support of the signature
algorithm and underlying hash algorithm, local policy admitting the
acceptance of these algorithms for signature validation, and the
mathematical verification of the signatures found.


Therefore, I fully support Samuel Weiler's PoV that DNSSEC validating
resolvers should only care about syntactical correctness of RRs
and the specific rules codified for such resolvers in the specs.
Otherwise, we would likely tend to  more and more close windows for
a smooth migration to protocol extensions (including migration to
new crypto) and make DNSSEC administration and management subject
to even more restrictions (that essentially would only serve to make
that management more fragile and error-prone and thereby make DNSSEC
itself looking more error-prone from the PoV of DNS users.

Making independent things happen at the same time is particularly
difficult in a highly distributed environment like the DNS, and so
allowing small steps on the signer/maintainer side of a zone and have
only particular "milestones" trigger change of mandatory behavior
in validating resolvers seems to be a valid and valuable strategy.

Kind regards,
  Alfred.