On 31/10/2020 14:01, Valery Smyslov wrote:
Hi Tom,
we discussed with the chairs the usefulness of adding "Recommended/Not
recommended" column
(as TLS WG did) into the IKEv2 algorithm registries back in 2018 in Bangkok
and I was one who
of those who initially suggested this. However, Tero made a very good point
that
IANA doesn't have any public history. So, in the ipsecme WG another approach
was taken - we have RFCs that say which algorithms are recommended/not
recommended
for ESP and for IKEv2 and these RFCs are updated periodically.
Thanks for getting back to me. What is missing from the IANA registry
is the guidance as to the status of the algorithm, how highly it is
recommended or not. This I-D tells people to go to RFC8247 and the IANA
Registry for advice; RFC8247 gives that advice; the IANA web page does
not.
As Tero said, the IANA web page references current RFCs (8221 & 8247 at the
moment)
that list recommended algorithms. Just one more level of indirection. All
algorithms that are not listed
in these RFC are treated as "not recommended" by default, including newly
added algorithms.
And RFC8247 specifies which algorithm are AEAD, the web page does not.
The YANG module behaves differently depending on whether or not the
algorithm is AEAD; YANG implementors need to know, having this
information on the web page would make it easier for YANG implementors.
Is is a problem to open corresponding RFC or I-D? Or do you want to say that
YANG implementers don't need any other information about algorithms
except whether it's AEAD and whether it's recommended?
Valery
The problem I see is where to direct readers of the i2nsf-sdn to for
more information, about which algorithms are recommended, or not, and, a
secondary consideration, whether they are AEAD or not, since the latter
affects the YANG module. The I-D has lots of references to RFC7296 and
that RFC is very clear - for up-to-date information go to IANA. The RFC
that update RFC7296 do not appear to update that advice. And the i2nsf
I-D also contains references to IANA often alongside a reference to an
RFC. You seem to be saying that IANA is only a good reference if it
points to an RFC that says so which may not match the expectations of
users (particularly those who are familiar with the approach of the TLS
WG). If they are pointed to IANA they may well expect IANA to be the
best source of information but you seem to be saying that the WG decided
not to support that, rather expecting people to read the RFC. If IANA
said 'use this to find the RFC but do not otherwise trust this
information' that would be fine, well in a manner of speaking:-)
So, question. What references should draft i2nsf-sdn point readers to
for up-to-date information on algorithms (assuming that they do not
track the IETF WG that updates information on IKEv2 ie like me)?
Currently that is both a reference to the IANA registry and to an RFC;
is that your best advice?
Were I an author of this I-D, as opposed to a reader thereof, then based
on what you say I would remove references to the IANA website or at
least qualify them with some statement that they need to check the RFC
for current information!
What would you advise?
Tom Petch
Regards,
Valery Smyslov.
And RFC8247 specifies IoT, which I do not think is yet a consideration
here.
As I said, we are currently ok but as new algorithms get added, by
Expert Review, then that information is needed and may not be available
as there is no requirement for the Expert Reviewer to make it available.
As I said to Roman, the TLS WG found that they needed to add extra
columns to their web pages of algorithms. Different columns (e.g. DTLS
not AEAD) but I think that the situation is otherwise identical so I am
anticipating that in a year or two you will see what I mean:-). In
passing, the TLS WG determine by consensus what the status is for a new
algorithm but the Expert Reviewer makes it available via the web site
whether or not it is in an RFC.
I take your point about duplicating data - no relational databases here!
- but the answer is to specify which is authoritative and for me that
should be the IANA pages as it is for many assignments in the context of
YANG and before that SMI going back decades.
Tom Petch
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
