Re: [saag] SSH & Ntruprime

[Simon Josefsson <[e-mail]>]

I think there are many orthogonal issues that are being discussed in a
conflated and heated way here.  Perhaps it will help to break them up
into some separate questions related to the document:

  1) Whether to add sntrup761x25519-sha512 to the IANA SSH "Key Exchange
     Method Names" registry.  Before RFC 9519 the policy for allocation
     was IETF Review, but is now Expert Review.  We endured a lengthy
     process getting RFC 8731 published, which covers a similar
     situation: OpenSSH led the way and moved to curve25519-sha256
     before the IETF wanted to touch anything related to Curve25519, and
     we came to the IETF asking to document a widely deployed protocol.
     This may have lead to the process changes in RFC 9519.

     IANA has already reviewed the registration request and indicated
     'IANA OK' and the IANA expert review state also says 'Expert
     Reviews OK'.  Feedback from document reviewers can be seen here:
     https://datatracker.ietf.org/doc/draft-josefsson-ntruprime-ssh/

     The mailing list indicated in RFC 9519 does not work, so the
     process to follow the current registration procedure is broken.  I
     escalated this back in January but no change so far.

     As far as I can tell, the expert review process is less about value
     judgement on particular algorithms/protocols and more about
     following due process and that the namespace doesn't become crowded
     (it is infinite in this case).

  2) If the Internet community would benefit from having protocols
     widely deployed on the Internet in a stable document like an RFC.
     I find it surprising that people argue against this.  It may help
     re-visit the mission of the IETF is in the first place.  What
     benefit is there to not document a description of a protocol that
     is widely deployed?  It will make the IETF less relevant as a place
     where people go for documentation on Internet protocols.

  3) The standardization level of the proposed protocol.  The document
     is INFORMATIONAL and the implementation advice is MAY and has been
     so the entire time, merely because it is not proposed as a standard
     protocol.

  4) If sntrup761 is a good cryptographic algorithm.  I believe this
     question is irrelevant for the decision to publish a document.
     Certainly known facts should be covered in the Security
     Considerations section, and if you want to help improve the
     document, that would be appreciated.  As an illustration: if
     OpenSSL and Chrome deployed a TLS cipher suite "ROT13-no-MAC" and a
     significant portion of the Internet started to use it tomorrow, to
     me that suggests having documentation of that protocol as an RFC is
     beneficial to everyone so they can get interop working.  The
     Security Considerations could accurately describe what is currently
     known about the security of "ROT13-no-MAC", and using INFORMATION
     rather than STANDARDS TRACK seems appropriate.

     I think the Crypto Review Panel has a unclear charter and role in
     the IETF ecosystem, and that undue weight on one person's opinion
     is made here.  Is the role of the CRP part of any IETF process
     documents?  As far as I can tell, it has no decision making
     authority, but historically been a tool for the non-IETF CFRG WG.
     The panel could adopt a similar process as most IETF Area
     Directorates.  Compare how most SECDIR review are phrased: they
     evaluate things related to security and ask for those facts to be
     accurately covered by the document, which seems different in style
     compared to the review made here.  See
     https://wiki.ietf.org/group/secdir/SecDirReview

  5) Process issues regarding decision making.  The document was AD
     sponsored by Roman (on the recommendation from SECDISPATCH) and
     I've seen no decision from him to hand over AD-sponsorship to
     someone else or a decision to stop AD sponsor it.  Have I missed
     were that was published?  How are those two decisions regarded by
     IETF policys?

/Simon