Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nselib: Fix EdDSA in default TLS 1.2 signature_algorithms #2766

Closed
wants to merge 1 commit into from

Conversation

droe
Copy link

@droe droe commented Jan 3, 2024

I seem to have lost my commit bit on the Subversion repo (which is fine, kudos for the user lifecycle management), so here's a fix I'd like to see in Nmap:

Fix the default signature_algorithms extension used for TLS 1.2 to include code points 0x0807 (intrinsic, ed25519) and 0x0808 (intrinsic, ed448) instead of the invalid 0x0407, 0x0408, 0x0607 and 0x0608, combining sha256/sha512 with EdDSA.

Quoting RFC 8422:

5.1.3. The signature_algorithms Extension and EdDSA

The signature_algorithms extension, defined in Section 7.4.1.4.1 of
[RFC5246], advertises the combinations of signature algorithm and
hash function that the client supports. The pure (non-prehashed)
forms of EdDSA do not hash the data before signing it. For this
reason, it does not make sense to combine them with a hash function
in the extension.

For bits-on-the-wire compatibility with TLS 1.3, we define a new
dummy value in the "TLS HashAlgorithm" registry that we call
"Intrinsic" (value 8), meaning that hashing is intrinsic to the
signature algorithm.
To represent ed25519 and ed448 in the signature_algorithms extension,
the value shall be (8,7) and (8,8), respectively.

Fix the default signature_algorithms extension used for TLS 1.2 to
include code points 0x0807 (intrinsic, ed25519) and 0x0808 (intrinsic,
ed448) instead of the invalid 0x0407, 0x0408, 0x0607 and 0x0608,
combining sha256/sha512 with EdDSA.

Quoting RFC 8422:

5.1.3.  The signature_algorithms Extension and EdDSA

   The signature_algorithms extension, defined in Section 7.4.1.4.1 of
   [RFC5246], advertises the combinations of signature algorithm and
   hash function that the client supports.  The pure (non-prehashed)
   forms of EdDSA do not hash the data before signing it.  For this
   reason, it does not make sense to combine them with a hash function
   in the extension.

   For bits-on-the-wire compatibility with TLS 1.3, we define a new
   dummy value in the "TLS HashAlgorithm" registry that we call
   "Intrinsic" (value 8), meaning that hashing is intrinsic to the
   signature algorithm.
   To represent ed25519 and ed448 in the signature_algorithms extension,
   the value shall be (8,7) and (8,8), respectively.
@nmap-bot nmap-bot closed this in 034ea73 Jan 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant