Re: [Pearg] [saag] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?

[Tony Rutkowski <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag