Re: [secdir] Writing Security Considerations

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;
	- 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.

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.
Cheers,

  Vincent

> Le 27 juin 2019 à 14:15, Salz, Rich <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>
> Date: Thursday, June 27, 2019 at 12:33 AM
> To: Vincent Roca <vincent.roca@inria.fr>
> Cc: "secdir@ietf.org" <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