Re: [TLS] RFC4492bis - Removing ECDH

[Michael Clark <[e-mail]>]

Hi Yoav,

On 8/1/15 12:42 pm, Yoav Nir wrote:
> My understanding is the DH-RSA and ECDH-(RSA|ECDSA) are practically unused and that implementations use DHE-RSA and ECDHE-(RSA|ECDSA). ECDH requires the CA to embed static named or explicit points in certificates. The practice is that implementations let server administrators choose and /sign/ *somewhat* ephemeral parameters e.g. secp256r1,  secp384r1 works widely, but secp521r1 failed in my tests with Win8.1 IE11; this report matches my data point: (*3). I use the word /sign/ loosely until we have a proof that handshake messages can't be replaced in situ (*4). i.e. the client and server establish a chain of trust from their first Hellos to the pre-master secret establishment; which is possible with careful refinements to the protocol (constant salt in AD across all handshake messages). This of course then pushes an integrity problem down to another layer. i.e. DNSSEC (*5).
> #4 is a TLS proxy. And it does get noticed, because you don’t trust Gogo’s CA, so it’s not so great as an attack. I do wonder why they would apply it to Youtube of all services. Filter out video clips with crashing planes?

I watched "Non-Stop" on an Singapore Airlines flight from New Zealand to
Singapore in late-October, and at the same time noticed the plane
altered course at Darwin, and instead of flying direct, flew over East
Timor towards West Kalimantan (Borneo), completely avoiding the Java
sea. Coincidence. Likely planning. "Weather". An AirAsia plane however
sadly flew straight through the Java Sea during monsoon season. They had
requested for new flight path and were denied due to heavy air traffic;
so they flew on straight through a storm. My partner and I were boarding
an A320 to Bangkok to Singapore 2 days after on Dec 30.

    http://www.rottentomatoes.com/m/non_stop_2013/

"Non-Stop" was about an Air Marshall who was trying to trace an unknown
device on the plane sending him hijack threat messages, now they have
WiFI and GSM... The reality is anyone serious would be using LoFi.
"Non-Stop" is fiction. There is no need for MiFi. It human nature that
people are angry when they are denied security (physical or ephemeral).

I can separate fact from fiction. Rotten Tomatos gave it the thumbs. It
was an okay movie however I think I liked it more because I was watching
it on a plane.

I am aware in the case where the CA is not in the trust store; and this
is noticeable to the user, and there are techniques such as public key
pinning in HTTP headers (which relies on establishing the first
connection on a trusted network as a proxy could easily re-write the
pins). The security needs to go down to the next layer. I still believe
there is a rationale to (not in spite of RSA and other digital signature
algorithms, rather to enhance them), make the client software aware, not
just the user in the case of certificate tampering. Otherwise the
browser needs a database. The policy could be that the client can
indicate to the user that the handshake has been tampered and an
implementation chose to accept invalid tags however I suspect it might
be a slippery slope towards tamper free TLS handshakes. i.e. net
neutrality. packets that arrive as they were sent. Someone will like
derive a closed user group derivation of TLS once they are aware of
this, if this kind of strategy is not adopted (assuming it is possible).

I am still reasoning about adding HMAC on handshake messages with
constant (client|server)_random as AD in all handshake messages
(HMAC_SHA2_𝑛). My reasoning probably has flaws or this would have been
solved. The MAC from the ClientHello MAC from the client may need to be
signed by the cert and returned in the Finished message from the server.
We have to distinguish between the HMACs that are *sent* not *seen* and
perhaps use the *sent* in key derivation or tamper detection. This
allows the browser to know at the TLS level (versus via the trust store)
that the handshake was modified "in flight" (no pun intended). The
browser developers and therefor the user can distinguish and take
appropriate action. There is a distinction between untrusted cert and a
tampered handshake that isn't currently exposed to the TLS client.

I'm thinking of the rewriting case and reasoning about it... The client
knows the MAC of it's ClientHello so it may need to be included in the
Finished message signed by the servers certificate (and a MITM would
need to change it). The server *sees* the MAC of the ClientHello it
receives, not necessarily the one that was sent. It's almost like an
HMAC of the handshake messages (from both sides as they were *sent*)
needs to contribute to the pre-master secret, and each side knows what
they sent. The tamperer would need to HMAC his tampered message. I will
think some more about it... My thinking may have flaws...

>> It raises another question. Is DH_anon a misnomer? Should it be DHE_anon? Is it used anywhere in practice?
> It is a misnomer. It is not used on the web, but it is used in some situations. For example, my company’s firewalls use it to establish the initial trust between a firewall and the management station. They will establish a TLS connection with DH_anon (should be DHE_anon, I guess), and then run certificate enrollment over that.

Forward progress. It probably wasn't incorrect at the time until there
was context for the distinction.

Michael.