Subject: Re: [perpass] mandatory-to-implement vs. more?

From: Tony Rutkowski <[email-masked]>
Date: Mon, 21 Oct 2013 15:47:09 -0400

Hi Brian,

It's fair enough to stay out of the jurisdictional legal construct arena. Most bodies do.

However, "privacy" is also a jurisdictional legal construct.  Indeed, some instantiations of "privacy" - especially as manifested under the perpass rubric - are plainly anti-government (if not anti-business)
in nature.  The aim is to harm legitimate interests of law enforcement.  In so doing, 2408 is being contravened by swinging the ideological pendulum toward a rather extreme perspective.  Indeed, alternative views seem plainly not welcome.

The IETF as a body is denigrated by venturing into these kinds of religious exercises.  It should neutral in these matters.

On the other hand, as someone who participates in dozens of different standards venues, it's better the wackiness on this subject stay in perpass!

--tony

Brian E Carpenter <[email-masked]> wrote:

>Tony,
>
>On 21/10/2013 23:14, Tony Rutkowski wrote:
>> Hi Eliot,
>> 
>> Apropos to your suggestion...
>> 
>> What about MTnI (mandatory to not implement) or MTB (mandatory to break)? Public networks and services have been subject to governmental controls on encryption by every country in international law since 1850. Individuals and small groups may be able to skirt the requirements, but not commercial or institutional providers. Seems like a bit of a scaling challenge?
>> 
>
>I believe that is *exactly* why the IETF endorsed both RFC 1984 and
>RFC 2804. It's *our* job to make our specs as secure as reasonably
>possible and to not help make them liable to eavesdropping. If that
>makes signals intelligence agencies unhappy, or presents implementors
>with a conflict between an IETF "MUST" and a jurisdictional "MUST NOT",
>that isn't our concern.
>
>Here, I believe we should focus only on specifications that enhance
>privacy, and IMHO that certainly includes specifying that implementations
>must have strong privacy-protecting default configurations.
>
>    Brian