Re: SSL/TLS everywhere fail

--------
In message <245746A1-A574-4D19-A8AA-8AC5270D0D8F@lukasa.co.uk>, Cory Benfield w
rites:

>Poul-Henning, you and I agree on very little (which is fine, 
>disagreement is healthy), but I think we agree that the TLS-everywhere 
>policy pressured the Kazakh government to make this move. I personally 
>believe they'd have done this eventually *anyway*, and we 
>definitely disagree on whether TLS-everywhere is a good idea in the face 
>of this move, but we can agree on that point.

My point is that TLS anywhere made this *possible* for them.

MiTM of TLS is a COTS product.

If instead of rushing head-first into "TLS everywhere!!!!!" reactive
posture without a minimum of strategic planning, people had spent
a moment thinking forward, they would have realized that TLS
everywhere makes it *easier* to disable privacy in total, because
the entire infrastructure and *market* is already in place[1].

The correct response would have been to roll out more or less
*exactly* what the encryption draft contains, along with a wide
number of diverse key-management schedules.

That way the Kazakh government, no matter how much they desired it,
would not be able to do a MiTM on their entire country, because they
would not be able to get any tool from anywhere to implement it.

Their political choice would then be reduced to:

   A) Pass traffic, collecting only the "envelope",

or

   B) Block all traffic that cannot be inspected.

Even in Kazakstan B) would be politically suicide, so the result would
*at worst* be A).

A) Would have been a *much* better situation than what is now happening.

Now that they *have* implemented total MiTM, we fight the uphill
battle where they can (and probably will) block any other kind of
encrypted traffic than TLS, so rolling out our stronger weapon just
got impossble.

TLS-everywhere has played right into the hands of the "Crypto must
have back-doors" crowd.


>However, I want to point out that *this working group* has, to my 
>knowledge, never enacted any requirement that could be referred to as 
>mandating, or even particularly encouraging, TLS-everywhere.

So it wasn't committed to an RFC ?  Big deal.

I'm sorry, but the cheering was deafening, so don't come now and
claim that the people in this WG was neutral bystanders not taking
a position.

>As I understand it, your objection is not with *this working group*,

My objection is with naïve nerds who think that quick technical
hacks can solve heavy-duty political problems.

This WG has a solid majority from that camp, even if they never
wrote this one particular stupid decision into a RFC, but only
implemented it in their software.

>Given that, as far as I can see what you want from this WG is not to 
>stop specifying that TLS must be used everywhere, but to start 
>specifying that implementations MUST support plaintext versions of all 
>protocols they implement.

What I've been telling this group, is the exact same thing I have
been preaching everywhere else:

If you want to fight for your right to privacy, you shouldn't bring
a knife to a gunfight, you should get elected to your nearest
relevant legislature.

You may be able to enact RFCs, the people you are fighting can
enact laws, which police, courts and worst case military force
will back up.

While you work on the political side, you should certainly *also*
make sure that we can have "proportional response" in the technical
battle.

Doing that, we *might* have a chance of victory[2].

>If you want to avoid TLS-everywhere being "shoved down" everyone's
> throat, rather than posting emails that prove how wonderful you are at 
>predicting changes in government policy, you should continue to use your 
>influential voice when new drafts are discussed to ensure that they do 
>not further contribute to the problems you are concerned about.

You may not know this:  I make my living as a one man company writing
software.  I have no customers I can bill for IETF work and much
less can I afford to travel to IETF meetings, even if I wanted to
in the first place.

And yet I sit here at midnight, after a workday which started 16
hours and 800km away, answering your email.

And by the way:  The HTTP workshop was half of my summer-vacation this year.

So for the sake of my blood-pressure, I would *really* appreciate
if you will stop telling me how I should spend my time.

>What is *not* helping is about 50% of this thread, which consists of 
>grandstanding and empty rhetoric. 

If you consider this "empty rhetoric", then I probably have nothing
to contribute that you would consider germane.

I will point out though, that amongst my "empty rhetoric" was an
attempt to prevent HTTP/2 from just goldplating SPDY:

 http://phk.freebsd.dk/words/httpbis.html

I was told by several people that I didn't even need to bother
posting that as ID because it was a foregone conclusion that
HTTP/2 would be based on SPDY.

Despite that, I also worked with a group of other people to try to
come up with a protocol draft in the unreasonably short timeslot
which basically only allowed the SPDY people to make it.

And finally, I've been trying my damnest to to raise awareness
in any context I've had the chance, including one of the most
watched and talked about closing keynotes in FOSDEM history[4]:

  https://www.youtube.com/watch?v=fwcl17Q0bpk

So yes, I'm full of "empty rhetoric" in an attempt to raise
the ground-swell we will need if we want to have a chance to
fight for a right to privacy.

If you think a well-written ID is a better way, be my guest.

Now get off my lawn...

Poul-Henning


[1] IHTSITYSBITYS

[2] I've never rated that chance particularly high, because I do not
    see young people being upset about the lack of privacy[3]

[3] If the 20-29 year old women do not go to bat for your cause, your
    chances of winning are non-existent base on the historical record.

[4] See also: https://twitter.com/csoghoian/status/672457784663781379

    
-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Saturday, 5 December 2015 00:11:30 UTC