Re: [secdir] Writing Security Considerations

[Linda Dunbar <[e-mail]>]

I see many drafts from Routing Area and Ops Areas have the similar writing on Security Considerations as RFC6520.
For many people in Routing and Ops, Security is not on their mind, even with Thinking Multiple times.

It will be more helpful to compose a list of Security Check List. Draft authors can go through the list to be reminded of potential security risks introduced by the draft proposed mechanisms.

Linda

From: secdir <[e-mail]> On Behalf Of Vincent Roca
Sent: Thursday, June 27, 2019 7:50 AM
To: Salz, Rich <[e-mail]>; Yoav Nir <[e-mail]>
Cc: secdir <[e-mail]>
Subject: 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Date: Thursday, June 27, 2019 at 12:33 AM
To: Vincent Roca <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__tools.ietf.org_html_rfc6520%26d%3DDwMFaQ%26c%3D96ZbZZcaMF4w0F4jpN6LZg%26r%3D4LM0GbR0h9Fvx86FtsKI-w%26m%3D32H5KaerecFFfHL_RbK6_S3L5bwUE9K88_l69RYrvIQ%26s%3DFbDzqETFX080s8nnVXHURz64o5cbrHAGdKknxxMVsBA%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cbe1607e3887d44118d9708d6fafe1082%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636972366461270746&sdata=%2Be8dQAiiMhX8aq2JBn%2BPLCAK1pi%2FfeSnyIBADT0KMnI%3D&reserved=0>) 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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__git.openssl..org_gitweb_-3Fp-3Dopenssl.git-3Ba-3Dcommitdiff-3Bh-3D96db9023b881d7cd9f379b0c154650d6c108e9a3%26d%3DDwMFaQ%26c%3D96ZbZZcaMF4w0F4jpN6LZg%26r%3D4LM0GbR0h9Fvx86FtsKI-w%26m%3D32H5KaerecFFfHL_RbK6_S3L5bwUE9K88_l69RYrvIQ%26s%3D9FZTwoOauH47k_ngFMjQzuMPRb0jIWcs96Y0axdM9gY%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cbe1607e3887d44118d9708d6fafe1082%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636972366461280740&sdata=zyswYpFDTktpKWf7F6mk8gSQjoOTpGrQ1NUq20ojA%2FU%3D&reserved=0>

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 <[e-mail]<mailto:[e-mail]>> a écrit :

Hi, all

If you’ve had a look at the draft agenda (https://datatracker.ietf.org/meeting/105/agenda.html<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__datatracker..ietf.org_meeting_105_agenda.html%26d%3DDwMFaQ%26c%3D96ZbZZcaMF4w0F4jpN6LZg%26r%3D4LM0GbR0h9Fvx86FtsKI-w%26m%3D32H5KaerecFFfHL_RbK6_S3L5bwUE9K88_l69RYrvIQ%26s%3D3UI7WQmwfyz7h1buiVZOY8g7D6K8ARLSHXArn_PYUBc%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cbe1607e3887d44118d9708d6fafe1082%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636972366461290735&sdata=RDwcMInt7Yx%2FHyNug8ayYPBkYb7%2FMXPy3hcGXOr88io%3D&reserved=0>), 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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_IETF-2DSAAG_SecurityConsiderationsTutorial%26d%3DDwMFaQ%26c%3D96ZbZZcaMF4w0F4jpN6LZg%26r%3D4LM0GbR0h9Fvx86FtsKI-w%26m%3D32H5KaerecFFfHL_RbK6_S3L5bwUE9K88_l69RYrvIQ%26s%3DkMYyq9Tz5RZyqpaBjEPwSWYLw7P6jG9eqigfDeW1lNk%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cbe1607e3887d44118d9708d6fafe1082%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636972366461290735&sdata=A7A48mIPGRQ9y2EbjfUw%2Bn%2BvA0xl8owyTA8CfMcl0ps%3D&reserved=0>

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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_IETF-2DSAAG_SecurityConsiderationsTutorial_blob_master_examples.md%26d%3DDwMFaQ%26c%3D96ZbZZcaMF4w0F4jpN6LZg%26r%3D4LM0GbR0h9Fvx86FtsKI-w%26m%3D32H5KaerecFFfHL_RbK6_S3L5bwUE9K88_l69RYrvIQ%26s%3Df1H6brU-13lYu1_rTmpXv5fGU5dc258l1UXuaIrOX3Y%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cbe1607e3887d44118d9708d6fafe1082%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636972366461300727&sdata=hT51%2Bgdtzn5BH0c9gbBDbxekd2uBByae8YDXfs3qeh4%3D&reserved=0>

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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/secdir<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_secdir%26d%3DDwMFaQ%26c%3D96ZbZZcaMF4w0F4jpN6LZg%26r%3D4LM0GbR0h9Fvx86FtsKI-w%26m%3D32H5KaerecFFfHL_RbK6_S3L5bwUE9K88_l69RYrvIQ%26s%3D6b6SRPf-vkkPvj-FrX-q8rwRHE1RCF54pOHVFQAkkRQ%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cbe1607e3887d44118d9708d6fafe1082%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636972366461300727&sdata=EYUr5SBgNDlQOUF9AI7t2LwSJlcXFszlog2iCtCKNFw%3D&reserved=0>
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview<https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2Farea%2Fsec%2Ftrac%2Fwiki%2FSecDirReview&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cbe1607e3887d44118d9708d6fafe1082%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636972366461310723&sdata=p0WeLfYi23bSD6sslNFoAYyizebY0ruewP1%2BdCFyIpc%3D&reserved=0>