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

[Watson Ladd <[e-mail]>]

On Fri, Apr 19, 2024 at 5:43 PM Paul Wouters <[e-mail]> wrote:
>
>
> 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.

I would like to have a discussion where people who participate in the
relevent fora and draft authors can raise their concerns. Saying the
IESG, IAB and ISE are going to come on from on high to sort it doesn't
fill me with confidence. The SSH draft prompted me to write the email,
but as I've said in other emails, it isn't a great example of the
problem.

>
>
>>
>> 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's been a decade since CFRG decided to standardize a PAKE. The draft
of the contest winner (not something that IETF ever does well) that
everyone agrees is the best has taken 4 years since the contest was
held to be published. Then the SPAKE2 draft got published without a
consensus statement despite having gone through RGLC, as well as being
referenced by a Kerberos draft. CPACE, which is the winner in the
other category has likewise not been published, and the feature that
let it edge out SPAKE2 proved to be pretty problematic in the actual
writing and integration with IETF protocols. I don't think any of this
was because implementors (distinct from people who write papers) were
participating. Generally that's a positive: someone has to make the
running code after all, and groups with a tight integration between
participant and implementor do function well at the IETF.

RFC 9497, and assorted drafts took five years. Thankfully blind RSA
took a comparatively speedy 2 years. This isn't a terribly rewarding
environment for young academics, who face evaluation on similar
timescales. It's difficult to justify the effort even commercially if
it isn't really needed to get things out there.

>
> 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.

If vendors didn't think that they should support RFCs that were
applicable above their own proprietary extensions or alternate
standards, there wouldn't be any consensus forming worth noting. And
if standardization didn't matter to authors, people wouldn't
participate. I don't think having the RFC number is inherently
attractive enough to justify spending the sums on travel that
participants and their employers do to participate. Rather it's
because there is value in having the way things work be broadly agreed
upon and not exclude anyone that the IETF is valuable to participate
in and hence becomes the forum for operational experience and
maintenance to be shared.

OpenSSL has a policy of only adding features to TLS that have an RFC
finished, and are very reluctant to add things without a spec. So for
a large proportion of the internet, either there is an RFC or it will
never get made for the single most important cryptographic protocol.
In the case of cryptographic algorithms there are ways around it, but
for protocol features it's a challenge.

>
> 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 :)

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim