Re: [Trans] Removing the Preventing Tracking Clients section

[Tom Ritter <[e-mail]>]

On 24 April 2018 at 16:43, Andrew Ayer <[e-mail]> wrote:
> On Fri, 20 Apr 2018 22:13:54 +0100
> Rob Stradling <[e-mail]> wrote:
>
>> EKR had some concerns about this section
>> (https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-28#section-11.4).
>>   We (the authors) discussed it and concluded that this section
>> should probably be struck from 6962-bis.
>>
>> PR here:
>> https://github.com/google/certificate-transparency-rfcs/pull/295
>>
>> Anyone have any objections?
>
> Yes.  Developing a workable gossip solution will require experimentation
> to get it right.  If log artifacts (STHs and SCTs) can act as
> supercookies, it will limit the type of experimentation that can be done
> by TLS clients, as clients won't be able to store and transmit artifacts
> without potentially violating their users' privacy.
>
> Al proposes that this section be moved to a gossip doc, but that
> creates a circular dependency: logs won't implement an unproven,
> experimental gossip spec, but proving the viability of the spec will
> only be possible if logs comply with the spec's anti-tracking
> provisions. We can avoid the circular dependency by leaving this
> section in 6962-bis. This will allow TLS clients to experiment with
> different types of gossip without worrying that the log artifacts that
> they're gossiping might be supercookies.
>
> I'd like to better understand EKR's concern with this section, so I can
> propose better text.  But I don't see any inline comments about this
> section at https://mozphab-ietf.devsvcdev.mozaws.net/D13 (perhaps I'm
> not using Phabricator correctly?).


Also agree; although TBH I don't much care for the section text as is.
Especially "Logs SHOULD mitigate this risk" - the risk is that the Log
has done something bad - either by design or by accident. The
'mitigation' tries to address the accidental part; but not the design
part.

To me, it's basically saying "Logs may misbehave, so to avoid logs
misbehaving, logs should do one of these two things."  It seems like
it would be better to say "Logs should not misbehave, and can make
implementation choices that (should) prevent inadvertent misbehavior."

-tom