[Trans] Question regarding new gossip protocols [Was: Certificate transparency on blockchains]

[Tao Effect <[e-mail]>]

(Changed the thread's subject title to reduce likelihood this question was missed:)

The document does say that clients MUST send the certificate chain back to servers, and that's good, because if that's the case, shouldn't that be enough on its own for servers to detect that a MITM attack occurred (after the MITM leaves)?

If that is so, it seems like a point worth highlighting in the document. It would completely address our concerns about CT's ability to detect MITM attacks post-facto.

Thanks,
Greg

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

On Mar 27, 2015, at 12:12 AM, Tao Effect <[e-mail]> wrote:

> (re-sending from the email I use with [trans].)
> 
> Thanks Tom for the very helpful reply.
> 
> Thinking this through a bit more, I remember again something that was previously discussed about this technique.
> 
> The document does say that clients MUST send the certificate chain back to servers, and that's good, because if that's the case, shouldn't that be enough on its own for servers to detect that a MITM attack occurred (after the MITM leaves)?
> 
> If that is so, it seems like a point worth highlighting in the document. It would completely address our concerns about CT's ability to detect MITM attacks post-facto.
> 
> Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing with the NSA.
> 
> --
> Please do not email me anything that you are not comfortable also sharing with the NSA.
> 
> On Mar 26, 2015, at 6:18 PM, Tom Ritter <[e-mail]> wrote:
> 
>> On 26 March 2015 at 15:45, Greg <[e-mail]> wrote:
>>> Reading over it, I still have several concerns, which I will voice here but
>>> let me know if it would be better to also voice them on [trans].
>> 
>> It would be better to voice them on trans, which I am copying.  I
>> suggest we move it there for follow-ups.
>> 
>> 
>>> In Section 3.1.1, it says:
>>> 
>>> <begin>
>>> 
>>> HTTPS servers MUST perform a number of sanity checks on SCTs from
>>>   clients before storing them:
>>> 
>>>   1.  if a bit-wise compare of the SCT matches one already in the
>>>       store, discard
>>> 
>>>   2.  if the SCT can't be verified to be a valid SCT for the
>>>       accompanying leaf cert, issued by a known log, discard
>>> 
>>>   3.  if the leaf cert is not for a domain that the server is
>>>       authoritative for, discard
>>> 
>>>   Check number 1 is a pure optimisation.  Check number 2 is to prevent
>>>   spamming and attacks where an adversary can fill up the store prior
>>>   to attacking a client.  Check number 3 is to help misbehaving clients
>>>   from leaking what sites they visit.
>>> 
>>> </end>
>>> 
>>> Concern #1: Discarding invalid SCTs
>>> ============================
>>> 
>>> It is not clear to me what's going on in (2) above.
>>> 
>>> Specifically:
>>> 
>>> - How is the server verifying the SCT for validity?
>> 
>> 
>> It checks if the signature over the data is valid.
>> 
>> 
>>> - Why is the server discarding the SCT if it is invalid?
>>> 
>>> Wouldn't discarding an invalid SCT totally undermine the point of clients
>>> sharing them?
>> 
>> 
>> Keeping data for an invalid signature (or a signature for a log which
>> I do not recognize and thus don't have the public key) would allow
>> clients to store arbitrary data on your server. Complex rate-limiting
>> and DoS concerns now apply.
>> 
>> 
>> 
>>> Concern #2: The use of the word SHOULD
>>> =================================
>>> 
>>> The doc states:
>>> 
>>> (with ref to server => auditor comms):
>>> <begin>
>>> 
>>> HTTPS servers SHOULD share all SCTs and certificate data they see
>>>   that pass the checks above
>>> 
>>> </end>
>>> 
>>> <begin>
>>> 
>>> Auditors SHOULD provide the following URL accepting HTTPS POSTing of
>>>   SCT feedback data:
>>> 
>>> </end>
>>> 
>>> <begin>
>>> 
>>> Auditors SHOULD regularly poll HTTPS servers at the well-known sct-
>>>   feedback URL.  How to determine which domains to poll is outside the
>>>   scope of this document
>>> 
>>> 
>>> </end>
>>> 
>>> 
>>> As per RFC2119, "SHOULD" means the advice is free to be ignored after the
>>> implications are "carefully weighed".
>>> 
>>> This means that so far the document provides no guarantees that a
>>> misbehaving log will be caught.
>> 
>> 
>> Yup. We can't force anyone to participate unfortunately.  A client
>> _can_ opt-in to using a trusted auditor and send SCTs to them, which
>> then mitigates the concerns over a server not participating.  But I
>> will note that if a server does not participate they are essentially
>> opening themselves to attacks by logs. So they have an incentive to
>> participate.
>> 
>> 
>>> It is also disconcerting that instead of taking direct action themselves,
>> 
>> 
>> There is nothing stopping a server from being an auditor and detecting
>> log misbehavior.  I suppose we could add a note in the draft to that
>> effect, but it's a pretty weighty option I imagine most people will
>> not pursue.
>> 
>> 
>>> servers are supposed to initiate yet another HTTPS connection to an auditor.
>> 
>> 
>> (nit: Server can instead just make the SCTs available for auditors to
>> query and retrieve from them. Server doesn't have to initiate outbound
>> requests.)
>> 
>> 
>>> This is cumbersome and will probably leave open holes for a global MITM to
>>> prevent SCTs from reaching auditors, yet again undermining the entire point
>>> of sharing SCTs.
>> 
>> 
>> Yes, an attacker who can persistently isolate a client or server from
>> the rest of the internet is powerful, and is difficult to defeat. We
>> do not defend against such an attacker. I'm open to suggestions here,
>> but none really came to me.
>> 
>> 
>>> While it's definitely a positive sign that the sharing of SCTs and
>>> certificate chains is now an official recommendation, I am concerned that
>>> the particular implementation is without any teeth to deliver concrete
>>> results, and so until these concerns are addressed I am not convinced that
>>> the problem has been fully addressed.
>> 
>> 
>> That's fair.  There are limitations to the draft, to be sure - but
>> balancing the very difficult privacy concerns of literally
>> broadcasting the websites you've visited is also important.
>> 
>> 
>> -tom
>> _______________________________________________
>> The cryptography mailing list
>> [e-mail]
>> http://www.metzdowd.com/mailman/listinfo/cryptography
> 
> _______________________________________________
> Trans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans