Subject: [secdir] Writing Security Considerations

From: Yoav Nir <[email-masked]>
Date: Tue, 25 Jun 2019 21:57:38 +0300

Hi, all

If you’ve had a look at the draft agenda (https://datatracker.ietf.org/meeting/105/agenda.html <https://datatracker.ietf.org/meeting/105/agenda.html>), 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://github.com/IETF-SAAG/SecurityConsiderationsTutorial>

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://github.com/IETF-SAAG/SecurityConsiderationsTutorial/blob/master/examples.md>

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

---

From: Vincent Roca <[email-masked]>
Date: Wed, 26 Jun 2019 08:57:44 +0200

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://tools.ietf.org/html/rfc6520>) 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://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db9023b881d7cd9f379b0c154650d6c108e9a3>

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 <[email-masked]> a écrit :
> 
> Hi, all
> 
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Yoav Nir <[email-masked]>
Date: Thu, 27 Jun 2019 07:33:07 +0300

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 <[email-masked]> wrote:
> 
> Hello Yoav and Linda,
> 
> Good initiative.
> 
>> Le 25 juin 2019 à 20:57, Yoav Nir <[email-masked] <mailto:[email-masked]>> a écrit :
>> 
>> Hi, all
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 27 Jun 2019 12:15:09 +0000

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 <[email-masked]>
Date: Thursday, June 27, 2019 at 12:33 AM
To: Vincent Roca <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [secdir] Writing Security Considerations

Hi, Vincent.

Yoav

On 26 Jun 2019, at 9:57, Vincent Roca <[email-masked]<mailto:[email-masked]>> 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=>

Cheers,

  Vincent

Le 25 juin 2019 à 20:57, Yoav Nir <[email-masked]<mailto:[email-masked]>> 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 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=>

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=>

Thanks in advance

Linda & Yoav

_______________________________________________
secdir mailing list
[email-masked]<mailto:[email-masked]>
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

---

From: Vincent Roca <[email-masked]>
Date: Thu, 27 Jun 2019 14:50:03 +0200

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 <[email-masked]> a écrit :
> 
>> On 26 Jun 2019, at 9:57, Vincent Roca <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Hello Yoav and Linda, 
>>  
>> Good initiative.
>>  
>> 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 
>> 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=>
>>  
>>> 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 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=>
>>>  
>>> 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=>
>>>  
>>> 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=>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 27 Jun 2019 16:47:20 +0000

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 <[email-masked]> On Behalf Of Vincent Roca
Sent: Thursday, June 27, 2019 7:50 AM
To: Salz, Rich <[email-masked]>; Yoav Nir <[email-masked]>
Cc: secdir <[email-masked]>
Subject: Re: [secdir] Writing Security Considerations

Hello,

  Vincent

Le 27 juin 2019 à 14:15, Salz, Rich <[email-masked]<mailto:[email-masked]>> a écrit :

From: Yoav Nir <[email-masked]<mailto:[email-masked]>>
Date: Thursday, June 27, 2019 at 12:33 AM
To: Vincent Roca <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [secdir] Writing Security Considerations

Hi, Vincent.

Yoav

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>

Cheers,

  Vincent

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

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>

Thanks in advance

Linda & Yoav

_______________________________________________
secdir mailing list
[email-masked]<mailto:[email-masked]>
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>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 27 Jun 2019 19:48:41 +0300

> On 27 Jun 2019, at 15:50, Vincent Roca <[email-masked]> wrote:
> 
> Hello,
> 

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"

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

> 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 <[email-masked] <mailto:[email-masked]>> a écrit :
>> 
>> From: Yoav Nir <[email-masked] <mailto:[email-masked]>>
>> To: Vincent Roca <[email-masked] <mailto:[email-masked]>>
>> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview <http://tools.ietf.org/area/sec/trac/wiki/SecDirReview>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 27 Jun 2019 19:26:45 -0500

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

This thread is rather apropos, as one of the items the IESG is working on
is assembling some "hot topic" items from each area that regularly recur as
issues arising at IESG evaluation or IETF LC.  The idea would be that ADs,
and perhaps WG chairs as well, would have some better visibility into what
other Areas' review will look for, and avoid "late surprises" for document
authors that were not thinking about any given topic.

Roman and I just earlier today assembled a first cut at such "hot topics"
for the security area:
https://trac.ietf.org/trac/sec/wiki/TypicalSECAreaIssues .  It's not
exactly a checklist, but could probably be turned into one without too much
work.

Please take a look and make/suggest improvements -- it's a wiki, after all!

-Ben