Subject: [Trans] comments on draft-linux-trans-gossip-ct-01

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 22 Mar 2015 22:51:38 -0400 (EDT)

First off, I have a general comment that there seem to be some places in
the document where it is implicitly assumed that the HTTPS client and
server trust each other to behave correctly and are "only" truing to
detect misbehavior by other parties (i.e., CAs or parties subverting the
CA infrastructure, etc.), to the exclusion of having the client and server
retain some level of distrust or sanity checking of each other.  I'm not
sure that the client wants to always trust the server, given that the
scheme is positing a universe where some clients will sometimes
successfully connect to hostile servers supplied with fraudulent
certificates (that validate) by the attacker.

In a related vein, in 3.1.2, should the server be allowed to exclude SCTs
that it considers legitimate?  What are the consequences if the server
misbehaves and shares "other data that they may learn from the submission
of SCTs by HTTP clients"?

I'm also a little confused by the last paragraph of 3.1.2, "the selection
MUST NOT be influenced by potential HTTPS clients connecting directly to
the auditor".  It seems like the only risk of allowing a client to request
monitoring for a given site is additional resource usage by the server
(assuming the client is aware of the privacy considerations of making such
a request).  I suspect that there is a valid concern here, but the text as
written may be overly broad.

I seem to be missing a normative reference for various terminology and
conventions (e.g., "the timestamp, as a number", which I assume is
milliseconds since the epoch, excluding leap seconds, in decimal, to match
the other specs).

The formatting in 4.1.3 seems funky; it looks like a list has been
condensed into running text (including bullet symbols)

-Ben

---

From: Tom Ritter <[email-masked]>
Date: Sun, 22 Mar 2015 22:38:48 -0500

On 22 March 2015 at 21:51, Benjamin Kaduk <[email-masked]> wrote:
> retain some level of distrust or sanity checking of each other.

If it is not clear, I think it should be made explicit that the
purpose of CT gossip is to detect misbehaving CT logs - and nothing
more.  The purpose of CT is to detect misbehaving CAs.

A misbehaving server is making itself vulnerable, so they have an
incentive to behave. If a server misbehaves in collusion with a log,
it will hopefully be detected by an HTTPS client sharing SCTs directly
with an auditor (which is mentioned in a sentence in 3.1.2, and is a
natural extension if a user _wishes_ to give up some privacy.) But
this scenario also doesn't seem to make a lot of sense - why would a
server collude with a log when it can achieve the same goal with
significantly less work and less risk?

> I'm not

The client is trusting that it will eventually connect to a behaving
server and that a server is interested in detecting mis-issuance for
itself. Another way to phrase it is that a client is not cordoned off
for a given server once and forever, with no way to ever connect to
the valid server again

If it's not clear that the client does not empty it's SCT cache into a
server and say "Okay, I'm all set" -then it should be made so. The
client doesn't do that. It retains SCTs and reports them according to
some unspecified UA algorithm. (exponential backoff plus
randomization?)

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

> What are the consequences if the server

It would be a privacy violation of the client.

> written may be overly broad.

It's designed to prevent the following traffic analysis:

- Adversary is watching traffic of the auditor and client, and wants
to learn historical client behavior
- Client connects to an auditor and sends a bunch of SCTs over HTTPS
- Auditor immediately goes and queries all the domains the client sent for
- Adversary learns which domains the client sent in SCTs for

-tom

---

From: Linus Nordberg <[email-masked]>
Date: Mon, 23 Mar 2015 12:11:49 +0100

Ben,

Thanks for the review. Addressing some issues below and others in a
separate reply to Tom's comments.

Benjamin Kaduk <[email-masked]> wrote
Sun, 22 Mar 2015 22:51:38 -0400 (EDT):

| I seem to be missing a normative reference for various terminology and
| conventions (e.g., "the timestamp, as a number", which I assume is
| milliseconds since the epoch, excluding leap seconds, in decimal, to match
| the other specs).

They are all from RFC6962. What'd be the right way of refer to it?
Mentioning 6962 in each and every entry, like

         +  sct_version - Version as defined in [RFC6962] Section 3.2,
            as a number.

         +  log_id - LogID as defined in [RFC6962] Section 3.2, as a
            base64 encoded string.

or rather put some text at the top of the section (3.1.3. in this case)?

| The formatting in 4.1.3 seems funky; it looks like a list has been
| condensed into running text (including bullet symbols)

Would capitalizing the first word of each point be sufficient or should
we get rid of the list altogether?

---

From: Linus Nordberg <[email-masked]>
Date: Mon, 23 Mar 2015 12:12:18 +0100

Tom Ritter <[email-masked]> wrote
Sun, 22 Mar 2015 22:38:48 -0500:

| > I'm not
| > sure that the client wants to always trust the server, given that the
| > scheme is positing a universe where some clients will sometimes
| > successfully connect to hostile servers supplied with fraudulent
| > certificates (that validate) by the attacker.
| 
| The client is trusting that it will eventually connect to a behaving
| server and that a server is interested in detecting mis-issuance for
| itself. Another way to phrase it is that a client is not cordoned off
| for a given server once and forever, with no way to ever connect to
| the valid server again
| 
| If it's not clear that the client does not empty it's SCT cache into a
| server and say "Okay, I'm all set" -then it should be made so. The
| client doesn't do that. It retains SCTs and reports them according to
| some unspecified UA algorithm. (exponential backoff plus
| randomization?)

Branch sct-feedback of https://github.com/ln5/internet-drafts.git makes
an initial attempt at explaining this [1]. Improved wording is welcome!

[1] https://github.com/ln5/internet-drafts/commit/6310b87e826d0a6f650fa39532932d24176b7cbe

| > 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'm also a little confused by the last paragraph of 3.1.2, "the selection
| > MUST NOT be influenced by potential HTTPS clients connecting directly to
| > the auditor".  It seems like the only risk of allowing a client to request
| > monitoring for a given site is additional resource usage by the server
| > (assuming the client is aware of the privacy considerations of making such
| > a request).  I suspect that there is a valid concern here, but the text as
| > written may be overly broad.
| 
| It's designed to prevent the following traffic analysis:
| 
| - Adversary is watching traffic of the auditor and client, and wants
| to learn historical client behavior
| - Client connects to an auditor and sends a bunch of SCTs over HTTPS
| - Auditor immediately goes and queries all the domains the client sent for
| - Adversary learns which domains the client sent in SCTs for

Should we add text explaining this? Should explanations like this go
into "Security considerations", refering to appropriate sections (like
3.1.2. in this particular case)?

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 23 Mar 2015 10:43:14 -0400 (EDT)

[fixed embarassing typo in the subject line]

> or rather put some text at the top of the section (3.1.3. in this case)?

I would actually consider making a section 1.1 "Terminology", with
something like "this document relies on terminology and data structures
defined in RFC 6962, including but not limited to the SCT Version, LogID,
SCT timestamp, CTExtensions, ...".  Of the two you list, I would prefer
the former (mentioning 6962 in each line).

> we get rid of the list altogether?

This list is okay, but I would just make it a semicolon-separated list.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 23 Mar 2015 11:50:26 -0400 (EDT)

> | for a given server once and forever, with no way to ever connect to

I know that, and you know that, but we want to make sure that the document
says that as well.  Linus's suggestion below is a good start.

But this is still not really addressing the issue I was trying to raise.
Yes, the goal of this protocol is to enable a client and server to
cooperate to detect misbehavior by third parties.  But that does not
absolve us of a responsibility to analyze the situation where one of the
client and/or server misbehaves, and document the security and privacy
considerations in that case.

> [1] https://github.com/ln5/internet-drafts/commit/6310b87e826d0a6f650fa39532932d24176b7cbe

That is helpful.

Could we also add a paragraph to the end of the introduction motivating
clients sending SCTs to servers due to it not presenting an additional
privacy leak?  Perhaps something like:

"""
However, there is no loss in privacy if a client sends SCTs for a given
site to the site named in the SCT, since the site's access logs would
already indicate that the client is accessing that site.  In this way a
site can accumulate records of SCTs that have been issued by various logs
for that site, providing a consolidated repository of SCTs which can be
queried by an auditor interested in that site (such as the site's owner
itself).
"""

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

> 3.1.2. in this particular case)?

I think it would be fine to mention this in 4.1.2 (near "SCTs [are]
sensitive data").

I still think it is possible for a properly-written auditor to add sites
to monitor in a way which does not expose client information via traffic
analysis (i.e., probabilistic/staggered/delayed queries), but I am willing
to conced that getting it right is sufficiently hard that we should not be
recommending it.

-Ben

---

From: Linus Nordberg <[email-masked]>
Date: Tue, 24 Mar 2015 08:35:30 +0100

Benjamin Kaduk <[email-masked]> wrote
Mon, 23 Mar 2015 11:50:26 -0400 (EDT):

| On Mon, 23 Mar 2015, Linus Nordberg wrote:
| 
| > Tom Ritter <[email-masked]> wrote
| > Sun, 22 Mar 2015 22:38:48 -0500:
| >
| > | > I'm not
| > | > sure that the client wants to always trust the server, given that the
| > | > scheme is positing a universe where some clients will sometimes
| > | > successfully connect to hostile servers supplied with fraudulent
| > | > certificates (that validate) by the attacker.
| > |
| > | The client is trusting that it will eventually connect to a behaving
| > | server and that a server is interested in detecting mis-issuance for
| > | itself. Another way to phrase it is that a client is not cordoned off
| > | for a given server once and forever, with no way to ever connect to
| > | the valid server again
| 
| I know that, and you know that, but we want to make sure that the document
| says that as well.  Linus's suggestion below is a good start.
| 
| But this is still not really addressing the issue I was trying to raise.
| Yes, the goal of this protocol is to enable a client and server to
| cooperate to detect misbehavior by third parties.  But that does not
| absolve us of a responsibility to analyze the situation where one of the
| client and/or server misbehaves, and document the security and privacy
| considerations in that case.

Do you have suggested text?

| > | If it's not clear that the client does not empty it's SCT cache into a
| > | server and say "Okay, I'm all set" -then it should be made so. The
| > | client doesn't do that. It retains SCTs and reports them according to
| > | some unspecified UA algorithm. (exponential backoff plus
| > | randomization?)
| >
| > Branch sct-feedback of https://github.com/ln5/internet-drafts.git makes
| > an initial attempt at explaining this [1]. Improved wording is welcome!
| >
| > [1]
| > https://github.com/ln5/internet-drafts/commit/6310b87e826d0a6f650fa39532932d24176b7cbe
| 
| That is helpful.
| 
| Could we also add a paragraph to the end of the introduction motivating
| clients sending SCTs to servers due to it not presenting an additional
| privacy leak?  Perhaps something like:
| 
| """
| However, there is no loss in privacy if a client sends SCTs for a given
| site to the site named in the SCT, since the site's access logs would
| already indicate that the client is accessing that site.  In this way a
| site can accumulate records of SCTs that have been issued by various logs
| for that site, providing a consolidated repository of SCTs which can be
| queried by an auditor interested in that site (such as the site's owner
| itself).
| """

Tweaked it a bit and added it (1c45c37) to section Problem, now renamed
Introduction. Thanks.

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

| > | > I'm also a little confused by the last paragraph of 3.1.2, "the selection
| > | > MUST NOT be influenced by potential HTTPS clients connecting directly to
| > | > the auditor".  It seems like the only risk of allowing a client to request
| > | > monitoring for a given site is additional resource usage by the server
| > | > (assuming the client is aware of the privacy considerations of making such
| > | > a request).  I suspect that there is a valid concern here, but the text as
| > | > written may be overly broad.
| > |
| > | It's designed to prevent the following traffic analysis:
| > |
| > | - Adversary is watching traffic of the auditor and client, and wants
| > | to learn historical client behavior
| > | - Client connects to an auditor and sends a bunch of SCTs over HTTPS
| > | - Auditor immediately goes and queries all the domains the client sent for
| > | - Adversary learns which domains the client sent in SCTs for
| >
| > Should we add text explaining this? Should explanations like this go
| > into "Security considerations", refering to appropriate sections (like
| > 3.1.2. in this particular case)?
| 
| I think it would be fine to mention this in 4.1.2 (near "SCTs [are]
| sensitive data").
| 
| I still think it is possible for a properly-written auditor to add sites
| to monitor in a way which does not expose client information via traffic
| analysis (i.e., probabilistic/staggered/delayed queries), but I am willing
| to conced that getting it right is sufficiently hard that we should not be
| recommending it.

Could this be what 4.1.2 calls "mixing"? We put that down as "TBD" for
now.

---

From: Linus Nordberg <[email-masked]>
Date: Tue, 24 Mar 2015 08:37:13 +0100

Benjamin Kaduk <[email-masked]> wrote
Mon, 23 Mar 2015 10:43:14 -0400 (EDT):

| [fixed embarassing typo in the subject line]

Don't worry. It's not the first time that's happened. :)

| > | I seem to be missing a normative reference for various terminology and
| > | conventions (e.g., "the timestamp, as a number", which I assume is
| > | milliseconds since the epoch, excluding leap seconds, in decimal, to match
| > | the other specs).
| >
| > They are all from RFC6962. What'd be the right way of refer to it?
| > Mentioning 6962 in each and every entry, like
| >
| >          +  sct_version - Version as defined in [RFC6962] Section 3.2,
| >             as a number.
| >
| >          +  log_id - LogID as defined in [RFC6962] Section 3.2, as a
| >             base64 encoded string.
| >
| > or rather put some text at the top of the section (3.1.3. in this case)?
| 
| I would actually consider making a section 1.1 "Terminology", with
| something like "this document relies on terminology and data structures
| defined in RFC 6962, including but not limited to the SCT Version, LogID,
| SCT timestamp, CTExtensions, ...".  Of the two you list, I would prefer
| the former (mentioning 6962 in each line).

Addressed in b3c2525.

| > | The formatting in 4.1.3 seems funky; it looks like a list has been
| > | condensed into running text (including bullet symbols)
| >
| > Would capitalizing the first word of each point be sufficient or should
| > we get rid of the list altogether?
| 
| This list is okay, but I would just make it a semicolon-separated list.

7c9801f.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 24 Mar 2015 17:37:25 -0400 (EDT)

Thanks for the updates.

> | This list is okay, but I would just make it a semicolon-separated list.

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.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 24 Mar 2015 18:16:06 -0400 (EDT)

> Do you have suggested text?

Any text I would suggest would be text that I am not entirely happy with,
since I do not have confidence that I correctly understand the security
and privacy considerations in question.

Unfortunately, I left the copy of the document that I marked up at the
hotel, so I have to recreate my work and only remember one of the places
that tickled this concern (there were at least two):

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.

> Tweaked it a bit and added it (1c45c37) to section Problem, now renamed

Looks good; thanks for the cleanup.

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

> Could this be what 4.1.2 calls "mixing"? We put that down as "TBD" for

They are very related issues, and TBD for now is fine.  When the mixing
question comes up again, we might think about auditors starting to monitor
more sites as well.

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

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 25 Mar 2015 00:17:26 -0400 (EDT)

> organizations might want to know if their target is being attacked by

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.

-Ben

---

From: Linus Nordberg <[email-masked]>
Date: Wed, 25 Mar 2015 06:58:08 +0100

Benjamin Kaduk <[email-masked]> 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 <[email-masked]> 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 <[email-masked]> 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!