Re: [saag] SSH & Ntruprime

[Stephen Farrell <[e-mail]>]

Hiya,

FWIW, I agree with Simon's arguments #1-#3 below.

WRT #4, I think sntrup761 is credible enough so
that, given it's deployment, there's a benefit in
documenting that as per the draft. I would not
think the same about rot-13 or something known to
be broken.

WRT #5, AD sponsorship is an individual decision,
so, process-wise, it's entirely fine that different
ADs take different positions, and that things can
change in the face of IESG personnel or role changes.

All that said, I do continue to think that the right
outcome here is AD sponsorship, so I hope some AD
picks it up and processes it.

Cheers,
S.

On 10/04/2024 10:20, Simon Josefsson wrote:
> 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
> 
> 
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag