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

From: Brian Smith <[email-masked]>
Date: Thu, 4 May 2017 12:21:14 -1000

Hi,

Recently I implemented RFC 6979 and also I'm implementing some CT things.

Draft 24 of rfc6962-bis says that the log must use RFC 6979 for ECDSA
signatures. However, the requirement to use RFC 6979 is problematic
for several reasons, noted below. I think this group should reconsider
if the fingerprinting threat that motivated the requirement for
deterministic signatures is significant enough to overcome these
problems.

If the requirement for deterministic signatures were removed, all the
problems below would be resolved. (Additionally the more secure
RSA-PSS could be mandated instead of the obsolete and less safe PKCS#1
1.5.)

If it is still seen as very important to require signatures be
deterministic, the requirement to to use specifically RFC 6979 should
be be removed, and replaced with a more general requirement to use
*some* secure deterministic nonce for ECDSA signatures, without
mandating RFC 6979 specifically.

Here are the problems I see with mandating the use of RFC 6979:

1. RFC 6979 deterministic signatures are not and cannot be compliant
with FIPS and other regulations. This means, in particular, that a log
cannot use the same CABForum-compliant (HSM) ECDSA implementation that
it could use to sign certificates.

2. RFC 6979 is a very inefficient way of generating deterministic
signatures. Every RFC 6979 signature requires invoking the SHA-256
compression function 19 to 22 times. The BitCoin core developers
reported that this takes 10% of total signature generation time. [0]

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.

4. Because of #1, #2, and #3, most crypto libraries and HSM
implementations would be better off using a different deterministic
signature scheme (such as a variant of the much more efficient one
used for Ed25519). And/or they may use a different, non-deterministic,
solution to the concerns that originally motivated the creation of RFC
6979 in the first place, such as the one that Google's BoringSSL [1]
and Cisco [2] have implemented. If one is going to use a better
scheme, then maintaining RFC 6979 support too just for this one
protocol is a large burden.

5. There is no way to check that the log actually used RFC 6979, or
any other specific secure deterministic scheme, because part of
calculating the nonce involves hashing the private key. Thus the
requirement to use RFC 6979 is unenforceable technically or even by
policy.

[0] https://crypto.stackexchange.com/a/42551 (I can't find the
original citation for what the Bitcoin people said.)
[1] https://boringssl.googlesource.com/boringssl/+/783e0957875ac62b35aa4f8741069e133695a3d4
[2] https://blogs.cisco.com/security/fips-and-deterministic-ecdsa-achieving-robust-security-and-conformance

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Eran Messeri <[email-masked]>
Date: Fri, 5 May 2017 10:02:23 +0100

I share the concern, due to the difficulty I've had finding implementations
of this RFC (or any deterministic signature scheme for ECDSA in general).

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,

My proposal for 6962-bis is then to:
* State 6962-bis logs SHOULD use a deterministic signature scheme (making
it optional, but strongly suggested).
* Remove normative references to RFC6979.

Eran

On Thu, May 4, 2017 at 11:21 PM, Brian Smith <[email-masked]> wrote:

> [2] https://blogs.cisco.com/security/fips-and-
> deterministic-ecdsa-achieving-robust-security-and-conformance
>
> Cheers,
> Brian
> --
> https://briansmith.org/
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Brian Smith <[email-masked]>
Date: Fri, 5 May 2017 09:39:37 -1000

> original citation for what the Bitcoin people said.)

I found it:
https://bitcoin.stackexchange.com/questions/36127/problems-with-deterministic-ecdsa-based-on-rfc6979-in-bitcoin#comment42214_36142

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Rob Stradling <[email-masked]>
Date: Fri, 5 May 2017 22:16:08 +0100

On 04/05/17 23:21, Brian Smith wrote:
<snip>
> used for Ed25519).

Given that RFC8032 has been published and we're still working 6962-bis...

Would it be a good idea to add Ed25519 to the initial list of permitted 
signature algorithms that logs can use?

https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-24#section-10.4

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Tom Ritter <[email-masked]>
Date: Mon, 8 May 2017 12:38:45 -0500

> 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 <[email-masked]> wrote:
> 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

---

From: Andrew Ayer <[email-masked]>
Date: Mon, 8 May 2017 11:11:41 -0700

On Thu, 4 May 2017 12:21:14 -1000

> deterministic signatures is significant enough to overcome these

I think preventing fingerprinting is important.  I suggest we loosen
the requirement on logs.  Logs should still be forbidden from producing
more than one distinct signature for any given STH or SCT, but we
shouldn't specify how logs must satisfy this requirement.

Here are some of the ways a log could satisfy this requirement:

1. Use RFC 6979.

2. Use a different deterministic signature scheme.

3. When producing a new STH or SCT, sign it, store the signature, and
serve the stored signature instead of re-signing on-the-fly every time
the log needs to serve the STH or SCT.  Since the log already needs
to store information about STHs and SCTs, also storing the signature
should not be burdensome.

I'll also note that forbidding the log from producing more than one
signature per STH makes it slightly easier for people participating in
STH pollination to deduplicate STHs, as it becomes possible to
deduplicate based on the entire STH rather than parsing out the
non-signature parts.

Regards,
Andrew

---

From: Linus Nordberg <[email-masked]>
Date: Tue, 09 May 2017 00:46:11 +0200

Andrew Ayer <[email-masked]> wrote

> shouldn't specify how logs must satisfy this requirement.

+1

---

From: Linus Nordberg <[email-masked]>
Date: Tue, 09 May 2017 00:54:38 +0200

> should not be burdensome.

Why do logs already need to store information about SCTs?

Do logs already need to store information about STHs because of the
proposed get-sths API [0][1][2] or something else?

[0] https://trac.ietf.org/trac/trans/ticket/160
[1] https://trac.ietf.org/trac/trans/ticket/163
[2] https://github.com/google/certificate-transparency-rfcs/pull/200

---

From: Andrew Ayer <[email-masked]>
Date: Mon, 8 May 2017 16:14:43 -0700

On Tue, 09 May 2017 00:54:38 +0200
Linus Nordberg <[email-masked]> wrote:

> > 3. When producing a new STH or SCT, sign it, store the signature,
> > and serve the stored signature instead of re-signing on-the-fly
> > every time the log needs to serve the STH or SCT.  Since the log
> > already needs to store information about STHs and SCTs, also
> > storing the signature should not be burdensome.
> 

Technically it's not required, but practically speaking logs need to
return an SCT for an existing entry when someone submits an
already-logged certificate (otherwise the log could be spammed into
oblivion).  To construct that SCT, the log needs to know the timestamp
of the existing entry.  A logical place to store the signature would be
alongside the timestamp.

> proposed get-sths API [0][1][2] or something else?

Even without the get-sths API, the log needs to store the timestamp of
the current STH.  That would be a logical place to store the signature.

Regards,
Andrew

---

From: Linus Nordberg <[email-masked]>
Date: Tue, 09 May 2017 01:32:31 +0200

> of the existing entry.  A logical place to store the signature would be

Ah, I see the confusion. I view the SCT as the data sent as a response
to an add-chain request, not the various parts it's being made
of. Storing the timestamp together with the cert chain makes a lot of
sense. Caching the signature as well is a different thing.

(On a side note, our log implementation has recently started mandating
caching of SCTs at frontend nodes in order to protect against a
"dropping-entries-attack" by a rogue frontend.)

> the current STH.  That would be a logical place to store the signature.

Right. Storing information about the _current_ STH is useful, agreed.

---

From: Linus Nordberg <[email-masked]>
Date: Tue, 09 May 2017 10:03:06 +0200

Rob Stradling <[email-masked]> wrote
Fri, 5 May 2017 22:16:08 +0100:

> Would it be a good idea to add Ed25519 to the initial list of
> permitted signature algorithms that logs can use?

I think it would.

---

From: Linus Nordberg <[email-masked]>
Date: Tue, 09 May 2017 10:53:59 +0200

Tom Ritter <[email-masked]> wrote

> there's no way to know, because as I said above - detection is hard.

You seem to focus on SCTs, which are indeed hard to share between
privacy concerned clients because they contain sensitive data. But STHs
have signatures too and I think we should limit the ways a log can track
clients asking for STHs.

Catching a log serving different log clients different bits for the same
timestamp, tree_size and root_hash is a matter of clients comparing
retrieved STHs. Keeping the requirement for deterministic signatures and
the limitation on STH issuance frequency (6962bis-24 4.8) makes
gossiping about STHs reasonable even for clients serving end users with
privacy expectations (gossip-04 10.5.4).

> So I think Eran's suggested changes are okay.

I think we should keep requiring deterministic signatures being used but
stop mandating how it is being done.

---

From: Linus Nordberg <[email-masked]>
Date: Tue, 09 May 2017 10:56:54 +0200

Brian Smith <[email-masked]> wrote

> it could use to sign certificates.

I'm going to expose my lack of knowledge of FIPS and ask why. What makes
RFC 6979 signatures unable to comply with FIPS?

---

From: Eran Messeri <[email-masked]>
Date: Tue, 9 May 2017 18:37:05 +0100

The downsides with storing signatures (for SCTs and STHs), which is an
additional storage requirement for something that can be generated
on-the-fly:
* Storage costs and processing: Logs have to use highly-reliable storage,
so every piece of data stored costs more and requires more processing to be
verified.
* Potential corruptions: What would a log do if it finds out it stores a
corrupted signature? It could continue operation by re-signing without
problems, unlike a corruption of the list of entries, where it's clear it's
unhealthy (a safety measure in some log implementations is to hash all
entries up to the last-issued STH and verify root hash, before adding new
entries and producing a new one).

This is a viable solution to the problem of deterministic signatures,
though, so it should be mentioned in -bis.
How about requiring returning the same signature for the same SCT / STH,
without requiring the use of deterministic signature schemes?

---

From: Tom Ritter <[email-masked]>
Date: Tue, 9 May 2017 12:43:33 -0500

> privacy expectations (gossip-04 10.5.4).

I agree that we could catch logs who do this to STHs relatively easily.

> stop mandating how it is being done.

Definitely agree that we not mandate how it is done.

I guess I'm more on the fence now because of the STH situation.

-tom

---

From: Al Cutter <[email-masked]>
Date: Tue, 9 May 2017 19:28:54 +0100

> so every piece of data stored costs more and requires more processing to be

TBH the cost of running a log is mostly going to be opex, the overhead of
storing an extra few tens of GB for a really big log like Pilot are
probably not going to be that noticeable.

> entries and producing a new one).

This is an interesting one...
Recalculating the root of a large tree from the leaf images is a kinda*
sequential operation but verifying the signatures over SCTs+leaves can be
as obscenely parallel as your storage permits. (*Not entirely true, you can
recurse and go wide of course, but that's considerably more complicated
than existing implementations I'm aware of which mostly tend to use a
compact Merkle tree approach.)
Also, unless the corruption of your signature and/or corresponding leaf
entry caused precisely one of them to be invalid DER, you don't really have
any idea which part is wrong, so simply re-signing and continuing operation
would probably not be wise.

> without requiring the use of deterministic signature schemes?

At least for SCTs this is not a good idea; if you require this, then by
implication you also require a strongly consistent global queue with
deduping for putting the to-be-sequenced leaves into. That's certainly one
way of building a log, but there are others, and not everyone's got Spanner
:)

Incidentally this is why RFC6962 says  'the log ... MAY return the same SCT
as it returned before'; I'd imagine most log implementations will generally
do this because it makes sense from the operators' PoV of controlling
growth, but there may be situations when they can't guarantee it.

---

From: Andrew Ayer <[email-masked]>
Date: Tue, 9 May 2017 11:37:23 -0700

On Tue, 9 May 2017 19:28:54 +0100
Al Cutter <[email-masked]> wrote:

> > This is a viable solution to the problem of deterministic
> > signatures, though, so it should be mentioned in -bis.
> > How about requiring returning the same signature for the same SCT /
> > STH, without requiring the use of deterministic signature schemes?
> >
> 
> At least for SCTs this is not a good idea; if you require this, then
> by implication you also require a strongly consistent global queue
> with deduping for putting the to-be-sequenced leaves into. That's
> certainly one way of building a log, but there are others, and not
> everyone's got Spanner :)
> 
> Incidentally this is why RFC6962 says  'the log ... MAY return the
> same SCT as it returned before'; I'd imagine most log implementations
> will generally do this because it makes sense from the operators' PoV
> of controlling growth, but there may be situations when they can't
> guarantee it.

Ah, good point.

Maybe we should only require same/deterministic signatures for STHs.
As Tom and Linus have discussed, that's where same/deterministic
signatures are the most needed anyways.

Regards,
Andrew

---

From: Eran Messeri <[email-masked]>
Date: 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.
* 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).
Also, in 6962-bis, my focus is on correct operation of the log & Merkle
Tree - and deterministic signatures are not strictly necessary for that.

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?

---

From: Brian Smith <[email-masked]>
Date: Fri, 12 May 2017 08:40:34 -1000

Eran Messeri <[email-masked]> wrote:
> * 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.

This sounds good to me. I'm not sure that the reference to RFC 6979
needs to be removed. It could be referenced as an example of a
deterministic signature scheme.

Cheers,
Brian

---

From: Linus Nordberg <[email-masked]>
Date: Mon, 15 May 2017 12:50:02 +0200

Eran Messeri <[email-masked]> wrote

> (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.

> different timestamps, which the log may issue, cannot have the same

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?

> 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?

> * Mention that deterministic signatures can be achieved by storing the

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.

---

From: Eran Messeri <[email-masked]>
Date: Mon, 15 May 2017 12:35:32 +0100

On Mon, May 15, 2017 at 11:50 AM, Linus Nordberg <[email-masked]> wrote:

> 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.

> Also, this talks about SCTs specifically. What do you think the story is
Seems to me like the same reasoning applies to both - sorry, wasn't clear
about it.

> Also, does this imply that the limitation on STH issuance frequency
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).

> 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?

---

From: Eran Messeri <[email-masked]>
Date: 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

---

From: Linus Nordberg <[email-masked]>
Date: Mon, 22 May 2017 16:21:54 +0200

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 <[email-masked]> wrote
Mon, 22 May 2017 13:23:12 +0100:

>> <https://chromium.googlesource.com/chromium/src/+/dba25668458c87c4b38c63db710c49c47d0db087>> from Chrome recently). Even if there was such an implementation, because

---

From: Gary Belvin <[email-masked]>
Date: Mon, 22 May 2017 15:16:24 +0000

> 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 <[email-masked]> wrote:

> >>> > also by logs storing the produced signatures and returning them
> instead
> >>> of
> >>> > (SCTs or STHs) because it's not clear what TLS clients will gossip
> and
> >>> how.
> >>>
> >> <
> https://chromium.googlesource.com/chromium/src/+/dba25668458c87c4b38c63db710c49c47d0db087>>

---

From: Linus Nordberg <[email-masked]>
Date: Mon, 22 May 2017 19:38:24 +0200

Gary Belvin <[email-masked]> wrote

> supplied data that wasn't directly tied to the leaves themselves would seem

Yes. My understanding is that they are all under control.

For STH's: The log id is fixed. The number of timestamps, the tree size
and the root hash are limited by the STH frequency count. The extensions
field is unused.

For SCT's: The log id is fixed. Timestamps are limited by the visibility
in the log and the cost of storage forever. The extensions field is
unused. None of issuer key hash and (pre-) certificate in the
timestamped entry are server supplied.

Please let us know if we're missing something.

---

From: Eran Messeri <[email-masked]>
Date: Tue, 23 May 2017 10:41:49 +0100

On Mon, May 22, 2017 at 6:38 PM, Linus Nordberg <[email-masked]> wrote:

> SCTs
(1) while the STH frequency is bound, a log is not required to produce STHs
at that frequency - it can (and I suspect most operators will) issue STHs
at a lower frequency. So it's still possible for the log to issue a few
STHs which a few "select" clients will see - it all depends on the
operational model of STH distribution / fetching.
(2) while the extensions field is currently unused, clients are required to
ignore any extension they do not understand, so a log may put arbitrary
data there.

> timestamped entry are server supplied.
The timestamp is chosen by the log, and a log may choose to create several
entries, with different timestamps, for a single submission (useful if a
log and server collude). Again, the usefulness of this for tracking a
client depends on the SCT reporting/gossip model.

My point is that even with fully deterministic signatures, it's very hard
to defend against this vector of client fingerprinting, particularly in the
face of unknown operational/threat model.
Furthermore, there are other ways to track a client - even today, with 6962
and Expect-CT: A server may simply collect SCTs from multiple logs and
serve a unique subset of SCTs to the client it wants to track, setting the
Expect-CT header for reporting only. But a server that wants to track
clients has many, many ways that are more straightforward.

---

From: Linus Nordberg <[email-masked]>
Date: Tue, 23 May 2017 12:00:44 +0200

> ignore any extension they do not understand, so a log may put arbitrary

You're right. So it's not impossible to track clients using the
extension field but at least it's visible.

---

From: Andrew Ayer <[email-masked]>
Date: Wed, 24 May 2017 12:33:47 -0700

On Mon, 22 May 2017 16:21:54 +0200

> views on the balance we're trying to strike.

I would also be sad - particularly in the case of STHs.  I may be
willing to give up mandatory consistent SCT signatures, since
privacy with SCTs might be a lost cause anyways, and because it's
hard for logs to ensure consistent SCT signatures without using
deterministic signatures (due to the need to issue SCTs from many
different frontends).  However, it doesn't seem hard for logs to have
consistent STH signatures.

> Regarding current deployment, are there any 6269bis logs deployed yet?

I don't know of any.  However, it may be interesting to note that of
the 31 publicly-known RFC6962 logs[1], all but two (Clicky and Behind
the Sofa) return the same signature for repeated get-sth requests, which
suggests that this is not a difficult requirement for STHs.  The two
logs which return a new signature for each get-sth request are running
Trillian. It would be interesting to hear from the Trillian developers
why Trillian behaves this way and whether it would be difficult to
persist STH signatures as other implementations do.

> Regarding gossip unclearity, the suggested change risks making it harder

Agreed.  We may never know how necessary consistent STH signatures are
if attempts to experiment with STH gossip are stillborn due to privacy
concerns.  It would make more sense to start out with a strong
requirement, and loosen it later if it turns out to be unnecessary.

Regards,
Andrew

[1] https://sslmate.com/labs/ct_ecosystem/ecosystem.html

---

From: Al Cutter <[email-masked]>
Date: Thu, 25 May 2017 16:29:49 +0100

On 24 May 2017 8:33 pm, "Andrew Ayer" <[email-masked]> wrote:

The short answer is because we've not built any support for doing that yet
:)

The slightly longer answer is that Trillian is a General Transparency
implementation, rather than a CT implementation, and there are some
divisions of responsibility in there:
  - Trillian maintains the trees of opaque blobs, updating them with
batches of new entries, and creates Trillian Tree Heads (signed with
Trillian tenant keys) for each update.
 - Then there's a CT 'personality' layer in front which uses Trillian APIs
to build a CT log, and that, currently, has no distributed state, so each
instance of this personality creates a CT STH from the data in the latest
Trillian Tree Head, and signs that with the CT log's key.

The CT personality layer could certainly be extended to somehow select and
"bless" STHs in some fashion.  This idea of logging STHs would also provide
a nice mechanism for doing that, as it happens :)

Regards,
Andrew