Re: [Trans] comments on draft-linus-trans-gossip-ct-01

[Linus Nordberg <[e-mail]>]

Benjamin Kaduk <[e-mail]> wrote
Tue, 24 Mar 2015 17:37:25 -0400 (EDT):

| Ah, looking at the diff makes what is going on more clear.  7c9801f is
| probably not helping very much; there seems to be some issue with the
| conversion process from markdown.  If you look at
| https://tools.ietf.org/html/draft-linus-trans-gossip-ct-01#section-4.1.3 ,
| the bulleted list from the markdown ... isn't.  I have no experience with
| writing I-Ds in markdown, but I am sure there are some experts who can be
| consulted.

Oh! Fixed in e261141.


Benjamin Kaduk <[e-mail]> wrote
Tue, 24 Mar 2015 18:16:06 -0400 (EDT):

| In section 3.1.1, """When the client later reconnects to any HTTPS server
| for the same domain it again receives a set of SCTs.  The client [...]
| MUST send to the server the ones in its store that were not received from
| that server."""  This precludes the client from doing any sort of MITM
| detection and refusing to send SCTs to a (presumed) attacker.  Admittedly,
| the scope of exposure here is pretty small; it seems like the only privacy
| loss would be that attacker A who has MITM'd the client then can learn
| whether the client has *also* been MITM'd by attacker B at some point in
| the past (since presumably the attackers know which SCTs are legitimate).
| But, it is not too much of a stretch to think that three-letter
| organizations might want to know if their target is being attacked by
| someone else.

That's an interesting attack. The best thing I can come up with right
now would be to s/MUST/SHOULD/1 and leave it at that.

I have very little clue about how that would change implementors minds
about the whole thing though. Guidance welcome.


| > | > | > In a related vein, in 3.1.2, should the server be allowed to exclude SCTs
| > | > | > that it considers legitimate?
| > | > |
| > | > | This is an optimization: if a server sends you SCTs A,B,C and then you
| > | > | as a client report back to it "I know about SCTs A, B, and C - it
| > | > | doesn't make a whole lot of sense for a server to report those to the
| > | > | auditor.
| > | > |
| > | > | I suppose; however, that an attacker may feed a server invalid SCTs
| > | > | somehow to 'load it's cache' such that it never reports them. So
| > | > | perhaps yes, it should report the SCTs it knows about to an auditor.
| > | >
| > | > I'm thinking of SCT's being legitimate as a "policy decision" made by
| > | > the operator and not something a piece of software decides. Does this
| > | > make sense? Should we add text to explain this?
| > |
| > | I guess I'm coming at this from the assumption that an auditor will want
| > | to know about all SCTs for a given site, including the "legitimate" ones.
| > | On the other hand, it could be useful for the site to have a way to
| > | indicate to an external auditor which SCTs it believes are legitimate.
| > | But it's not clear that omitting them from the results is the best way to
| > | make that indication, since it is not distinguishable from the site not
| > | knowing about those SCTs.  In short, is the extra complexity of making
| > | this optional justified?
| >
| > Backing up a bit, the question can be posed as whether the optimisation
| > of not sending them all is justified. This is somewhat related to the
| > open question of how (push vs. pull) and how often and much auditors and
| > web servers gossip. Getting an idea about the quantity of data would
| > help. I don't have any numbers at the moment.
| 
| 
| Waiting for data seems like a fine plan for now.
| 
| I do wonder if there should be an explicit way for an auditor to query
| which SCTs are considered "legitimate".

I've been thinking about some "score" mechanism too. My gut feeling is
that it complicates an already complicated matter. Open to suggestions
though.


| Hmm, re-reading the document just now I noticed a new issue -- in section
| 3.1.1 ("HTTPS client to server"), the first enumerated action is not
| required for interoperability, so I don't think MUST is appropriate.  (It
| is explicitly disclaimed as "a pure optimization".)

Right. I think I fixed that in d07126a.


Benjamin Kaduk <[e-mail]> wrote
Wed, 25 Mar 2015 00:17:26 -0400 (EDT):

| It looks like the other one was in 3.1.2, "HTTPS servers MUST NOT share
| any other data that they may learn from the submission of SCTs by HTTP
| clients".  My immediate response to that statement was "what goes wrong if
| a server misbehaves?"  Thinking about it now, it seems like the answer is
| "not very much, compared to a misbehaving server which does not implement
| CT", but confirmation would be nice.  Maybe my response to this line of
| thought would be to remove the RFC 2119 language and just ensure it's in
| the security/privacy considerations, but it's probably not a big deal
| either way.

We are giving server implementors a new vehicle to hurt the privacy of
their clients. It seems proper to make sure it's not being used for
that.

That said, I'm not well versed in 2119 language. I'll wait for more
comments on this.

Thanks!