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

[Gary Belvin <[e-mail]>]

> return a different stream of bytes for the same ingoing parameters, for SCTs
and STHs.
In addition to fixing signature randomization, wouldn't one also need to
fix the inputs to the signature? Timestamps in particular and any server
supplied data that wasn't directly tied to the leaves themselves would seem
to be a problem.

-G


On Mon, May 22, 2017 at 10:21 AM Linus Nordberg <[e-mail]> wrote:

> Hi,
>
> It should be clear by now that I'd be sad if 6962bis would allow logs to
> return a different stream of bytes for the same ingoing parameters, for
> SCTs and STHs, but more interesting would be to hear other wg members
> views on the balance we're trying to strike.
>
> Regarding current deployment, are there any 6269bis logs deployed yet?
>
> Regarding correctness vs. completeness, what in -24 is incorrect with
> this regard?
>
> Regarding added cost of implementation, using RSA is an option.
>
> Regarding gossip unclearity, the suggested change risks making it harder
> to get STH gossip going.
>
>
> Eran Messeri <[e-mail]> wrote
> Mon, 22 May 2017 13:23:12 +0100:
>
> > FYI I'm proposing changes per this discussion in
> > https://github.com/google/certificate-transparency-rfcs/pull/261.
> Comments
> > welcome.
> >
> > Eran
> >
> > On Mon, May 15, 2017 at 12:35 PM, Eran Messeri <[e-mail]> wrote:
> >
> >>
> >>
> >> On Mon, May 15, 2017 at 11:50 AM, Linus Nordberg <[e-mail]>
> wrote:
> >>
> >>> Eran Messeri <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/trans
>
> _______________________________________________
> Trans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans
>