On Mon, May 15, 2017 at 11:50 AM, Linus Nordberg <[email protected]> wrote:
> 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. > > I completely agree - it would be more difficult for clients caring about privacy (which should be all TLS clients used by end-users these days, really) to exchange STHs they've obtained themselves, if logs were allowed to use unique signatures. I'm not saying the reasoning is wrong - it is very solid as far as I can tell - but that we don't know if we need it yet, see below. > > * 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? > Seems to me like the same reasoning applies to both - sorry, wasn't clear about it. > > > > 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? > I'd leave that, as it has several benefits beyond gossip (for example, the ability to cache STHs and their consistency proofs or coordinating selection of an SCT). > > > > 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. > Overall I agree with the sentiment. However I'm trying to balance the attempt to make SCTs & STHs non-identifying as much as possible with ease of implementation and the current deployment: - As Melinda said on a separate post, 6962-bis has to be correct but it doesn't have to be complete. We could add the stricter requirement of producing consistent signatures for the same data later on. - There's an added cost for implementations: Either more storage (storing produced signatures) or reliance on features that are not widely supported in crypto libraries (deterministic signatures). - Right now, how the gossip is going to take place is unclear: The only thing currently operating (AFAIK) is STH exchange between several monitors. I don't know of any TLS client implementation that intends to fetch STHs directly (we've actually removed this capability <https://chromium.googlesource.com/chromium/src/+/dba25668458c87c4b38c63db710c49c47d0db087> from Chrome recently). Even if there was such an implementation, because it's not clear who it will be exchanging STHs with, it's unclear what's the threat model - who has to collude to compromise a client's privacy by tracking it. To put it simply, I don't know yet if we'll need it - which is why I suggest we strongly recommend deterministic signatures, but not mandate it. What do you think?
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
