Reclassification of Suite B Documents to Historic Status

Note: This ballot was opened for revision 05 and is now closed.

(Eric Rescorla) Yes

(Ignas Bagdonas) No Objection

(Deborah Brungard) No Objection

(Ben Campbell) No Objection

(Alissa Cooper) No Objection

Benjamin Kaduk No Objection

Comment (2018-05-24)
No email
send info
Section 2 seems to implicitly assume that the only reason one would want to use
Suite B crypto is to comply with NSA/US Government requirements.
One could imagine that this is not always true; can we give more
guidance on why it's okay to hang out to dry such (hypothetical)
other consumers of Suite B (or why they are believed to be nonexistent)?

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2018-05-22)
No email
send info

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

Comment (2018-05-24)
No email
send info
I support the intent of this document. After looking at [CNSA] it took me some time to realize that although Suite B is moved to historic, the underlying cryptographic mechanisms are not considered broken (even if some of them are not recommended). For example, ECDH on Curve P-384 is present in both Suite B and CNSA.

So can I suggest that you add a sentence to the Abstract saying that while Suite B as a profile is declared historic, the underlying mechanisms are not necessarily historic. People who don't read beyond the Abstract might draw wrong conclusion otherwise!

Alvaro Retana No Objection

(Adam Roach) No Objection

Comment (2018-05-23)
No email
send info
Thanks to the authors for their work on this document.
I found two very small editorial nits that should be fixed
if any further changes to the document are made.



>   Other RFC make reference to these Suite-B-related RFCs; these
>   references are discussed in the following subsections.

Nit: "Other RFCs..."



>  RFC 7321, "Cryptographic Algorithm Implementation Requirements and
>  Usage Guidance for Encapsulating Security Payload (ESP) and
>  Authentication Header (AH) [RFC7321], points out that the AES-GCM

Nit: missing closing quotation mark.



>  RFC 8253, "PCEPS: Usage of TLS to Provide a Secure Transport for the
>  Path Computation Element Communication Protocol (PCEP)" [RFC8253],
>  points RFC 6460 for the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
>  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites.  Both of these
>  ciphersuites are defined in [RFC5289], which would have been a better
>  reference.

Not a comment for this document as much as a suggestion for further action by
the authors: is it worth filing an erratum on RFC 8253 to fix this?

Martin Vigoureux No Objection