Re: SSL/TLS everywhere fail

--------
In message <CAFggDF21JqbKnnFcOr0=XicpiuoNfQAz1n6-Dhs_1nAVHAWHHQ@mail.gmail.com>
, Jacob Appelbaum writes:

>I think we may disagree about meta-data vs content and how we want
>surveillance by unauthorized third parties to actually be conducted.

So since I'm waiting for a huge compile anyway...

I'm not a card-carrying historian, but here is my attempt to
contextualize government, privacy and secrecy:

Historically, people have been accutely aware of the difference
between keeping the metadata and the message secret.

Historically it has also been very hard to keep the metadata secret,
because metadata is essentially that communication is happening.

In classic art and literature, you will find thousands of references
to rulers and fathers receiving metadata:

   A courier was seen leave.

   Lights were being flashed.

   Letters were being sent.

   Telegrams were sent.

   Somebodys private secretary had left town.

   Somebody sent his son to the pope.

   The daughters maid has started gossiping with the young swains waiter.

   &c &c &c

More rare, but far from seldom, somebody take great pains to conceal
both message and metadata:  Carefully planned message paths through
unexeptional encounters, leaving in the dark of night, trusting
outsiders to carry messages etc. etc.

In all of this, protection and discovery of the metadata, that
communication is happening and with whom is being communicated, is
treated distinct and separate from the protection and discovery
of the actual message.

Indeed, it is more often than not the case that the actual message
is inferred with high precision, from the metadata.  After all,
there is only so many things a young man has to say to a young
woman, or a threatend ruler to the pope.

Integrity is a big issue and very often much greater effort and
creativity was expended on means to ensure it than on secrecy of
the actual message:  Sigils in laquer, leather, paper, and cloth.
Many interesting variations of torn money, swearing on bibles,
graves, honours etc. etc.


This leads me to the following observations for our current
times:

1)  If you *really* have something to hide, you should focus on
    protecting your metadata.

    Nobody needs to brute-force your session-keys to know what's
    going on if they know you had a two hour midnight web-session
    with 'aids-advice.example.com'
    
2)  In most cases the actual message does not need absolute or
    even any secrecy.  If I browse a major news-site, there is
    very little incremental information leakage in knowing which
    particular articles I read.

3)  Where secrecy is required, my web-commerce and banking as an
    example, we do so mostly to protect against simple crime.

    It is worth remembering that a simple paper envelope and modestly
    tamper-proof mail-boxes protected almost all the worlds
    commercial communication for the last 500 years.

4)  Integrity an authentication are much more important than secrecy,
    in both theory and praxis, but often treated as a side-effect
    of cryptography, rather than the goal of it.

5)  There are rare but legitimate reasons to demask communication,
    and in civilized societies we have carefully allowed for this
    and designed checks & balances to prevent abuse of this power.


If I project thos observation onto the HTTP-space, I get the following:

1)  If it *really* matters Tor is probably the _weakest_ facility
    you can and should use, and even the fact that you use HTTP
    should not leak through your protection.

    In other words:  The protection you use should be good enough
    that you could trust it with your plaintext, so this usecase
    does not impose any requirements on HTTP or any other "carried
    protocol"

2)  HTTP should offer Integrity separate from secrecy.  If nothing
    else to deter simple crime and for reasons of performance and
    caching.

3)  If the metadata, the fact that HTTP traffic is happening between
    two IP numbers, is not protected, attempting to protect the
    HTTP envelope and headers does not incrementally increase privacy
    enough for the downsides of doing it.

    The converse, moving the HTTP envelope and headers to the
    metadata column, (as the discusse draft could) can gain us a
    lot of valuable advantages in both efficiency and actual privacy.

    Most notably a lot of current MiTM proxies only want that
    metadata:  Who communciated with who ?  And a lot of them are
    in tricky legal positions if they get anywhere near the actual
    message content.

    Making it easier for law-regulated MiTM to only collect only the
    metadata they need, will therefore increase privacy, rather
    than decrease it.
    
4)  From a optimization and political point of view, we should only
    protect as well as necessary.

    Overprotecting is waste of resources.

    Politically over-protection causes over-breakage.

    If we over-protect, the easiest way to handle the legally
    mandated de-masking is to de-mask everything and sift the
    plaintext.

    If we protect the message only inside the metadata, only
    the targeted messages need to be de-masked.


And therefore TLS-everywhere falls down:

1)  It doesn't protect the most important metadata.

2)  About the only positive thing is that it does offer integrity
    (Provided you trust the CA-protection-racket)

3)  It pointlessly protects secondary metadata, which makes
    communication slower and more costly, without improving privacy.

    In the special case of legally regulated MiTM this even causes
    loss of privacy.

4)  It wastes computing resources[1] and it makes it cheaper for
    governments to break open all communication, and having broken
    it, it would obviously be a waste of resources to not collect it.


Feel free to use this text in any future ID's on the topic.

Poul-Henning

[1] We only have 10 years to get rid of fossil fuels now, every bit helps.
    
-- 
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 Sunday, 6 December 2015 10:58:53 UTC