Dean Willis | 18 Apr 23:23 2011

Re: [ietf-privacy] wrt tcpcrypt and obscrypt


On Apr 13, 2011, at 3:59 AM, bmanning <at> vacation.karoshi.com wrote:

On Tue, Apr 12, 2011 at 11:58:14PM -0500, Dean Willis wrote:

On Apr 12, 2011, at 12:16 PM, bmanning <at> vacation.karoshi.com wrote:


I don't think it is a trivial matter to have the IETF working on confidentiality & privacy by mandating strong
encryption in Internet (global) standards.  I suspect the intersection of national laws and  technical standards
is going to be a difficult road to walk, esp if there is a desire for a global standard.


We should perhaps focus on publishing technically correct standards with as few security flaws and weaknesses as we can manage. Trying to decide whether the specification can be legally implemented in Jurisdiction X, Y, Z, and so on is an impossibly large problem.

no problem with that... however - at least in the US and as a US national, I don't think I can
(with out filing forms and getting permission -ahead- of time) work on confidentiality/privacy,
techniques in an open forum.  and I am pretty sure that other sovreigns have the same issues.

Sue you can. You just can't export executable code for a certain subset of applications without prior EAR approval. I'm not a lawyer, but I have coordinated export for a company that was shipping SIP proxies with TLS support for signaling. Actually, it was more like cleaning up the situation for a company that had been accidentally exporting such function without having done all the needed paperwork, but it's clearly doable.

Even in the US, a fairly broad range of applications in unrestricted. This includes a cryptographic applications that do not have generic data-object encryption as their primary function, including crypto for copy protection, digital rights restriction, and arguably (having argued this with apparent success for SIP/TLS) protection of signaling to/from a service platform.

Even exporting products containing the code for general purpose encryption of the sorts used in most IETF specs is a fairly straightforward reporting exercise. If it weren't, you wouldn't see anybody running an Apache web server, and you wouldn't be able to download the J2EE SDK from Oracle//Sun/whatever owns it today.

Yes, Phil Z may have been arrested over PGP, but that was arguably as much an intellectual-property snit with RSA as it was an export control issue. And as you may recall, the case eventually faded away, though things were a bit tense for awhile.



its not just the code, its illegal to share work on some of these topics in some venues.
this is a topic that -REALLY- needs to have the ISOC/IETF legal team look at closely before
we engineers go off half-cocked and get ourselves, our employers, and the IETF into international
legal trouble.

The IETF has quite effectively published dozens of RFCs for SSL, TLS, PKIX, DTLS, SRTP/DTLS, and now ZRTP. We've also published lots of higher-level specs that reference these at  a "MUST implement" level. It's been looked at fairly closely. It seems unlikely that we'd be faulted for  pushing the specs a little further to add "MUST NOT implement a null cipher" requirement.

So, Kanuckistan or other locales might restrain their citizens from participation. They probably don't let them leave the country to attend IETF meetings either, so who cares what their rules are? We're not going to force them to develop the capacity to engage in international business; if a nation really wants to be a stagnant backwater with a starving citizenry and intellectually inbred leadership they can just choose not to play along. 


--
Dean


_______________________________________________
obscurity-interest mailing list
obscurity-interest <at> ietf.org
https://www.ietf.org/mailman/listinfo/obscurity-interest
Dean Willis | 13 Apr 06:58 2011

Re: [ietf-privacy] wrt tcpcrypt and obscrypt


On Apr 12, 2011, at 12:16 PM, bmanning <at> vacation.karoshi.com wrote:


I don't think it is a trivial matter to have the IETF working on confidentiality & privacy by mandating strong
encryption in Internet (global) standards.  I suspect the intersection of national laws and  technical standards
is going to be a difficult road to walk, esp if there is a desire for a global standard.


We should perhaps focus on publishing technically correct standards with as few security flaws and weaknesses as we can manage. Trying to decide whether the specification can be legally implemented in Jurisdiction X, Y, Z, and so on is an impossibly large problem.

In fact, it's possible to have conflicting legal imperatives: for example, European laws on privacy protection might well conflict with Asian or North American laws on interceptibility. I'm expecting IMAP/SSL and SMTP/TLS to become illegal in India any day now, at least when used between mobiles within the country and servers outside the country. But I don't think we'll respond by deprecating either specification. If India wants to ban VPNs, they can do that too. But at least the users will know that their privacy is at-risk and economic pressures can be brought (what multinational would put up with this?) to end the ban.

But if we deliberately design security weaknesses into protocols (or continue to tolerate and maintain known problems for which we have a solution), we're arguably negligently responsible for a whole lot of problems.

--
Dean Willis

_______________________________________________
obscurity-interest mailing list
obscurity-interest <at> ietf.org
https://www.ietf.org/mailman/listinfo/obscurity-interest
=JeffH | 30 Mar 19:49 2011

wrt tcpcrypt and obscrypt

 > 1) We should try to drive the widespread use of encryption.This makes
 > encrypted real-time channels (and other things that benefit from security)
 > stand out less than they otherwise might. The general principle is that good
 > network citizens, along with sharing the net gracefully, should help their
 > neighbors hide from attacks.
 >
 > Along these lines, we'd like to encourage the IETF to NOT develop more
 > protocols with encrypted and unencrypted variants. Unless protocols NEED to
 > be unencyypted, they need to be protected. We should also encourage
 > deprecation of the current unencrypted variants.
 >
 >
 > everybody should look at the "tcpcrypt" draft. This has the potential to
 > opportunistically encrypt applications using TCP and nicely augments TCP
 > applications.It might be possible to do somethi'ng similar to do something
 > similsr for UDP.

In terms of the latter, I believe you mean..

draft-bittau-tcp-crypt-00

see also: http://tcpcrypt.org/

I've played with the impl on linux and it apparently worked. ( I left comment 
#46 here: http://tcpcrypt.org/fame.php )

there's also this similar work to take a look at..

Opportunistic Encryption Everywhere - Adam Langley
http://w2spconf.com/2009/papers/s1p2.pdf

https://secure.wikimedia.org/wikipedia/en/wiki/Obfuscated_TCP

AdamL brought his stuff up on the tcp list (not sure offhand of exact list 
moniker) and it got shot down (so he felt, but he didn't try for more than just 
3 days to get acceptance... :)

HTH,

=JeffH
Dean Willis | 29 Mar 17:48 2011

report on face-to-face 28 MAR 2011


Marc, Michael, Martin and I had dinner last night. We met up with Phillip later, and also chatted some with Hannes.

We seem to have consensus on a few points:

1) We should try to drive the widespread use of encryption.This makes encrypted real-time channels (and other things that benefit from security) stand out less than they otherwise might. The general principle is that good network citizens, along with sharing the net gracefully, should help their neighbors hide from attacks.

Along these lines, we'd like to encourage the IETF to NOT develop more protocols with encrypted and unencrypted variants. Unless protocols NEED to be unencyypted, they need to be protected. We should also encourage deprecation of the current unencrypted variants.


everybody should look at the "tcpcrypt" draft. This has the potential to opportunistically encrypt applications using TCP and nicely augments TCP applications.It might be possible to do somethi'ng similar to do something similsr for UDP.

2) The ietf-privacy list is a good forum for much of the discussion, and we should participate there.


3) We feel a need for more tactical near-term action. We don't know what yet. More discussion would be helpful.


There might be an opportunity to do SIP over RELOAD that we should look at.

--
Dean
_______________________________________________
obscurity-interest mailing list
obscurity-interest <at> ietf.org
https://www.ietf.org/mailman/listinfo/obscurity-interest
Marc Petit-Huguenin | 28 Mar 12:49 2011
Picon

Paul Baran (April 29, 1926 – March 26, 2011)

I just discovered that Paul Baran died last Saturday.

I think that his work about networks resistant to nuclear attacks could be 
relevant to this mailing-list, as such a network would also be resistant to 
dictators and censorship.   I have a copy of "On Distributed Communications" 
that I meant to read for some time.  Will definitively go on the top of the 
reading list.

--

-- 
Marc Petit-Huguenin
Personal email: marc <at> petit-huguenin.org
Professional email: petithug <at> acm.org
Blog: http://blog.marc.petit-huguenin.org
Dean Willis | 28 Mar 09:35 2011

Re: When & Where is the BarBOF?

Mondsy post-plenary in Hilton bar. We may decide on an offsite outing later.

On Mar 27, 2011 5:29 PM, "Hannes Tschofenig" <hannes.tschofenig <at> gmx.net> wrote:
>
> _______________________________________________
> obscurity-interest mailing list
> obscurity-interest <at> ietf.org
> https://www.ietf.org/mailman/listinfo/obscurity-interest
_______________________________________________
obscurity-interest mailing list
obscurity-interest <at> ietf.org
https://www.ietf.org/mailman/listinfo/obscurity-interest
Marc Petit-Huguenin | 24 Mar 19:30 2011
Picon

Contact Summit 2011

Relevant, I think:

http://contactcon.com/

--

-- 
Marc Petit-Huguenin
Personal email: marc <at> petit-huguenin.org
Professional email: petithug <at> acm.org
Blog: http://blog.marc.petit-huguenin.org
Dean Willis | 24 Mar 01:05 2011

Another example: Protest, protest...

This article from the New York Times seems to claim that calls are being real-time tapped for keyword recognition and dropped if one repeats the wrong word:

http://www.nytimes.com/2011/03/22/world/asia/22china.html?_r=1


While it sounds scary, I don't actually believe it's currently deployable on a mass scale. But it's the type of scenario that could become plausible if we don't get our security acts together.

The NY Times article is linked from the Huffington Post, if that's easier for you to follow (for some reason, coming in from HP skipped me past the Time's paywall.)


Thanks, Geoff!

--
Dean

_______________________________________________
obscurity-interest mailing list
obscurity-interest <at> ietf.org
https://www.ietf.org/mailman/listinfo/obscurity-interest
Dean Willis | 22 Mar 06:08 2011

GNU Free Call

Not obscure, but at least slightly opaque:

http://planet.gnu.org/gnutelephony/?p=14

Question: What could be done to reduce the "stand out", or "obviousness" of a SIPWitch node?

--
Dean

Gmane