Remove deterministic signatures requirement #261
Conversation
Per discussion on trans, making deterministic signing optional, mentioning that deterministic signing can be achieved by storing the signature blobs rather than re-signing the same SCTs for the same submissions.
eranmes
requested review from
robstradling and
benlaurie
and removed request for
benlaurie
I think we should also change the title of this section from "Deterministic Signatures" to something like "Tracking Clients" (or "Preventing Tracking Clients").
draft-ietf-trans-rfc6962-bis.md
Outdated
| @@ -1892,7 +1892,7 @@ IANA is asked to establish a registry of signature algorithm values, named | |||
| |-------------+--------------------------------------------------------+------------------------------------------| | |||
| | Value | Signature Algorithm | Reference / Assignment Policy | | |||
| |-------------+--------------------------------------------------------+------------------------------------------| | |||
| | 0x00 | Deterministic ECDSA (NIST P-256) with HMAC-SHA256 | [RFC6979] | | |||
| | 0x00 | ECDSA (NIST P-256) with HMAC-SHA256 | [RFC6979] | | |||
There was a problem hiding this comment.
If we're dropping the requirement for deterministic ECDSA, then I don't see how we can keep "[RFC6979]" as the (only) Assignment Policy. I can't find an RFC for "non-deterministic" ECDSA, so I think we should reference FIPS 186-4.
I think we should still mention RFC6979 as an option. AFAICT, the "with HMAC-SHA256" part doesn't apply to "non-deterministic" ECDSA, so I think we should have two lines, both with the value 0x00:
ECDSA (NIST P-256) | [FIPS 186-4]
Deterministic ECDSA (NIST P-256) with HMAC-SHA256 | [RFC6979)
There was a problem hiding this comment.
Oh, we also need to specify the signature hash algorithm:
ECDSA (NIST P-256) with SHA-256
I'm not intimately familiar with RFC6979. Is "with HMAC-SHA256" sufficient? Or do we need to write "with HMAC-SHA256 and SHA-256"?
There was a problem hiding this comment.
Done.
HMAC-SHA256 seems enough, by looking at the Building Blocks section of RFC6979 (3.2).
draft-ietf-trans-rfc6962-bis.md
Outdated
| Logs are encouraged to use deterministic signatures to reduce the risk of | ||
| tracking clients: clients that gossip STHs or report back SCTs can be tracked | ||
| or traced if a log was to produce multiple STHs or SCTs with the same timestamp | ||
| and data but different signatures. |
There was a problem hiding this comment.
My wordsmithing attempt on this paragraph:
Clients that gossip STHs or report back SCTs can be tracked or traced if a log produces multiple STHs or SCTs with the same timestamp and data but different signatures. To mitigate this risk, logs are encouraged to use deterministic signature schemes.
draft-ietf-trans-rfc6962-bis.md
Outdated
| Note that deterministic signatures can be provided without the use of a | ||
| signature scheme that's designed for deterministic signing: The signature bytes | ||
| for each SCT or STH could be stored and served when the same certificate is | ||
| submitted or the same STH requested, rather than re-signing the same data. |
There was a problem hiding this comment.
I think it's misleading/confusing to use the phrase "deterministic signatures can be provided" here. Here's an attempt at wordsmithing both this and the preceding paragraph:
`Clients that gossip STHs or report back SCTs can be tracked or traced if a log produces multiple STHs or SCTs with the same timestamp and data but different signatures. Logs MUST mitigate this risk by either:
- Using deterministic signature schemes, or
- Producing no more than one SCT for each distinct submission and no more than one STH for each distinct tree_size. Each of these SCTs and STHs can be stored by the log and served to other clients that submit the same certificate or request the same STH.`
There was a problem hiding this comment.
Done - with one modification, changing MUST to a SHOULD because I really don't want to require it yet, we don't really know how gossip will take place and if it'll indeed introduce a new tracking/fingerprinting vector.
|
@robstradling PTAL. |
Per discussion on trans, making deterministic signing optional,
mentioning that deterministic signing can be achieved by storing
the signature blobs rather than re-signing the same SCTs for
the same submissions.