Re: [saag] CFRG, CFRG crypto review panel and IETF consensus

[Paul Wouters <[e-mail]>]

On Thu, Apr 18, 2024 at 1:18 PM Watson Ladd <[e-mail]> wrote:

> Dear SAAG,
>
> I am quite confused about how the relation between IETF work and CFRG
> work and the crypto review panel is supposed to work.


The IESG, IAB and the ISE are hoping to clear this up.

In the SSH
> NTRUPrime discussion it appears that a negative report from the crypto
> review panel is reason not to standardize an algorithm choice or
> register it in the IETF space for a protocol


It was me as Security Area Director, not choosing to "AD Sponsor" a new
algorithm. This is not about "IETF standardization".
It was one of the inputs leading to my decision. Note that a more regular
way of getting a new algorithm into a protocol is for
a BoF and then Working Group to take on such work. The WG would hopefully
also take the opinion of CFRG into account.
Various IETF protools have a RECOMMENDED value that typically would only be
set for algorthms that have very broad
consensus from the IESG (and IRTF). Note that in this case SSH has a tweak
of this, as it only has an "OK to implement"
field. This was one other input in my decision, as I could not AD Sponsor
this with a RECOMMENDED set to NO, and I felt
specifying NTRUprime as an AD Sponsored RFC would be misinterpreted as to
what the consensus on recommended
status was.

Note also that I was never preventing NTRUprime from getting a code point
allocated in the SSH IANA Key Type registry,
so I was not blocking the deployment of NTRUprime within the IETF namespace.

I don't recall this being the way things used to work, and I think its
> had very negative effects on the way the CFRG functions, as well as
> stretching the IETF/IRTF distinction beyond the breaking point.


What are those negative effects this SSH discussion caused?
I agree in general with you, which for example can be seen by how many
types the HPKE RFC is references as a DOWN REF
due to it being an IRTF and not IETF document.



> Simply
> put having knock out contests like we did for curves and PAKES,
> combined with an endless series of reviews and last calls creates some
> very adversarial debates and raises tensions and hampers cooperation.
>

Right. I guess part of that is that the CFRG should ideally be one step
away from the implementers of the algorithms, but what
we are seeing is a lot of of them spearheading their own algorithms. This
makes it harder for the CFRG as a community to be
seen as a more independent evaluator of the wider (outside IETF)
cryptographic community.


> It also moves away from the running code part and rough consensus: if
> a group of people have made choices that work for them, we now make
> ourselves irrelevant by saying no


Again, this is incorrect. The IETF did not say no to NTRUprime for SSH. A
code point was requested and the Designated Experts
of the SSH registry approved it. I cannot yet point to the email audit
trail here because the [e-mail] was not
properly working when the request was made and approved, but this is being
addressed and backfilled.


> rather than trying to accommodate
> their concerns. The CFRG review panel is not well placed to have these
> conversations as it knows nothing of the broader context and has very
> limited interaction with the proposal.
>

It is still the best we have. It is better than a single AD listening to a
single author of an algorithm to make a decision.

It also puts the CFRG into a place where it is making standardization
> choices that properly being to the IETF, and not even the CFRG but a
> subpanel.


This is also not correct. It did not make a decision. It advised an AD,
whom made a decision on a specific process path to
an RFC that is a non-standard, exceptional path.  AD Sponsoring is not the
standard method for getting a cryptographic
algorithm standardized in the IETF, especially because the we would like to
discuss these in the wider IETF/IRTF communities.


> This isn't to say that we should abandon security examination of
> proposed algorithms, but it's pretty clear that we have treated
> cryptographic primitives very differently in ways that undermine core
> principles of the IETF process.
>

I guess I do not support this conclusion. The path that should have been
followed for something like NTRUprime should be
similar to the one followed by "ChaCha20 and Poly1305 for IETF Protocols".
See
https://datatracker.ietf.org/doc/draft-irtf-cfrg-chacha20-poly1305/history/

Note that if you are worried about the CFRG backlog, adding additional
algorithms for evaluation for IETF usage should be carefully considered.
Based on my personal information gathering, those resources are perhaps not
best spend on NTRUprime at this point in time (and yes I
understand not everyone agrees).

SSH was one of the last IANA registries we fixed a few months ago to be
able to get new code points without needing RFCs. So if anything, we have
lately _improved_ our process to allow people to run whatever crypto they
want to run. The IETF is not blocking anyone from using their favourite
cryptography
within IETF protocols.

The value of an RFC comes from the IETF/IRTF communities and their careful
considerations, consensus forming, operational experience and maintenance of
the specifications defined. That having an RFC number can act as a status
symbol for nation states, algorithm authors, enterprises, competitions and
others, and
that vendors use RFC numbers to allocate their own limited engineering
capabilities is unfortunate.

RFCs have a cost and as you have seen, resources within the IETF and IRTF
are limited. Choices need to be made and we try to have community processes
to steer this while
being flexible enough to cater to exceptions. The goal of the IETF is to
make the internet work better. RFCs are just one part of that.

Again, stay tuned for the IESG, IAB and ISE trying to bring more clarity to
the specific processes related to cryptography.

Paul
-- 
bad type setting is solely the fault of gmail :)