Eran Messeri <[email protected]> wrote
Fri, 12 May 2017 14:36:04 +0100:
> Thanks for the feedback. It helped me realize deterministic signatures
> could be achieved not only by using a deterministic signature scheme, but
> also by logs storing the produced signatures and returning them instead of
> re-signing SCTs, for example.
>
> That's my understanding of the discussion so far:
> * Requiring the use of RFC6979 is bad, for the reasons Brian has mentioned.
> * It is not yet clear where deterministic signatures may be more important
> (SCTs or STHs) because it's not clear what TLS clients will gossip and how.
Not to argue against that statement but I think that it's clear that
gossiping about STHs would become more problematic for a client caring
about privacy if logs were allowed to send different strings of bits to
different clients for a given pair of `log_id` and `tree_head` in an
STH.
> * It is not necessary to require the use of a deterministic signature
> scheme - only that the same signature is present in all instances of a
> particular SCT (note that different SCTs for the same submission, with
> different timestamps, which the log may issue, cannot have the same
> signature).
This sounds like a requirement, i.e. a MUST, which is not reflected in
the reasoning below ("MUST->SHOULD" and "Mention that").
Also, this talks about SCTs specifically. What do you think the story is
for STHs?
> Also, in 6962-bis, my focus is on correct operation of the log & Merkle
> Tree - and deterministic signatures are not strictly necessary for that.
While I think it's fair to try to limit the scope I think it would be
bad to make it hard to gossip since that's supposed to protect against
attacks on the ability to audit the correctness of said
operation. Admittedly, one problem here is that "hard to gossip" is far
from well defined.
Also, does this imply that the limitation on STH issuance frequency
should be removed too?
> To make progress on this issue, I propose the following:
> * Remove references to 6979.
> * Remove the strong requirement to use deterministic signature schemes
> (MUST -> SHOULD), so implementations can use non-deterministic signature
> schemes and still be compliant with the spec.
> * Add reference to EdDSA, which includes a deterministic signature scheme
> variant.
> * Mention that deterministic signatures can be achieved by storing the
> produced signatures.
>
> Any objections?
I think that 6962bis should mandate that the same bits are sent over the
wire to every client asking for a given piece of signed data. (This can
be accomplished by either using a deterministic signing scheme or by
storing the data under a unique key for later use.)
The main reason for this requirement is to make it possible for log
clients to gossip about STHs -- limiting the number of outstanding STHs
that a log can have at any given time is important in order to limit the
ability for a log to fingerprint its clients, as described in
draft-ietf-trans-gossip-04 section 10.5.4. This is done by limiting the
log STH issuance frequency (6962bis-24 section 4.8) _and_ requiring that
the same bits are sent over the wire to everyone asking for a given STH.
The privacy argument for imposing this same-bits-for-same-data rule for
SCTs too seems weaker since SCTs carry much more privacy sensitive data
but I'm not convinced that this holds for all gossip
scenarios. Fingerprinting of a gossip peer doesn't necessarily relate to
linking an SCT to a user of an HTTPS client. I think this is reason
enough to not separate STHs and SCTs with regard to this requirement.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
