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

[Linus Nordberg <[e-mail]>]

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