rfc-6594

Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records

O. Sury

date2012-04 streamIETF wgnon working group statusPROPOSED STANDARD pages9 canonicalhttps://www.rfc-editor.org/rfc/rfc6594 doi10.17487/RFC6594 errataview

This document updates the IANA registries in RFC 4255, which defines SSHFP, a DNS Resource Record (RR) that contains a standard Secure Shell (SSH) key fingerprint used to verify SSH host keys using DNS Security Extensions (DNSSEC). This document defines additional options supporting SSH public keys applying the Elliptic Curve Digital Signature Algorithm (ECDSA) and the implementation of fingerprints computed using the SHA-256 message digest algorithm in SSHFP Resource Records. [STANDARDS-TRACK]

Extracted elements (13)

design-rationale §7

SHA-256 was chosen over SHA-1 for SSHFP fingerprints because SHA-1 attacks (such as Wang et al.'s 2^63 SHA-1 differential path) erode confidence in SHA-1, making SHA-256 the better choice regardless of whether those specific attacks affect SSHFP.

dns, crypto, security

interoperability-note §1

This document updates RFC 4255 by extending the IANA registries to include ECDSA (algorithm 3) and SHA-256 (fingerprint type 2). Implementations must remain compatible with the existing RSA (1), DSA (2), and SHA-1 (1) values defined in RFC 4255.

dns, crypto, security

normative-requirement §4.1 MUST

If the SHA-256 fingerprint is tested and does not match the SSH public key received from the SSH server, then the key MUST be rejected rather than testing the alternative SHA-1 fingerprint.

dns, crypto, security

normative-requirement §4.1 MUST

Secure Shell implementations that support SHA-256 fingerprints MUST prefer a SHA-256 fingerprint over SHA-1 if both are available for a server.

dns, crypto, security

normative-requirement §4.1 SHOULD

SSHFP-aware Secure Shell implementations SHOULD support SHA-256 fingerprints for verification of the public key.

dns, crypto, security

normative-requirement §4.2 SHOULD

SSHFP-aware Secure Shell implementations that also implement ECDSA for the public key SHOULD support SSHFP fingerprints for ECDSA public keys.

dns, crypto, security

protocol-element §3.2.1

ECDSA public keys are stored in SSHFP Resource Records with algorithm number 3. The algorithm number octet describes the algorithm of the public key.

dns, crypto, security

protocol-element §3.1.1

SHA-256 fingerprints of SSH public keys are stored in SSHFP Resource Records with fingerprint type 2. The fingerprint type octet identifies the message digest algorithm used to calculate the fingerprint.

dns, crypto, security

registry §6.2

The IANA registry 'SSHFP RR types for fingerprint types' is updated to add SHA-256 with value 2.

dns, registry, crypto

registry §6.1

The IANA registry 'SSHFP RR Types for public key algorithms' is updated to add ECDSA with value 3.

dns, registry, crypto

security-consideration §7

SHA-256 is considered sufficiently strong for the immediate future. References to RFC 4255 and RFC 5656 are provided for security considerations covering SSHFP Resource Records and ECDSA respectively.

dns, crypto, security

security-consideration §7

Users of SSHFP are encouraged to deploy SHA-256 as soon as implementations allow. The SHA-2 family is widely believed to be more resilient to attack than SHA-1, and confidence in SHA-1's strength is being eroded by announced attacks.

dns, crypto, security

wire-format §3

An SSHFP RR encodes a public key fingerprint using two index octets — one for the public key algorithm (e.g., 1=RSA, 2=DSA, 3=ECDSA) and one for the fingerprint type (1=SHA-1, 2=SHA-256) — followed by the fingerprint value. Example: 'server.example.net IN SSHFP 3 2 ( 821eb6c1... )'.

dns, crypto