[saag] Re: RFCs vs Standards

[John Mattsson <[e-mail]>]

Hi,


  *   I don’t see the need to have any specific rules for cryptographic algorithms. Most vulnerabilities are in how algorithms are used, not the algorithms themselves. It is hard to see why a registration securely using alg X would be rejected when there are many RFCs published that uses no encryption or known algorithms in a bad way.


  *   Internet-drafts are obviously "permanent and readily available", I don’t see why that is debated. For registries wanting RFCs there is “RFC required”. I am against any registry saying that "permanent and readily available" internet-drafts are NOT OK, but pointing to a website outside of the IETF is…


  *   I think we have benefited greatly from informal RFCs but saying that we have benefited from the “ambiguity” is strange.


  *   I don’t like a push for more standard track RFCs. I think there are way too many standard tracks RFC. I would like standard track to mean good security. I would like to see much less standard track security related RFCs. Many standard track security related RFCs does not deserve to be standard track. Some recent examples I have come across are RFC 4568 (SDES), RFC 4895 (SCTP-AUTH), RFC 6083 (DTLS over SCTP), RFC 9048 (EAP-AKA’). My efforts to get SDES historic was not successful [1]. Recently EAP-AKA’ (which does not have acceptable security) was made standard track just so EAP-AKA-FS could be made standard track. Once published as a standard track RFC, it is very hard to lower the status. I think standard track should expire automatically. Other SDOs often have a lot of trust in and respect of the IETF. If they see a standards track RFC, they often believe in offers state-of-the-art security like 3GPP did with RFC 6083 and RFC 4895. People finding a link like [2] in their search engine does not even see that TLS 1.0 is not standard track anymore. That we have a lot of substandard security protocols deployed creates an incitement for attacks [3][4].

[1] https://www.youtube.com/watch?v=0FmJQbRFs7A
[2] https://www.rfc-editor.org/rfc/rfc2246.txt
[3] https://www.washingtonpost.com/national-security/2024/11/21/salt-typhoon-china-hack-telecom/
[4] https://theintercept.com/2015/02/19/great-sim-heist/

Cheers,
John