Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad

[Tom Ritter <[e-mail]>]

On 4 May 2017 at 17:21, Brian Smith <[e-mail]> wrote:
> 3. As RFC 6979 notes, RFC 6979 invalidates the proof of security for
> ECDSA. This is a step backward from recent progress towards provable
> security of internet protocols.

I just want to make sure I understand this point. Skimming the draft I
gather this is because the proof of ECDSA relies on k being
indistinguishable from the output of a Random Oracle? Deterministic
generation of k uses HMAC_DRBG which sure looks like the ROM, but
isn't (?) provably so?

Assuming I understand - when you implement ECDSA you don't get to use
a RO, you use a CSPRNG which also doesn't count as a RO so that
probably invalidates the proof. So one assumes the CSPRNG behaves like
the ROM, so why don't you just assume HMAC-DRBG behaves like the ROM
and your proof is repaired!

On 5 May 2017 at 04:02, Eran Messeri <[e-mail]> wrote:
> I'd like to hear the opinion of people who've worked on the Gossip protocol
> - as Brian said, the purpose behind deterministic signatures is to make it
> difficult to fingerprint individual clients. However, the only gossip that's
> taking place right now is STH exchange between monitors, where this is not a
> concern,

All of Brian's points are strong points.

My concern with fingerprinting still stands though. While not Gossip -
Google plans to resolve inclusion proofs for SCTs via DNS. The end DNS
server for this is their own log mirror - but I believe this is for
scaling, not privacy.

If a log and server colluded to issue and serve different SCT
signatures for the same SCT, there are no great options to detect it:

- very complicated logic in the client
- auditors performing aggressive fake-client spidering from multiple
network vantage points combined with significant refactoring and data
storage requirements
- the SCT Feedback part of the Gossip draft combined with the auditor changes

As far as the concern of this attack goes: without long-term storage
of the SCT (such as that in SCT Feedback) - the impact is minimal when
it comes to log+webserver-collaboration-for-tracking.

But the log is still able to send different SCTs out and can do this
without the server participating. With the distribution part outside
the log's control it's not as effective, and more turns into a game of
"I wonder what happens...". (I think.)


Anyway, so I still think there's fingerprinting concerns. But even if
we require deterministic signatures - if the log *wants* to be
malicious, it can still issue non-deterministic signatures, and
there's no way to know, because as I said above - detection is hard.
So I think Eran's suggested changes are okay.

-tom