Skip to main content

Reclassification of Suite B Documents to Historic Status
RFC 8423

Yes

(Eric Rescorla)

No Objection

Alvaro Retana
(Alissa Cooper)
(Ben Campbell)
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)
(Suresh Krishnan)
(Terry Manderson)

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

Alvaro Retana No Objection

Warren Kumari No Objection

Comment (2018-05-22)
LGTM.

(Eric Rescorla; former steering group member) Yes

Yes ()

                            

(Adam Roach; former steering group member) No Objection

No Objection (2018-05-23)
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.

---------------------------------------------------------------------------

§4:

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

Nit: "Other RFCs..."


---------------------------------------------------------------------------

§4.3:

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

---------------------------------------------------------------------------

§4.5:

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

(Alexey Melnikov; former steering group member) No Objection

No Objection (2018-05-24)
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!

(Alissa Cooper; former steering group member) No Objection

No Objection ()

                            

(Ben Campbell; former steering group member) No Objection

No Objection ()

                            

(Benjamin Kaduk; former steering group member) No Objection

No Objection (2018-05-24)
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)?

(Deborah Brungard; former steering group member) No Objection

No Objection ()

                            

(Ignas Bagdonas; former steering group member) No Objection

No Objection ()

                            

(Martin Vigoureux; former steering group member) No Objection

No Objection ()

                            

(Suresh Krishnan; former steering group member) No Objection

No Objection ()

                            

(Terry Manderson; former steering group member) No Objection

No Objection ()