ci: add duvet config

Author: camshaft

.duvet/.gitignore

@@ -0,0 +1 @@
+reports/

.duvet/config.toml

@@ -0,0 +1,74 @@
+'$schema' = "https://awslabs.github.io/duvet/config/v0.4.0.json"
+
+[[source]]
+pattern = "api/**/*.[ch]"
+comment-style = { meta = "*=", content = "*#" }
+
+[[source]]
+pattern = "bin/**/*.[ch]"
+comment-style = { meta = "*=", content = "*#" }
+
+[[source]]
+pattern = "crypto/**/*.[ch]"
+comment-style = { meta = "*=", content = "*#" }
+
+[[source]]
+pattern = "error/**/*.[ch]"
+comment-style = { meta = "*=", content = "*#" }
+
+[[source]]
+pattern = "stuffer/**/*.[ch]"
+comment-style = { meta = "*=", content = "*#" }
+
+[[source]]
+pattern = "tests/**/*.[ch]"
+comment-style = { meta = "*=", content = "*#" }
+
+[[source]]
+pattern = "tls/**/*.[ch]"
+comment-style = { meta = "*=", content = "*#" }
+
+[[source]]
+pattern = "utils/**/*.[ch]"
+comment-style = { meta = "*=", content = "*#" }
+
+# The Transport Layer Security (TLS) Protocol Version 1.2
+[[specification]]
+source = "https://www.rfc-editor.org/rfc/rfc5246"
+
+# HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
+[[specification]]
+source = "https://www.rfc-editor.org/rfc/rfc5869"
+
+# The Transport Layer Security (TLS) Protocol Version 1.3
+[[specification]]
+source = "https://www.rfc-editor.org/rfc/rfc8446"
+
+# Example Handshake Traces for TLS 1.3
+[[specification]]
+source = "https://www.rfc-editor.org/rfc/rfc8448"
+
+# Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension
+[[specification]]
+source = "https://www.rfc-editor.org/rfc/rfc7627"
+
+# Transport Layer Security (TLS) Renegotiation Indication Extension
+[[specification]]
+source = "https://www.rfc-editor.org/rfc/rfc5746"
+
+# Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
+[[specification]]
+source = "https://www.rfc-editor.org/rfc/rfc4492"
+
+# # Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
+[[specification]]
+source = "https://www.rfc-editor.org/rfc/rfc8422"
+
+[report.html]
+enabled = true
+issue-link = "https://github.com/aws/s2n-tls/issues"
+blob-link = "https://github.com/aws/s2n-tls/blob/${{ BLOB || GITHUB_SHA || 'main' }}"
+
+# Enable snapshots to prevent requirement coverage regressions
+[report.snapshot]
+enabled = true

compliance/specs/exceptions/rfc5746/3.6.toml .duvet/exceptions/rfc5746/3.6.toml

@@ -0,0 +1,36 @@
+target = "https://www.rfc-editor.org/rfc/rfc4492#section-2.1"
+
+# ECDH_ECDSA
+#
+#    In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable
+#    public key and be signed with ECDSA.
+# 
+#    A ServerKeyExchange MUST NOT be sent (the server's certificate
+#    contains all the necessary keying information required by the client
+#    to arrive at the premaster secret).
+# 
+#    The client generates an ECDH key pair on the same curve as the
+#    server's long-term public key and sends its public key in the
+#    ClientKeyExchange message (except when using client authentication
+#    algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the
+#    modifications from Section 3.2 or Section 3.3 apply).
+# 
+#    Both client and server perform an ECDH operation and use the
+#    resultant shared secret as the premaster secret.  All ECDH
+#    calculations are performed as specified in Section 5.10.
+
+[[spec]]
+level = "MUST"
+quote = '''
+In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable
+public key and be signed with ECDSA.
+'''
+
+[[spec]]
+level = "MUST"
+quote = '''
+A ServerKeyExchange MUST NOT be sent (the server's certificate
+contains all the necessary keying information required by the client
+to arrive at the premaster secret).
+'''
+

compliance/specs/exceptions/rfc5746/4.2.toml .duvet/exceptions/rfc5746/4.2.toml

@@ -0,0 +1,34 @@
+target = "https://www.rfc-editor.org/rfc/rfc4492#section-2.2"
+
+# ECDHE_ECDSA
+#
+#    In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
+#    capable public key and be signed with ECDSA.
+# 
+#    The server sends its ephemeral ECDH public key and a specification of
+#    the corresponding curve in the ServerKeyExchange message.  These
+#    parameters MUST be signed with ECDSA using the private key
+#    corresponding to the public key in the server's Certificate.
+# 
+#    The client generates an ECDH key pair on the same curve as the
+#    server's ephemeral ECDH key and sends its public key in the
+#    ClientKeyExchange message.
+# 
+#    Both client and server perform an ECDH operation (Section 5.10) and
+#    use the resultant shared secret as the premaster secret.
+
+[[spec]]
+level = "MUST"
+quote = '''
+In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
+capable public key and be signed with ECDSA.
+'''
+
+[[spec]]
+level = "MUST"
+quote = '''
+These
+parameters MUST be signed with ECDSA using the private key
+corresponding to the public key in the server's Certificate.
+'''
+

compliance/specs/exceptions/rfc5746/4.4.toml .duvet/exceptions/rfc5746/4.4.toml

@@ -1,9 +1,9 @@
 target = "https://www.rfc-editor.org/rfc/rfc4492#section-2.3"
 
-# 2.3.  ECDH_RSA
+# ECDH_RSA
 #
-# This key exchange algorithm is the same as ECDH_ECDSA except that the
-# server's certificate MUST be signed with RSA rather than ECDSA.
+#    This key exchange algorithm is the same as ECDH_ECDSA except that the
+#    server's certificate MUST be signed with RSA rather than ECDSA.
 
 [[spec]]
 level = "MUST"

compliance/specs/exceptions/rfc5746/5.toml .duvet/exceptions/rfc5746/5.toml

@@ -1,12 +1,12 @@
 target = "https://www.rfc-editor.org/rfc/rfc4492#section-2.4"
 
-# 2.4.  ECDHE_RSA
+# ECDHE_RSA
 #
-# This key exchange algorithm is the same as ECDHE_ECDSA except that
-# the server's certificate MUST contain an RSA public key authorized
-# for signing, and that the signature in the ServerKeyExchange message
-# must be computed with the corresponding RSA private key.  The server
-# certificate MUST be signed with RSA.
+#    This key exchange algorithm is the same as ECDHE_ECDSA except that
+#    the server's certificate MUST contain an RSA public key authorized
+#    for signing, and that the signature in the ServerKeyExchange message
+#    must be computed with the corresponding RSA private key.  The server
+#    certificate MUST be signed with RSA.
 
 [[spec]]
 level = "MUST"

.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.1.toml

@@ -0,0 +1,56 @@
+target = "https://www.rfc-editor.org/rfc/rfc4492#section-2.5"
+
+# ECDH_anon
+#
+#    In ECDH_anon, the server's Certificate, the CertificateRequest, the
+#    client's Certificate, and the CertificateVerify messages MUST NOT be
+#    sent.
+# 
+#    The server MUST send an ephemeral ECDH public key and a specification
+#    of the corresponding curve in the ServerKeyExchange message.  These
+#    parameters MUST NOT be signed.
+# 
+#    The client generates an ECDH key pair on the same curve as the
+#    server's ephemeral ECDH key and sends its public key in the
+#    ClientKeyExchange message.
+# 
+#    Both client and server perform an ECDH operation and use the
+#    resultant shared secret as the premaster secret.  All ECDH
+#    calculations are performed as specified in Section 5.10.
+# 
+#    Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA
+#    key exchange algorithms require the server's certificate to be signed
+#    with a particular signature scheme, this specification (following the
+#    similar cases of DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2] and [3])
+#    does not impose restrictions on signature schemes used elsewhere in
+#    the certificate chain.  (Often such restrictions will be useful, and
+#    it is expected that this will be taken into account in certification
+#    authorities' signing practices.  However, such restrictions are not
+#    strictly required in general: Even if it is beyond the capabilities
+#    of a client to completely validate a given chain, the client may be
+#    able to validate the server's certificate by relying on a trusted
+#    certification authority whose certificate appears as one of the
+#    intermediate certificates in the chain.)
+
+[[spec]]
+level = "MUST"
+quote = '''
+In ECDH_anon, the server's Certificate, the CertificateRequest, the
+client's Certificate, and the CertificateVerify messages MUST NOT be
+sent.
+'''
+
+[[spec]]
+level = "MUST"
+quote = '''
+The server MUST send an ephemeral ECDH public key and a specification
+of the corresponding curve in the ServerKeyExchange message.
+'''
+
+[[spec]]
+level = "MUST"
+quote = '''
+These
+parameters MUST NOT be signed.
+'''
+

.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.2.toml

@@ -0,0 +1,106 @@
+target = "https://www.rfc-editor.org/rfc/rfc4492#section-2"
+
+# Key Exchange Algorithms
+#
+#    This document introduces five new ECC-based key exchange algorithms
+#    for TLS.  All of them use ECDH to compute the TLS premaster secret,
+#    and they differ only in the lifetime of ECDH keys (long-term or
+#    ephemeral) and the mechanism (if any) used to authenticate them.  The
+#    derivation of the TLS master secret from the premaster secret and the
+#    subsequent generation of bulk encryption/MAC keys and initialization
+#    vectors is independent of the key exchange algorithm and not impacted
+#    by the introduction of ECC.
+# 
+#    The table below summarizes the new key exchange algorithms, which
+#    mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2] and
+#    [3]), respectively.
+# 
+#           Key
+#           Exchange
+#           Algorithm           Description
+#           ---------           -----------
+# 
+#           ECDH_ECDSA          Fixed ECDH with ECDSA-signed certificates.
+# 
+#           ECDHE_ECDSA         Ephemeral ECDH with ECDSA signatures.
+# 
+#           ECDH_RSA            Fixed ECDH with RSA-signed certificates.
+# 
+#           ECDHE_RSA           Ephemeral ECDH with RSA signatures.
+# 
+#           ECDH_anon           Anonymous ECDH, no signatures.
+# 
+#                      Table 2: ECC Key Exchange Algorithms
+# 
+#    The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward
+#    secrecy.  With ECDHE_RSA, a server can reuse its existing RSA
+#    certificate and easily comply with a constrained client's elliptic
+#    curve preferences (see Section 4).  However, the computational cost
+# 
+#    incurred by a server is higher for ECDHE_RSA than for the traditional
+#    RSA key exchange, which does not provide forward secrecy.
+# 
+#    The ECDH_RSA mechanism requires a server to acquire an ECC
+#    certificate, but the certificate issuer can still use an existing RSA
+#    key for signing.  This eliminates the need to update the keys of
+#    trusted certification authorities accepted by TLS clients.  The
+#    ECDH_ECDSA mechanism requires ECC keys for the server as well as the
+#    certification authority and is best suited for constrained devices
+#    unable to support RSA.
+# 
+#    The anonymous key exchange algorithm does not provide authentication
+#    of the server or the client.  Like other anonymous TLS key exchanges,
+#    it is subject to man-in-the-middle attacks.  Implementations of this
+#    algorithm SHOULD provide authentication by other means.
+# 
+#    Note that there is no structural difference between ECDH and ECDSA
+#    keys.  A certificate issuer may use X.509 v3 keyUsage and
+#    extendedKeyUsage extensions to restrict the use of an ECC public key
+#    to certain computations [15].  This document refers to an ECC key as
+#    ECDH-capable if its use in ECDH is permitted.  ECDSA-capable is
+#    defined similarly.
+# 
+#               Client                                        Server
+#               ------                                        ------
+# 
+#               ClientHello          -------->
+#                                                        ServerHello
+#                                                       Certificate*
+#                                                 ServerKeyExchange*
+#                                               CertificateRequest*+
+#                                    <--------       ServerHelloDone
+#               Certificate*+
+#               ClientKeyExchange
+#               CertificateVerify*+
+#               [ChangeCipherSpec]
+#               Finished             -------->
+#                                                 [ChangeCipherSpec]
+#                                    <--------              Finished
+# 
+#               Application Data     <------->      Application Data
+# 
+#                    * message is not sent under some conditions
+#                    + message is not sent unless client authentication
+#                      is desired
+# 
+#                  Figure 1: Message flow in a full TLS handshake
+# 
+#    Figure 1 shows all messages involved in the TLS key establishment
+#    protocol (aka full handshake).  The addition of ECC has direct impact
+#    only on the ClientHello, the ServerHello, the server's Certificate
+#    message, the ServerKeyExchange, the ClientKeyExchange, the
+#    CertificateRequest, the client's Certificate message, and the
+#    CertificateVerify.  Next, we describe each ECC key exchange algorithm
+#    in greater detail in terms of the content and processing of these
+#    messages.  For ease of exposition, we defer discussion of client
+#    authentication and associated messages (identified with a + in
+#    Figure 1) until Section 3 and of the optional ECC-specific extensions
+#    (which impact the Hello messages) until Section 4.
+
+[[spec]]
+level = "SHOULD"
+quote = '''
+Implementations of this
+algorithm SHOULD provide authentication by other means.
+'''
+

compliance/specs/www.rfc-editor.org/rfc/rfc4492/section-2.3.toml .duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.3.toml

@@ -0,0 +1,20 @@
+target = "https://www.rfc-editor.org/rfc/rfc4492#section-3.1"
+
+# ECDSA_sign
+#
+#    To use this authentication mechanism, the client MUST possess a
+#    certificate containing an ECDSA-capable public key and signed with
+#    ECDSA.
+# 
+#    The client proves possession of the private key corresponding to the
+#    certified key by including a signature in the CertificateVerify
+#    message as described in Section 5.8.
+
+[[spec]]
+level = "MUST"
+quote = '''
+To use this authentication mechanism, the client MUST possess a
+certificate containing an ECDSA-capable public key and signed with
+ECDSA.
+'''
+