Hi Alan,
Actually, NIST has no authority to mandate anything related to
encryption protocols - which is why the SP title is "guidance." SPs are
referenced by other agencies that have authority - primarily for
procurement purposes. The SP is also U.S. based with nuanced language
concerning "support." The implementation and use has also been modified
by NSA PP-20-1302. See
https://media.defense.gov/2021/Jan/05/2002560140/-1/-1/0/ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF
All of this is for good policy reasons and industry security concerns
that resulted in ETSI's development of the Middlebox Security Protocol
standards suite, especially TS 103 523-3, "Middlebox Security Protocol;
Part 3: Enterprise Transport Security," for TLS 1.3 implementations.
See
https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.03.01_60/ts_10352303v010301p.pdf
NIST itself has undertaken a NCCoE initiative to deal with the related
challenges. See
https://www.nccoe.nist.gov/sites/default/files/legacy-files/tls-1.3-visibility-project-description-draft.pdf.
ETSI has established the Encrypted Traffic Integration Industry Group.
See https://portal.etsi.org/tb.aspx?tbid=888&SubTB=888#/
Finally, the European Union - which very much has regulatory authority -
has published Resolution (EC) 13084/1/20, Council Resolution on
Encryption - Security through encryption and security despite
encryption,
https://data.consilium.europa.eu/doc/document/ST-13084-2020-REV-1/en/pdf
All of this may explain the lack of "boots on the ground" in the IETF.
The boots have moved to other more pragmatic, real-world ground. :-)
best,
tony
On 1/5/2023 10:18 AM, Alan DeKok wrote:
On Jan 5, 2023, at 8:58 AM, Eric Rescorla <ekr@xxxxxxxx> wrote:
3. Essentially none of these threats are the province of the IETF,
which defines networking protocols.
The output of the IETF is networking protocols. The input of the IETF is "good will" effort from individuals and corporations. Corporations whose highest priority is to ship hardware which can run "Flappy Bird" at double the frame rate and resolution of the previous version.
Witness the experience John and I had trying to update EAP for TLS 1.3. While NIST published a document in 2019 [1] mandating all government suppliers support TLS 1.3 by 2024, actual "boots on the ground" effort has been lacking. The afore-mentioned corporations shipping new hardware have been conspicuously absent in all relevant technical discussions.
i.e. the security of literally billions of devices depended on John, and one highly opinionated Open Source person who isn't being paid to be here.
We need to do better.
The work in the IETF is often done by people who are senior enough to be allowed to be involved, or who are independent enough to care. In many organizations, people with operational and/or implementation experience are often too junior to be allowed to participate. This has been my experience in many WGs.
I've been reading all of this discussion about protocols and legislation with a bit of amusement. I see all that as necessary, but it is not sufficient. My (and Johns) experience with EAP highlights this. If we hadn't chosen to do the work, there's a good chance that it either wouldn't have been done, or would have been done too late to meet legislated time frames.
The IESG and the IAB should take a serious look at which protocols need updating. They should see which people are allowed to be involved in the IETF, and where in the company they sit. They should find ways to get more participation from people who have operational and implementation experience.
Until that happens, the input of the IETF is insufficient "good will" to secure core protocols. The output of the IETF is window dressing. The foundation of the Internet is built on sand.
Alan DeKok.
[1] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf
_______________________________________________
saag mailing list
saag@xxxxxxxx
https://www.ietf.org/mailman/listinfo/saag
