Subject: [Trans] [trans] #130 (gossip): Support Delegation of SCT Feedback/STH Pollination

From: "trans issue tracker" <[email-masked]>
Date: Thu, 19 Nov 2015 16:24:39 -0000

#130: Support Delegation of SCT Feedback/STH Pollination

 Delegation is always possible, it's just currently difficult.  Maybe we
 should make it straightforward and easy...

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-threat-
  [email-masked]          |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  gossip       |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/130>
trans <http://tools.ietf.org/trans/>

---

From: Melinda Shore <[email-masked]>
Date: Thu, 19 Nov 2015 08:21:50 -0900

Hi, Tom:

Is there something specific you'd like to see happen here?
This looks more like a general comment than an issue that
can be addressed in the document.  That is to say, I'm not
sure why this is a ticket.

Melinda

-------- Forwarded Message --------
Subject: [Trans] [trans] #130 (gossip): Support Delegation of SCT
Feedback/STH Pollination
Resent-Date: Thu, 19 Nov 2015 08:24:40 -0800 (PST)
Resent-From: [email-masked]
Resent-To: [email-masked]
Date: Thu, 19 Nov 2015 16:24:39 -0000
From: trans issue tracker <[email-masked]>
To: [email-masked], [email-masked]
CC: [email-masked]

_______________________________________________
Trans mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trans

---

From: Tom Ritter <[email-masked]>
Date: Thu, 19 Nov 2015 12:38:35 -0500

I wanted to capture the TODO - either we're going to change the doc to
support it, or we're not, but I don't want to forget to make a decision :)

If people have a strong opinion on delegation, I'd love to hear it,
especially if it includes a way to do it (HTTP Header, redirects, etc)

-tom

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 24 Nov 2015 06:24:22 -0000

Comment (by [email-masked]):

 Is this about SCT Feedback, STH Pollination, or both?

 I don't like the idea that web servers send data from clients to a third
 party. I do realise it can be done regardless of my feelings. That's not
 an argument for adding any mechanisms for it to CT gossip though. Does it
 have any value? I'd like to hear more about that.

 Severity:  -            |  Resolution:
 Keywords:               |

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/130#comment:1>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 24 Nov 2015 14:21:13 -0000

Comment (by [email-masked]):

 Regardless of which we're talking about, it seems obvious that people will
 want to:

 a) Contract out the service of looking after their certificates, including
 worrying about CT, or

 b) Centralise their own management of such things.

 Both of these would be improved by allowing delegation.

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/130#comment:2>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 24 Nov 2015 15:02:33 -0000

Quick sanity check: Does delegation mean that the HTTPS server instructs
 its client to use a certain URL for report back, a URL that most probably
 has a host part (in the RFC1738 section 3.3 sense) that is not the same as
 the host part of the visited URL?

 Assuming yes, I've thought of SCT Feedback as something collected by the
 very same server as served the SCT and cert chain the client wants to
 report about. That server may, or even should, let auditors and monitors
 learn about what's collected. It must do so in a privacy preserving manner
 (that isn't fully laid out in the gossip draft).

 Having the client go to another server for reporting is bad not only from
 a privacy perspective but also from a blocking perspective. The idea with
 performing the reporting in the same TLS session as the ordinary
 request(s) will not translate to a delegation scenario AFAICT.

 As for STH Pollination, I don't know yet. Seems less problematic but I
 would probably want my browser not to connect to any domain (URL host
 part) that I haven't requested. Think "refusing third party content".

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/130#comment:3>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Thu, 26 Nov 2015 14:38:01 -0000

Yes, a different host.

 I think '''requiring''' that a server should forward in a privacy-
 preserving manner is over-reach. Not convinced we even know how to do that
 perfectly.

 On blocking: I don't understand - an adversary can block the server as
 easily as any delegate.

 On "refusing third party content", is that a thing? I can find no
 reference to it. Your browser is already required to connect to all sorts
 of domains you haven't requested, for CRLs, OCSP, DNS, updates, time... I
 don't think it is realistic to expect users to figure out what is and is
 not OK for these kinds of things.

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/130#comment:4>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Thu, 26 Nov 2015 15:37:56 -0000

I think requiring that '''if''' a server is forwarding SCT Feedback it
 '''must''' do it in a privacy-preserving manner that we will define,
 perfect or not.

 easily as any delegate.

 Blocking feedback in the same TLS session as the one where the ordinary
 request was carried out should be hard to do without collateral damage in
 form of the page that was requested (assuming it's hard to cut an existing
 session at the exact right time). To block feedback you'd have to block
 the page, something we hope will be too expensive.

 I expect users to be able to pick a browser that is less bad. Arguing that
 another third party is OK because there are others doesn't help.

 I guess a counter argument would be that explicit delegation is easier to
 detect and refuse.

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/130#comment:5>
trans <http://tools.ietf.org/trans/>