
Pervasive Monitoring Is an Attack - kallus
https://www.tbray.org/ongoing/When/201x/2014/05/13/Pervasive-Monitoring-is-an-Attack
======
discardorama
TFA says "PM is an attack ... and this is a consensus of the IETF". On the
other hand, IETF continues to employ NSA employees (like Kevin Igoe, a co-
chair of Crypto Research Group under IETF[1] ).

So: is it a consensus or not? Does Mr. Igoe consider PM an "attack", even
though his own employer does it?

I'm having trouble reconciling the two.

[1]
[http://article.gmane.org/gmane.ietf.irtf.cfrg/2337](http://article.gmane.org/gmane.ietf.irtf.cfrg/2337)

~~~
tptacek
The IETF considered replacing Igoe. No consensus was reached. People with lots
of IETF institutional credibility (ie: that had been instrumental in previous
standardization efforts, ones in which no tampering concerns were entertained
by anyone) strongly disagreed with his ouster.

Also, from a political perspective, the effort to replace Igoe was hamstrung
by the lack of anyone in the universe raising their hand and saying "I'm a
respected cryptographer AND I want to punch myself in the face continuously
for several years by chairing CFRG".

The less reverence the Internet has for the cryptographic wisdom of the IETF,
the better off I think we all are.

~~~
jchrisa
What do you think about IETF-JOSE? I've been using it as sort of a cookbook
for signing and encryption. They even have a cookbook:
[http://datatracker.ietf.org/doc/draft-ietf-jose-
cookbook/](http://datatracker.ietf.org/doc/draft-ietf-jose-cookbook/)

~~~
tptacek
JOSE includes JSON canonicalization, which scares the crap out of me. If I had
the choice, I'd treat JSON as binary --- a whitespace change would, for a
signed file, break the signature.

JOSE also includes RSA PKCS1v1.5 signatures, which are deprecated (you should
use RSA-PSS, which JOSE also documents).

It includes naive nondeterministic DSA, which should be deprecated in favor of
deterministic DSA or something like Ed25519.

It doesn't include details you actually want about curve selection. (Also,
P-521?!)

It includes encryption under RSA PKCS1v1.5 (encryption with v1.5 is even worse
than signing under it) and AES-CBC, which is disfavored by cryptographers.

(My understanding of JOSE is cursory, at best, so I wouldn't be surprised to
be corrected on any of these).

------
nknighthb
> _if your ap­pli­ca­tion doesn’t sup­port pri­va­cy, that’s prob­a­bly a bug
> in your ap­pli­ca­tion._

Amateur radio is explicitly _not_ for traffic that needs to remain private. It
exists for limited purposes not including routine communication that can be
served by other means (e.g. a phone or ordinary internet connection). It is
chiefly for education and research/experimentation in radio. It is not for
general personal communications or commercial use.

The applicable rule in the US[1] says:

 _" (a) No amateur station shall transmit: [...] messages encoded for the
purpose of obscuring their meaning"_

This serves to ensure the amateur radio service is not used in violation of
its rules and purpose.

The rule has exceptions elsewhere in the rules. For example, remote control of
satellites and model aircraft. And FCC rules as a whole pretty much go out the
window when transmissions are for the purpose of protecting the immediate
safety of life or property.

The rules are also susceptible of a particular interpretation: You can use
encryption, provided the algorithm is documented, and you keep a record of the
keys used. This has been used to block non-amateur access to WiFi access
points operating within the ordinary WiFi band, but under Part 97 rules (e.g.
non-FCC-approved equipment, or higher power than allowed for unlicensed
users).

The rule also does not in any way prevent use of authentication and message
integrity mechanisms, e.g. HMAC, because they are not intended to obscure the
meaning of the message, merely authenticate it.

If you need private communication, there are other avenues available than the
amateur radio service. And if you want greater freedom for unlicensed use of
the airwaves than now exists, you'll have my support in principle (there are
real problems with a free-for-all, but there are myriad ways FCC rules and
spectrum allocation practices could be greatly improved in this regard). But
this rule is not a bug, it is a deliberate feature of the amateur radio
service.

[1]
[http://www.gpo.gov/fdsys/pkg/CFR-2013-title47-vol5/xml/CFR-2...](http://www.gpo.gov/fdsys/pkg/CFR-2013-title47-vol5/xml/CFR-2013-title47-vol5-sec97-113.xml)

~~~
hafichuk
IANAL. The ham radio community needs to raise this with the FCC. This section
was originally constructed a long time ago (1993?). I'm guessing it's biased
this way to stop 1940's era spys from operating.

~~~
nullc
The regulations prohibit various forms of commercial use, e.g. preventing a
cab company from moving its dispatch onto the 2m ham band— a reasonable policy
since there is limited spectrum and commercial parties could easily overrun
it: but if the traffic is encrypted how is the community management supposed
to function?

Personally I'd like to see the regulations adopt special rules for highly
directional or low-power limited-range signals in the SHF+ bands where there
is plenty of spectrum which basically drops all the content rules beyond
requiring cleartext contact information. Without competition for spectrum the
balance of interests is different and it would be nice to be able to lawfully
backhaul community internet access over some chunks of spectrum up at 3cm.
Since no one would likely notice or care you could already use crypto in these
places, so it might as well be made permitted.

------
CapitalistCartr
" . . . the IETF is putting this stake in the ground in May of 2014." This
isn't much of a stake in the ground, but its a start.

So far, the disclosures have involved the NSA and GCHQ: intercepting hardware
and modifying it; strong-arming companies into "coöperating"; pushing
weaknesses known only to them into standards; and spending tens of billions to
copy most of the Internet and have server farms sort it.

None of that seems amenable to this RFC.

~~~
kbenson
To the contrary, I think forcing every proposal to at least confront pervasive
monitoring and how it may effect what is being proposed will force authors to
be more conscious of PM and security in general with regard to their
proposals. It's not the job of the IETF to stop monitoring, but it is their
job to make sure the cards are on the cable when putting forward a new RFC.

------
ryanobjc
This is a good formal step.

The time it took from 'common knowledge' to a formal proposal makes me a
little worried. If the IETF isn't really a "council of wise folks" then in the
long term, doesn't their effectiveness get eroded?

~~~
smtddr
_> >The time it took from 'common knowledge' to a formal proposal makes me a
little worried._

As anti-NSA, pro-snowden as I am _(I proudly wear my Snowden t-shirts)_... I
think it's important for formal steps to make sure they've filtered out the
hype and not just react while the general public is on fire about the issue.
Waiting about 6 months to a year after Snowden did his thing I think is fast
enough. Gives folks enough time to digest the info and for anyone else out
there thinking about "leaking" more info that _(dis)_ proves Snowden enough
time to weigh consequences 'n such. This way when formal steps begin to happen
nobody can complain that they didn't have enough time to respond/defend
themselves, etc. USGov has been given plenty of time to quell concerns and
haven't done a particularly good job so I feel that Snowden is mostly, if not
completely, correct and I can confidently consider the USGov/NSA as the real
villains in the world attempting to misdirect everyone else with allegations
of boogieman terrorists & spying from Russia/China/Nigeria/whatever.

Not that I ever believed otherwise... just that this gives me more talking
points in future debates with friends/family/random-online-comments.

~~~
ryanobjc
I guess I kind of expect the IETF to be predictive, and not be pop-culture or
mass-market/media driven.

I guess ultimately though, that's the only way to go. We knew years before
Snowden that something fishy was up, but it took the leaks to really make
people care at a level that could facilitate change.

~~~
jnbiche
>I guess I kind of expect the IETF to be predictive, and not be pop-culture or
mass-market/media driven.

But that's the GP's exact point: this _wasn 't_ a media-driven RFC -- if it
had been driven by media, it would have been published last summer. As it
stands now, the body has carefully deliberated on the facts and yet still
published a very strongly-worded RFC.

This pro-Snowden programmer is pretty happy to see the IETF step forward and
take on a leadership role here. Let's not forget that the IETF was founded by
a consortium of US government agencies and only when private in the 1990s.

With this RFC, they are asserting their independence in a surprisingly direct
manner (for a standards body).

------
leeoniya
adapting a quote from Office Space, every RFC shall ask, "Is this good for the
internet?"

------
skion
Curious if Analytics and Real User Monitoring (RUM) companies feel addressed
by this memo. And whether the IETF intended that or not.

