On 23 July 2015 at 04:16, Linus Nordberg <[email protected]> wrote:
> | "An SCT MUST NOT be sent to any other HTTPS server than one serving
> | the domain that the certificate signed by the SCT refers to.{Not all TLS
> | clients care about privacy: e.g. crawlers, so this MUST NOT is too strong}"
>
> I see. Wonder how we could express that. Should we try to differentiate
> between browsers with real people using them and other clients? Or bring
> in "user consent"?
Well, if a crawler sends an SCT for amazon.com to ritter.vg - I'm
going to ignore it. (I don't want you filling up my disk space.)
If you configure you server to accept any SCT, and your crawler sends
all the SCTs to it... I would describe this as a Trusted Auditor
relationship, that just happens to use (roughly) the same protocol as
SCT Feedback. How Trusted Auditors are implemented is well out of
scope. So I don't think any change is necessary, but we could clarify
I suppose.
> | "First, the server
> | recieving the SCT would learn about other sites visited by the HTTPS
> | client{if SCTs are gossipped then this is clearly untrue: however, I
> | agree that it is hard to avoid some kind of privacy leak}. "
>
> It is true for the first N clients gossiping was my first reaction. Then
> there was an interesting discussion off list about if either of those
> claims could be proven correct through simulation. Without more data my
> position is that we don't know and should err on the side of safety and
> not gossip SCTs.
Strong ++
> | "If the HTTPS client has configuration options for not sending cookies
> | to third parties, SCTs MUST be treated as cookies with respect to
> | this setting.{don't understand - you already banned sending to third
> | parties}"
>
> This is for local attacks, i.e. someone digging through the local
> store. Should probably expand. Added a TODO for now.
Did we ban sending to third parties? I don't think so. I know for
sure we said "don't send SCTs for amazon.com to ritter.vg". But if
ritter.vg embeds something from https://amazon.com - that connection
_could_ send SCTs. UNLESS the client is configured to not send
cookies on these sort of connections (the browser setting is Third
Party Cookies.) If Third Party Cookies are disallowed, then SCTs on
such connections should also be disallowed.*
* There are probably other sorts of super-cookies amazon.com could
use, but we should not introduce a new leak.
> | "The data sent in the POST is defined in Section 5.1.3.{what if the POST
> | fails, as it obviously will for most servers initially?}"
>
> Then no SCT Feedback is happening. Do we need to add text?
In general we need to do a full pass and review for the cases of "What
happens if the client's attempt to send Feedback/Pollination data
fails".
> | " It's important to note
> | that the check must be on pairs of SCT and chain in order to catch
> | different chains accompanied by the same SCT. [XXX why is this
> | important?]{given that logs do _not_ have to log multiple chains, I
> | suspect this is actually not important}"
>
> This could be of interest to the operator of the web site. Creating more
> incentive for them to play along is probably valuable. It can be debated
> whether it's worth it or not.
I swore earlier Ben said it would be useful for site operators to
receive not only chains, but the cert ordering that was sent from the
server... but I can't find that email so perhaps I'm attributing
someone else's comments to him. I think including the cert chain and
the cert ordering from the server* will be an open issue for a bit
longer.
* If that's even easily retrieved in the appropriate browser layer!
> | " Note that an HTTPS server MAY perform a certificate chain validation
> | on a submitted certificate chain, and if it matches a trust root
> | configured on the server (but is otherwise unknown to the server),
> | the HTTPS server MAY store the certificate chain and MAY choose to
> | store any submitted SCTs even if they are unable to be verified. The
> | risk of spamming and denial of service can be mitigated by
> | configuring the server with all known acceptable certificates (or
> | certificate hashes). {Confused by this, surely the point is to find
> | certs/SCTs the server does not expect?}"
>
> I think we thought this would help catching an SCT even if it doesn't
> verify correctly by imposing some limits on the cert chain that came
> with it.
Storing the server cert and chain helps catch unknown certs.
Storing the SCT(s) may help find that cert in a log. (Or detect
misbehavior by a log.)
So, to answer Ben's question - yes. Perhaps the "reduce the risk of
spamming" sentence was confusing?
> | 6.1.1
> |
> | " Therefore, a
> | client with an SCT for a given server should transmit that
> | information in only two channels: to a server associated with the SCT
> | itself; and to a trusted CT auditor, if one exists.{only if the client
> | cares about privacy}"
>
> See comment above ("I see. Wonder how we could express that.[...]")
If they don't care about privacy, they can talk to a Trusted Auditor.
And clients of course choose their own definition of "Trusted".
On 23 July 2015 at 04:53, Ben Laurie <[email protected]> wrote:
>> | 5.2.2
>> |
>> | "After retrieving the consistency proof to the most recent STH, they
>> | SHOULD pollinate this new STH among participating HTTPS Servers {and
>> may
>> | safely discard the older STH}. "
>>
>> Unless it should be gossiped some more? We only know that it's correct
>> with regard to the particular view of the log we're being served. I
>> don't think we've decided when to stop gossiping about a particular STH
>> yet.
>
>
> The point is that the newer STH includes the older one (i.e. it proves the
> log contains all the things the older one proved it contained), so there's
> no value in retaining the older STH...
++ to this
-tom
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
