Subject: [dtn] Default-sc-01

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Fri, 19 Feb 2021 05:27:51 +0000

Hi, Magnus.  Here are the Document Shepherd write-up and accompanying Document Announcement I've come up with for the BPSec Default Security Contexts specification.  There are nits, but we would like to address them in the course of the review.

Scott

---

From: "R. Atkinson" <[email-masked]>
Date: Fri, 19 Feb 2021 10:10:38 -0500

All,

I would be very surprised if the IETF Security Area were interested in spending much time reviewing a document that lacked a "Security Considerations” section, since that part of the document often is the primary focus of IETF Security Area reviews.

This note perhaps provides some suggestions with an eye towards creating a “Security Considerations” section for this document.  I think reviews will go more easily if the document has a meaningful “Security Considerations” section before it goes out for review.

1. The reference to RFC-4634 likely should be replaced by a reference to RFC-6234 — or BETTER by these two more authoritative and equally public/accessible references, one for the HMAC procedure and the second for SHA-2:

“US NIST, “The Keyed-Hash Message Authentication Code (HMAC)”, FIPS-198-1, US NIST, Gaithersburg, MD, USA, July 2008.  http://csrc.nist.gov/publications”

“US NIST, “Secure Hash Standard (SHS)”, FIPS 180-4, US NIST, Gaithersburg, MD, USA, August 2015.  http://csrc.nist.gov/publications”

2.  In Section 3.5, I am startled that the document provides no advice to protect keys when stored or distributed.  The existing text in 3.5 should be edited and also the "Security Considerations” section ought to strongly recommend that and also note that in the event any key(s) are compromised, then neither authentication nor integrity will be provided.

3. In Section 4 & in Security Considerations, special attention should be made to the cautions about the uniqueness requirements for GCM which are noted in Section 8 & also in Appendix A of [AES-GCM].  This is critical whenever GCM is used.  Sadly, this requirement of GCM is either ignored or not understood by many implementers of other IETF protocols which use GCM.  So it is important to call this out specifically.  Perhaps also add a citation to [AES-GCM] to the last paragraph of Section 4.3.1 of this document and point specifically to Appendix A in that citation.

This document’s "Security Considerations" also should discuss the attacks on GCM described in Appendix B and the corresponding mitigations described in Appendix C of [AES-GCM].

Appendix D of [AES-GCM] discusses limitations relative to replay attacks, which also should be mentioned and discussed in this document's “Security Considerations”.

(Aside:  I have no special issues with GCM as a cryptographic mode to specify here, but GCM does have specific requirements which implementers need to follow and which ordinary software/firmware developers generally are not aware of.  An important purpose for IETF “Security Considerations” sections is to point these types of things out very clearly, so a naive but well-intentioned developer can implement in a reasonably secure way. :-)

4. I would suggest reviewing the text in RFC-8152, Section 17, “Security Considerations” with an eye to adapting that text for inclusion in the “Security Considerations” section needed for this document.

Yours,

Ran

> On Feb 19, 2021, at 00:27, Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]> wrote:
> 
> <defsc shepherd writeup.docx><defsc document announcement.txt>_______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn

---

From: "Birrane, Edward J." <[email-masked]>
Date: Fri, 19 Feb 2021 15:51:28 +0000

Ran,

  Thank you for the document review.

  Scott noted the lack of security considerations section - there was a question as to how much to put in a Security Considerations section that wasn't already covered in the individual BIB and BCB sections and otherwise documented in references. However, your clarification:

> An important purpose for IETF “Security Considerations”
> sections is to point these types of things out very clearly, so a naive but well-
> intentioned developer can implement in a reasonably secure way. :-)

  Makes perfect sense. We should have a Security Considerations section for that purpose.

  Otherwise, in addition to providing such a section, I agree that using up-to-date, authoritative references is necessary, as is noting that keys should be protected when stored or distributed.

-Ed 

---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

> -----Original Message-----
> From: R. Atkinson <[email-masked]>
> Sent: Friday, February 19, 2021 10:11 AM
> To: Birrane, Edward J. <[email-masked]>; Burleigh, Scott C
> <[email-masked]>
> Cc: Magnus Westerlund <[email-masked]>; iesg-
> [email-masked]; [email-masked]
> Subject: [EXT] Re: [dtn] Default-sc-01
> 
> APL external email warning: Verify sender [email-masked] before clicking
> links or attachments
> 
> All,
> 
> I would be very surprised if the IETF Security Area were interested in
> spending much time reviewing a document that lacked a "Security
> Considerations” section, since that part of the document often is the primary
> focus of IETF Security Area reviews.
> 
> This note perhaps provides some suggestions with an eye towards creating a
> “Security Considerations” section for this document.  I think reviews will go
> more easily if the document has a meaningful “Security Considerations”
> section before it goes out for review.
> 
> 
> 1. The reference to RFC-4634 likely should be replaced by a reference to RFC-
> 6234 — or BETTER by these two more authoritative and equally
> public/accessible references, one for the HMAC procedure and the second
> for SHA-2:
> 
> “US NIST, “The Keyed-Hash Message Authentication Code (HMAC)”, FIPS-
> 198-1, US NIST, Gaithersburg, MD, USA, July 2008.
> http://csrc.nist.gov/publications”
> 
> “US NIST, “Secure Hash Standard (SHS)”, FIPS 180-4, US NIST, Gaithersburg,
> MD, USA, August 2015.  http://csrc.nist.gov/publications”
> 
> 
> 2.  In Section 3.5, I am startled that the document provides no advice to
> protect keys when stored or distributed.  The existing text in 3.5 should be
> edited and also the "Security Considerations” section ought to strongly
> recommend that and also note that in the event any key(s) are
> compromised, then neither authentication nor integrity will be provided.
> 
> 3. In Section 4 & in Security Considerations, special attention should be made
> to the cautions about the uniqueness requirements for GCM which are
> noted in Section 8 & also in Appendix A of [AES-GCM].  This is critical
> whenever GCM is used.  Sadly, this requirement of GCM is either ignored or
> not understood by many implementers of other IETF protocols which use
> GCM.  So it is important to call this out specifically.  Perhaps also add a citation
> to [AES-GCM] to the last paragraph of Section 4.3.1 of this document and
> point specifically to Appendix A in that citation.
> 
> This document’s "Security Considerations" also should discuss the attacks on
> GCM described in Appendix B and the corresponding mitigations described in
> Appendix C of [AES-GCM].
> 
> Appendix D of [AES-GCM] discusses limitations relative to replay attacks,
> which also should be mentioned and discussed in this document's “Security
> Considerations”.
> 
> (Aside:  I have no special issues with GCM as a cryptographic mode to specify
> here, but GCM does have specific requirements which implementers need
> to follow and which ordinary software/firmware developers generally are
> not aware of.  An important purpose for IETF “Security Considerations”
> sections is to point these types of things out very clearly, so a naive but well-
> intentioned developer can implement in a reasonably secure way. :-)
> 
> 4. I would suggest reviewing the text in RFC-8152, Section 17, “Security
> Considerations” with an eye to adapting that text for inclusion in the
> “Security Considerations” section needed for this document.
> 
> Yours,
> 
> Ran
> 
> > On Feb 19, 2021, at 00:27, Burleigh, Scott C (US 312B)
> <scott.c.burleigh=[email-masked]> wrote:
> >
> > Hi, Magnus.  Here are the Document Shepherd write-up and accompanying
> Document Announcement I've come up with for the BPSec Default Security
> Contexts specification.  There are nits, but we would like to address them in
> the course of the review.
> >
> > Scott
> > <defsc shepherd writeup.docx><defsc document
> announcement.txt>___________________________________________
> ____
> > dtn mailing list
> > [email-masked]