Re: [I2nsf] [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt

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?

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
> 
> 
> The
> > registry do include numbers from draft-smyslov-esp-gost document. The
> > RFC8247 says:
> > ----------------------------------------------------------------------
> > 1.3.  Updating Algorithm Requirement Levels
> > ...
> >      .... As a result, any algorithm listed at the IKEv2
> >     IANA registry not mentioned in this document MAY be implemented.
> > ----------------------------------------------------------------------
> > I.e., all algorithms not listed there are MAY to implement.
> >
> > But I do not see any reason why the yang module should provide any
> > other than pointer to the IANA registry, and the IANA registry already
> > has pointer to the RFC8247 to indicate the requirement levels for
> > algorithms.
> >
> >>>>> It seems to me that this is a similar situation to that which the
TLS
> >>>>> WG found itself in and which led to a revision of the TLS IANA
> >>>>> entries to provide what was needed via additional columns.
> >
> > There was some requests to modify the IANA registry while we were
> > publishing RFC 8247 and the WG decided against it, and instead decided
> > to provide pointer to the RFC 8211 and RFC 8247 in the notes section.
> >
> > The reason for that is that duplicating information always causes
> > problems, and because there is no (public) history of the IANA
> > registries, there is no way of finding out when and why specific
> > change to the registry was done unless there happens to be RFC that
> > actually did that change.
> >
> > I myself as an IANA expert of those registries do think it is better
> > that working group will do RFC that will update the levels, and that
> > will leave audit trail and public working group mailing list
> > discussion about the changes.
> >
> >>>>> I think that the IANA pages for IKEv2 need revising so that that
> >>>>> additional information that RFC8247 provides is required as
> >>>>> additional columns in the IANA entries at least for Type 1, Type 2,
> >>>>> Type 3, Type 4 and Authentication Method.
> >
> > I fail to see why does that information need to be in the IANA
> > registry? This is YANG model for IPsec, it should just refer to the
> > IANA registry about the mapping from algorithms to numbers and other
> > way around, but whether the algorithm is recommended or not, does not
> > belong to the YANG model, as that is not something that can be
> > modified by configuration or be part of running state.
> >
> > This document seems to have wierd text in it:
> >
> >        typedef encryption-algorithm-type {
> >          type uint16;
> >          description
> >            "The encryption algorithm is specified with a 16-bit
> >            number extracted from IANA Registry. The acceptable
> >            values MUST follow the requirement levels for
> >            encryption algorithms for ESP and IKEv2.";
> >
> > I do not see what the last sentence of the text is trying to say? Does
> > it mean that this yang model cannot be shown of running configuration
> > where someone is using one the algorithms not considered safe
> anymore?
> > In ietf we usually just try to say what implementors are implementing,
> > we do not that often limit what adminstrators can configure. If the
> > implementation happens to implement one of those weak ciphers for
> > example for talking to one obsoleted old hardware that only supports
> > them, then I do not see why this yang model should forbid showing
> > running status of such configuration.
> >
> > I think this document should just say that the algorithm numbers are
> > from the IANA registry, and nothing more. There might be informal
> > reference to the RFC 8221, and RFC 8247 but even that should not be
> > needed, as anybody implementing IKEv2 or ESP will already follow those
> > and only implement the algorithms from there that they seem proper. In
> > some cases that selection might include algorithms which are on SHOULD
> > NOT or even MUST NOT, if the backward compatibility to obsolete
> > hardware is more important than conformance.
> >
> >>> This I-D, as you quote, points to RFC8247 for guidance and that is
> >>> fine. But security moves on and new algorithms will be needed and
> >>> this I-D also points to the IANA registry, which is Expert Review,
> >>> where new entries have been added already; and for those the IANA
> >>> Registry gives no guidance and the I-D that IANA references for
> >>> the new entries - written by the Expert Reviewer! - also gives no
> >>> guidance. Over time we are likely to accrue algorithms with no
> >>> guidance unless and until an RFC8247-bis appears or we require
> >>> IANA to have columns for guidance. Currently the new algorithms
> >>> are GOST and so perhaps of limited interest but on the TLS list I
> >>> am always seeing new algorithms appear and there the new IANA
> >>> entry is required to give guidance. My sense is that IKEv2 is a
> >>> bit slower to take up new ones but, as with RFC8247, it does
> >>> eventually.
> >
> > The original cryptographic algorithm impelemtation requirements for
> > ESP and AH was published as RFC4305 in 2007. It was replaced with
> > RFC7321 in 2014, and that was replaced with RFC8221 in 2017. For IKEv2
> > we skipped the 2014 update, as that was not needed. We do have plans
> > to keep that draft up to date, and update it when there is need for
> > that, most likely in next 5 years or so, provided that implementation
> > status of some of new algorithms progresses favorably.
> >
> >>> I think that users need those extra columns that RFC8247 provides
> >>> on the IANA website so that when new algorithms are added by
> >>> Expert Review, then that guidance must be added as well. This is
> >>> what the TLS WG came round to and I think that IKEv2 needs to do
> >>> the same.
> >
> > I as an Expert does not want to decide whether the individual request
> > to add new 3rot13 cipher to the IANA registry should be MUST NOT,
> > SHOULD NOT, MAY or what. If the field is in the IANA registry then
> > whoever requests to add information to there can request whatever
> > value they want for that field too. Of course as an IANA expert I can
> > reject that by saying that 3rot13 is not MUST, but it is MUST NOT
> > algorithm, and then we can have discussion about that.
> >
> > I rather have that discussion in the working group when we are
> > updating the requirements document next time. And as I said IANA
> > registries do not have any (public) history, or any way of finding out
> > why they got changed and who did the change. There has happened some
> > changes in the registry where I as an IANA Expert was not aware of at
> > all...
> >
> > And if I need to find out when ENCR_MAGMA_MGM_KTREE was added or
> when
> > some of those earlier algorithms was renamed, I need to go to my
> > private mail archives.
> >
> 
> _______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf