Security considerations

What a valid stamp establishes#

A valid stamp is a statement by the holder of a domain about a set of facts. It establishes three things, and no more.

The time of issue is part of the signed data, but it is chosen by whoever holds the key. It is reliable to the extent that the key has not been stolen.

Trust model#

DKDS has no certificate authority and no registry. A verifier trusts the following:

• The holder of the domain, to publish only keys it controls. The identity shown to the reader is a domain name, not a legal entity.
• The DNS, to deliver the key record unaltered. With DNSSEC, this trust rests on the signed chain from the DNS root to the issuer's zone. Without DNSSEC, it rests on the resolvers and the network path to them.
• The verifier software and the device on which it runs.

The reader is trusted to recognise the domain and to compare the fields with the document. Several of the measures below exist to make these two tasks easier and harder to subvert.

Threats and mitigations#

Altered documents#

The purpose of a stamp is to reveal alterations made after issue. A verifier shows the fields as signed; the reader compares them with the document. A difference between the two shows that the document, or the stamp, has been changed. An alteration to a part of the document that the stamp does not cover is not detected, which is why issuers include every fact on which the recipient relies.

Lookalike domains#

The protocol proves which domain signed a stamp, not that the reader recognises it. A forger can register a domain such as northwind-invoices.example or one that uses characters from another script, publish a key under it, and sign stamps that verify as valid. Verifiers therefore display the domain prominently, show internationalised domains in their Unicode form, and warn about mixed scripts, confusable characters and domains similar to those the reader has verified before (Building a verifier). Issuers can reduce the risk by using the domain under which they are already known to their recipients.

Stolen private keys#

A holder of a stolen key can sign stamps with any time of issue. Revocation therefore invalidates all stamps of the key, including those signed before the theft, because the two cannot be distinguished. Short-lived keys, separate keys per issuing system and keys held in hardware security modules limit both the likelihood and the effect of a theft (Issuing documents).

Forged DNS answers#

An attacker who can alter DNS answers on the path to a verifier can substitute a key. Where the issuer's zone is signed with DNSSEC, a validating resolver rejects the forged answer and the outcome is unavailable. Verifiers report whether an answer was validated, and compare the answers of two independent resolvers, which makes an attack on a single resolver detectable.

Lapsed and transferred domains#

Whoever holds a domain can publish keys under it and sign stamps with any time of issue. When a domain lapses or is transferred, the new holder can therefore create stamps that verify as valid. A valid stamp means that the current holder of the domain vouches for it.

Copied stamps#

A stamp can be copied from one document onto another. The copy verifies as valid, but its fields describe the original document. The reader detects this by comparing the fields with the document. Issuer requirement 10.4, which asks for fields that identify the subject and the document, makes the comparison meaningful.

Untrue content#

A stamp shows who made a statement, not whether it is correct. An issuer can sign false facts, and the stamp is valid. DKDS makes such a statement attributable to the domain that signed it.

Repudiation#

An issuer might publish a weak key, under which any signature verifies, in order to deny later that it signed a stamp. The specification rejects keys of small order, including the identity point (section 6.3), so that a valid stamp can be attributed to the holder of the domain. Verifiers built on Ed25519 libraries that omit these checks lose this property.

Hostile input#

A stamp is untrusted input from a camera. Every length in the envelope is bounded, decompression stops at 16,384 bytes, no DNS query is made for a malformed stamp, and the payload is decompressed and parsed only after the signature has been verified. The test vectors include each limit, a decompression bomb and invalid UTF-8.

Display spoofing#

Text can be made to display differently from its content, for example with bidirectional overrides or invisible characters. Such code points are forbidden in field names and values (Appendix B). The separation of the verifier's statements from the issuer's fields (section 9.1) prevents a field from imitating the verifier.

Denial of verification#

If the issuer's DNS is unreachable, verification ends with unavailable, which is distinct from a failed verification and indicates that the stamp may be checked again later. An attacker who blocks DNS traffic can prevent verification but cannot make a stamp appear valid.

Privacy#

A stamp has no confidentiality: anyone who scans it can read every field. Issuers place in a stamp only facts that are printed on the document anyway.

Verification itself discloses information. The DNS query for <key_id>._dkds.<domain> reveals to the resolvers, and to the operator of the issuer's DNS, that a stamp of that issuer is being verified, together with the network address of the verifier or its resolver. The fields of the stamp are not disclosed by the query. Verifiers that remember keys and domains hold a record of the issuers a reader has checked, which is kept on the reader's device.

Cryptographic agility#

A sufficiently large quantum computer could forge Ed25519 signatures. The key record names the algorithm, so a post-quantum algorithm can be introduced as a new k value without changing the envelope (section 11). Within the limit of 1,088 bytes per envelope, only algorithms with small signatures are suitable.

Responsibilities#