On Thu, Sep 16, 2021 at 8:57 PM Daniel Migault <mglt.ietf@xxxxxxxxx> wrote:
Hi Paul,Thanks for the response. Please see inline, this is exactly the clarification I think the current document needs. Please see inline.Yours,
DanielOn Thu, Sep 16, 2021 at 11:00 AM Paul Wouters <paul@xxxxxxxxx> wrote:On Thu, 16 Sep 2021, Daniel Migault wrote:
> The concern is interoperability.
I think the real concern, that this document solves, is that if there
is a new algorithm some group wants to use for DNSSEC, that it can
be at least _specified_ in RFCs and registered in IANA registries,
be in standards track or experimental or informational. This document
ensures that. Right now, one could not specify an informational algorithm
completely, only partially, due to the inconsistent registration policies
for the related IANA Registries.
Once specified, whether something should or should not be mandatory to
implement (for validators or for signers) is up to RFC 8624bis. That
document would take into account operational concerns, as well as
cryptographic concerns, and interoperability concerns. For example,
it would like first try to promote (via MAY or perhaps SHOULD) that the
algorithm can be used/tested. Possibly it would then proceed to
to make validation a MUST before promoting the signers to SHOULD or
MUST.
The two paragraphs you propose are **exactly** the kind of text I am asking to be added to provide a clear path to anyone asking for the registration of a new algorithm. It clarifies the impact associated to standard and non standard code points, as well as that the mandatory-to-implement are defined by 8624 independently from the status of the code point. I also believe this could address interoperability - which could even get removed from the security considerations as this is clearly handled by 8624.
<ad hat>
I have read, and reread this document as well as RFC 8624, and think that the current text is fine. I do think that if we write an RFC 8624bis (and I hope we do), it can more fully discuss the implications and expectations around the different code-points, as well as how best to introduce new algorithms -- but, I don't think that that all belongs in *this* document. This document "Revise[s] IANA Considerations for DNSSEC", and so I feel that it should be kept focused on the IANA bits, not expanded into the larger issues.
</ad hat>
W
--> If previous RFC addressed it, then it should be ease to add a reference.
I believe the only reference needed is already there 8624.I agree 8624 is sufficient.Possibly, one
could refer to the DNSSEC BCP document, RFC 6781. It has a section 3.4 on
"Cryptographic Considerations", but it does not really provide any advise
on the interoperability issue you are raising. Perhaps you could review
6781 and if you think your concern warrants it, propose starting a draft
on 6781bis ?
Paul
--Daniel MigaultEricsson
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
-- E. W. Dijkstra
complexities of his own making.
-- E. W. Dijkstra
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
