Quote from: Mike Hearn on October 22, 2013, 03:24:49 PM

The interlock protocol does not do what the proposer thinks it does. Read the wikipedia page on it. It's a neat idea but it does not provide authentication. If there's a MITM sitting between you and the merchant, that MITM can rewrite traffic at will.

I'm the "proposer" and I know exactly what the interlock protocol does. It flatly prevents a MITM from altering your communications with someone else while allowing you to communicate at all. That is what I said, and that is what it does.

The MITM has to make an immediate choice when faced with Diffie-Hellman over Interlock Protocol. He can either try to impersonate one or both sides of the conversation completely (refusing to allow you to communicate at all) or he can allow you to communicate, whereby he immediately loses the ability to eavesdrop on or interfere with your communication at all except by cutting it off.

Good protocol for secured channels works like this:

1) All Protocol negotiation via Interlock protocol to ensure that you are talking to exactly one endpoint (which may be an MITM, but if so will definitely *not* be communications from your intended endpoint as altered by an MITM).

2) Diffie-Hellman Key exchange via Interlock Protocol to establish a private key (thereby cutting out potential eavesdroppers).

3) Authentication via shared secret to make sure that the endpoint you are talking to is in fact the endpoint you want to be talking to, ie, not the MITM.

Protocol security (steps one and two) secures the channel. Authentication (step 3) is not addressed by securing the channel; it is addressed by a shared secret. It might also be addressed by 509 certificates to the extent that people trust them.

What I said about SSL is that we ought not rely solely on the keys in those certs for securing the channel. SSL is a hybrid monster that conflates securing the channel with authentication, and they are two separate jobs.

SSL, trusted third parties and all, is a better method than any zero-trust protocol for authentication between strangers. Knowledge of the private key corresponding to the public key in an SSL certificate is not quite as good as a shared secret due to CA trust issues, but by definition you can't have a shared secret with a stranger, and it's a pretty good proxy for knowledge of a shared secret. We can use it for that, and I'll have no objections.

But using SSL to secure the channel (ie, trusting the keys in those certs _and_nothing_else_ to prevent eavesdropping or alteration of messages in flight) is a method inferior to zero-trust protocols, and I *will* be upset if using SSL authentication reduces us to using SSL to secure the channel.