Re: RFC 9205 vs. CL0P

Definitely awkward right off the bat. I consider HTTP an application protocol, which I use to build application interfaces. Calling it "Building API's With HTTP" would similarly confuse, because folks aren't thinking of allowing their application to be programmed. It's like trying to describe Math or Physics to a beginner, from the perspective of non-Euclidean Geometry or non-Newtonian Physics.



-Eric







---- On Wed, 23 Aug 2023 00:26:00 -0700 Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote ---



Hello everybody, 
 
Before complaining that nobody reads RFCs (which is of course a 
problem), please note that BCP 56 (RFC 9205) is entitled 
"Building Protocols with HTTP", 
which will easily lead a potential reader to say "that's not for me, I'm 
just using HTTP, no new protocol here". 
 
Regards,   Martin. 
 
On 2023-08-22 16:49, Seph Gentle wrote: 
> We could. But I doubt it would help. 
> 
> Frankly, I suspect less than 1% of working software developers have ever actually read any RFC (or BCP) published by the IETF. And the people who read specs aren't the people who need to be told not to run unauthenticated SQL queries on port 80. 
> 
> I was invited a few times to give guest lectures about computer science at General Assembly. For those who don't know, they run a 3 month "coding bootcamp", where they teach people just enough information about software development to get their foot in the door in the industry. Of their 60 classroom days, 0 of them are devoted to security. Their program seems to teach the philosophy of "If it seems to work, ship it". Needless to say, their students have no idea what the IETF is. They don't read any BCP documnets in their course. And despite writing web software, students graduate without really knowing HTTP. 
> 
> If you want to stop these ridiculous security vulnerabilities with education, it is those students you need to reach somehow. We could change some of the 9000 or so words in BCP56 to teach some information security. But it won't stop MoveIt from shipping insecure code. If they hired the sort of people who read BCP documents, I doubt they would have made these sort of mistakes in the first place. 
> 
> For my money, as an industry I think we need to solve this via the legal system. Harm caused by insecure software should be treated the same way that we treat harm caused by negligent builders, or negligent handling of food resulting in food poisoning. There should be much stricter penalties for data breaches like this. And companies shouldn't be able to wish away their liability with a EULA. If data security was an existential risk for companies, you bet security would become an essential part of their product development processes. 
> 
> But I think campaigning for this isn't part of the IETF's remit. We could change the BCP document, but I doubt it'll stem the tide of sloppy, insecure code. 
> 
> -Seph