Re: [secdir] Writing Security Considerations

> On 27 Jun 2019, at 15:50, Vincent Roca <vincent.roca@inria.fr> wrote:
> 
> Hello,
> 
> The two messages I would suggest:
> 	- You, authors, think everything is fine, that your proposal does not introduce any new threat. Think it twice (or more), 
> 	   there’s probably something that’s worth being said;

That just reads like “Be afraid. Be very afraid”. Yeah, we’re going to tell them to consider all security implications and implementation pitfalls. But without a concrete list of things to check, that’s just like Hill Street Blues’ “Let’s be careful out there"

> 	- And the Security Considerations section is also meant to help developers: in this specific case, it would have 
> 	  been nice to add a warning about this carbon copy in the reply packet, as we all discovered later.

Perhaps the broader lesson is to consider and call out whenever you are using a non-standard format. If a protocol is using JSON, CBOR, XML, YANG, or even ASN.1 you are going to be using some (hopefully) well-tested library that protects you from buffer overruns. When you roll your own format, like we do in things like TLS and IKE, the implementer is going to be writing a parser, and writing a parser is something that requires a level of care that should be called out.

> 
> I think it’s a good example of cool protocol feature that can turn into a security nightmare if wrongly implemented.
> It’s worth explaining IMHO.
> 
> But that’s just an idea, feel free to ignore my suggestion.

If you can suggest text for the slide/s, we’ll consider it.

> Cheers,
> 
>   Vincent
> 
> 
>> Le 27 juin 2019 à 14:15, Salz, Rich <rsalz@akamai.com <mailto:rsalz@akamai.com>> a écrit :
>> 
>> Well there’s also the fact that it was implemented in TLS but only intended for DTLS.
>>  
>> But yeah, I’m still not sure what the lesson learned is.
>>  
>> From: Yoav Nir <ynir.ietf@gmail.com <mailto:ynir.ietf@gmail.com>>
>> Date: Thursday, June 27, 2019 at 12:33 AM
>> To: Vincent Roca <vincent.roca@inria.fr <mailto:vincent.roca@inria.fr>>
>> Cc: "secdir@ietf.org <mailto:secdir@ietf.org>" <secdir@ietf.org <mailto:secdir@ietf.org>>
>> Subject: Re: [secdir] Writing Security Considerations
>>  
>> Hi, Vincent. 
>>  
>> Thanks, but I don’t know what kind of lesson there is in this for the general RFC-writing audience.
>>  
>> Always call out when you have internal length fields because that can be done dangerously in C?
>>  
>> I think mis-handling length fields has been an issue with protocols as long as protocols have been implemented.
>>  
>> Yoav
>> 
>> 
>>> On 26 Jun 2019, at 9:57, Vincent Roca <vincent.roca@inria.fr <mailto:vincent.roca@inria.fr>> wrote:
>>>  
>>> Hello Yoav and Linda, 
>>>  
>>> Good initiative.
>>>  
>>> Since you’re looking for stories, here is a proposal, rooted in real life.
>>> RFC6520 (https://tools.ietf.org/html/rfc6520 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6520&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=32H5KaerecFFfHL_RbK6_S3L5bwUE9K88_l69RYrvIQ&s=FbDzqETFX080s8nnVXHURz64o5cbrHAGdKknxxMVsBA&e=>) on TLS heartbeat extension has a pretty simple security considerations section: it says 
>>> it does not introduce any new security consideration and it refers to two existing RFCs.
>>>  
>>> We all know this TLS heartbeat extension has been the cause of the famous heartbleed OpenSSL vulnerability and associated attack.
>>> Of course the major problem comes from an erroneous implementation of the mechanism in OpenSSL:
>>> https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db9023b881d7cd9f379b0c154650d6c108e9a3 <https://urldefense.proofpoint.com/v2/url?u=https-3A__git.openssl.org_gitweb_-3Fp-3Dopenssl.git-3Ba-3Dcommitdiff-3Bh-3D96db9023b881d7cd9f379b0c154650d6c108e9a3&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=32H5KaerecFFfHL_RbK6_S3L5bwUE9K88_l69RYrvIQ&s=9FZTwoOauH47k_ngFMjQzuMPRb0jIWcs96Y0axdM9gY&e=>
>>>  
>>> The goal is not to blame anybody in person, especially as the RFC describes what should be done to prevent any problem.
>>> But I also think this is a document where we all (i.e., authors/secdir/IESG) should have highlighted the associated risk of badly
>>> implementing the response message in the Security Considerations section. As always in such a situation, it’s easier to say afterwards!
>>>  
>>> I think there is a way to say that in a positive way (lessons learned) and tell an interesting story many people heard about without knowing
>>> the details.
>>>  
>>> Cheers,
>>>  
>>>   Vincent
>>>  
>>>  
>>>> Le 25 juin 2019 à 20:57, Yoav Nir <ynir.ietf@gmail.com <mailto:ynir.ietf@gmail.com>> a écrit :
>>>>  
>>>> Hi, all 
>>>>  
>>>> If you’ve had a look at the draft agenda (https://datatracker.ietf.org/meeting/105/agenda.html <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_meeting_105_agenda.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=32H5KaerecFFfHL_RbK6_S3L5bwUE9K88_l69RYrvIQ&s=3UI7WQmwfyz7h1buiVZOY8g7D6K8ARLSHXArn_PYUBc&e=>), we have a Writing Security Considerations tutorial on Sunday, which Linda Dunbar and I will be doing.
>>>>  
>>>> The idea is to get people writing drafts to know what they should do for a smooth interaction with us SecDir people.
>>>>  
>>>> The slides do not exist yet, but we have a rough outline on github: https://github.com/IETF-SAAG/SecurityConsiderationsTutorial <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSAAG_SecurityConsiderationsTutorial&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=32H5KaerecFFfHL_RbK6_S3L5bwUE9K88_l69RYrvIQ&s=kMYyq9Tz5RZyqpaBjEPwSWYLw7P6jG9eqigfDeW1lNk&e=>
>>>>  
>>>> So if there’s missing or wrong stuff, we’d like to hear about it, preferably in the form of PRs.
>>>>  
>>>> But most of all, we’re looking for more examples in the examples page: https://github.com/IETF-SAAG/SecurityConsiderationsTutorial/blob/master/examples.md <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSAAG_SecurityConsiderationsTutorial_blob_master_examples.md&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=32H5KaerecFFfHL_RbK6_S3L5bwUE9K88_l69RYrvIQ&s=f1H6brU-13lYu1_rTmpXv5fGU5dc258l1UXuaIrOX3Y&e=>
>>>>  
>>>> So any horror story, war story, stuff that’s terribly wrong, or even something that’s surprisingly right will be welcome.
>>>>  
>>>> Thanks in advance
>>>>  
>>>> Linda & Yoav
>>>>  
>>>> _______________________________________________
>>>> secdir mailing list
>>>> secdir@ietf.org <mailto:secdir@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/secdir <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_secdir&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=32H5KaerecFFfHL_RbK6_S3L5bwUE9K88_l69RYrvIQ&s=6b6SRPf-vkkPvj-FrX-q8rwRHE1RCF54pOHVFQAkkRQ&e=>
>>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview <http://tools.ietf.org/area/sec/trac/wiki/SecDirReview>