Hello all, On Fri, Mar 27, 2015 at 9:43 PM, Tao Effect <[email protected]> wrote:
> (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. > > I suspect that a smart enough attacker will be able to send native certificates back to server instead of the ones he sent to client. Or am I missing something? Thank you! > > 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 <[email protected]> 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 <[email protected]> wrote: > > On 26 March 2015 at 15:45, Greg <[email protected]> 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 > [email protected] > http://www.metzdowd.com/mailman/listinfo/cryptography > > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > > > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > > -- SY, Dmitry Belyavsky
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
