Re: [Twisted-Python] AutobahnPython 0.6.3 - WebSocket compression and more

[Tobias Oberstein]

>>>So in practice, I _have_ to use a CA that is built into all major browsers.

>>You're assuming a lot here.  Perhaps TLS is broken for all the uses you're 
>>interested in - that doesn't mean it's broken for everyone else's uses.

@Jean-Paul: Granted .. good catch.

My interest is the Web/browser, and also non-browser clients working in a 
Web-compatible way.

>Tobias, all of the things you've said here about browser UI, enterprise 
>networks, and key management tooling are true; however, note that none of 
>those nouns are "TLS".

@Glyph:

I agree: "browser UI" is formally unrelated to TLS
I (mostly) agree: locked down enterprise networks are orthogonal to TLS - 
formally.

And the "key management" system being ortho to TLS: a very good point.

The problem is X.509, and TLS today uses only that, but it is capable of using 
different schemes in principle.

I did some further looking around: turns out there is TLS-PGP

http://tools.ietf.org/html/rfc6091

Does someone know whether OpenSSL supports that?

[Sidenote: if not, one more reason why a pure Python TLS implementation (then 
with RFC6091) would rock. The other reason being the total awesomeness of the 
OpenSSL codebase;) And the third: PyPy.]

> 1. Write some code that uses TLS (which is a wire protocol, after all, not a 
>trust model or set of trust roots, nor a key management UI) and addresses 
>these issues, by implementing a new trust model, protocol for exchanging trust 
>roots, or key management UI, and selecting appropriate ciphers.
> 2. Write some code that uses a brand new wire protocol with unknown, 
>unaudited security properties, also implementing appropriate ciphers, and also 
>implementing all of the things in point 1.

>One of these options seems obviously superior to me :-).

Yeah;) 

1) => RFC6091

>>*This* is probably now sufficiently off-topic, though...

>Man, are there some kind of Topic Police everyone is worried about? Do I need 
>to start taking extra precautions when I write to mailing lists? :-)

Got it. It's just that different communities have different social codes.
But it's good that Twisted has no "Topic Police".
I like that .. term and fact;)

>I think this is on-topic enough, since this might inform TLS work with Twisted 
>in the future, and Vertex has been brought under the Twisted umbrella 
>recently, https://github.com/twisted/vertex and it seeks to provide a 
>different trust model with TLS and Twisted.

Is there any intro / architecture document? I'd like to read more .. 

/Tobias

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] AutobahnPython 0.6.3 - WebSocket compression and more

[Phil Mayers]

On 10/07/2013 08:51 AM, Tobias Oberstein wrote:


I did some further looking around: turns out there is TLS-PGP

http://tools.ietf.org/html/rfc6091

Does someone know whether OpenSSL supports that?



There are *lots* of TLS extensions that eliminate or obviate the need 
for the (horrible) PKIX trust model as deployed. For example, TLS PSK, 
TLS-SRP, the PGP method you've found, and others.


Right now, none are useful in a browser, but personally I have high 
hopes for raw keys, trust-anchored by DNSSEC via RFC 6698. In this 
model, X.509 is essentially just a payload format for certs - the entire 
trust model is unused.



[Sidenote: if not, one more reason why a pure Python TLS


Such as tlslite?

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] AutobahnPython 0.6.3 - WebSocket compression and more

[Phil Mayers]

On 10/07/2013 09:50 AM, Phil Mayers wrote:


Right now, none are useful in a browser, but personally I have high
hopes for raw keys, trust-anchored by DNSSEC via RFC 6698. In this
model, X.509 is essentially just a payload format for certs


Sorry, "payload format for keys".

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] AutobahnPython 0.6.3 - WebSocket compression and more

[Donald Stufft]

DNSSEC solves none of the problems with the CA system. It just moves the 
problem around. 

> On Oct 7, 2013, at 4:50 AM, Phil Mayers  wrote:
> 
> I have high hopes for raw keys, trust-anchored by DNSSEC via RFC 6698. In 
> this model, X.509 is essentially just a payload format for certs - the entire 
> trust model is unused.

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] AutobahnPython 0.6.3 - WebSocket compression and more

[Tobias Oberstein]

> There are *lots* of TLS extensions that eliminate or obviate the need for the
> (horrible) PKIX trust model as deployed. For example, TLS PSK, TLS-SRP, the
> PGP method you've found, and others.

Sure .. however as far as I understand the IETF has only 2 _cert_ schemes 
sanctioned:
x509 and OpenPGP, and of those only OpenPGP has a decentralized trust model.

> 
> Right now, none are useful in a browser, but personally I have high hopes for

Which is the main roadblocker to adoption .. right.

> raw keys, trust-anchored by DNSSEC via RFC 6698. In this model, X.509 is
> essentially just a payload format for certs - the entire trust model is 
> unused.

DNSSEC seems to follow a centralized/hierachical trust model. Won't help. The 
NSA will (does?) own those.

> > [Sidenote: if not, one more reason why a pure Python TLS
> 
> Such as tlslite?

That could be a good start: it would take a community effort to scrutinize, 
security review and
robustify for production.

The monoculture of OpenSSL is no good IMHO.

/Tobias

> 
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] AutobahnPython 0.6.3 - WebSocket compression and more

[Phil Mayers]

On 07/10/13 11:56, Donald Stufft wrote:

DNSSEC solves none of the problems with the CA system. It just moves
the problem around.


Disagree.

However - there are other, better forums to have this argument in (and 
to be frank, I've no interest in having it at all) so I won't respond 
further.


I would however urge other people reading this to look into the issues 
and decide for themselves.


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] AutobahnPython 0.6.3 - WebSocket compression and more

[Phil Mayers]

On 07/10/13 12:35, Tobias Oberstein wrote:


DNSSEC seems to follow a centralized/hierachical trust model. Won't
help. The NSA will (does?) own those.


The default trust model is to have parent sign the child. Other models 
are not only possible, they're deployed. Google "DLV" and "trust anchor".


As to whether "the NSA" has the root keys; given recent revelations I 
rule nothing out. But if this is a concern, I would urge you to 
investigate and get involved in the root key generation and rollover 
procedures - there is a rollover coming soon, and more eyes make 
subversion less likely.



That could be a good start: it would take a community effort to
scrutinize, security review and robustify for production.

The monoculture of OpenSSL is no good IMHO.


I agree, but there are other options - gnutls, NSS - which have received 
this scrutiny, if you want to move away from OpenSSL.


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] txThings - simple library for CoAP protocol

[Glyph]

On Oct 6, 2013, at 4:11 AM, Tobias Oberstein  
wrote:

>>> If above sounds OT for this list, in one way probably, but when looking from
>>> the angle: competitive advantage of Python/Twisted and opportunities for
>>> expanding the community and actively promoting Twisted, I'd say it's on
>>> topic.
> 
>> While I appreciate showing respect for the list membership's time and trying 
>> to stay on topic - jeez, lighten up, if you have stuff to say about Twisted, 
>> please just >say it on this list ;-).  The Management will not hesitate to 
>> (gently, politely) tell you if we believe you've gone too far afield.
> 
> Ok, thank you for making this crystal clear! 
> 
> What's your take on the tactic/proposal  "actively promoting Twisted for IoT"?

Personally I don't have much of one.  I don't know a lot about that space.

> E.g., as a start, we could have a dedicated page on the Twistedmatrix Web 
> site "Twisted for Things" for intro and collecting links, articles etc

Fun fact: the very first class in the very first thing that would eventually 
become Twisted was called "Thing".  ;-)

> Dummy question: how would I contribute to the Trac-based Web site content?

Just click on the "edit" button at the bottom of any wiki page.  Some of the 
pages (like the front page) are locked to prevent abuse, but I can give you 
whatever extra permissions you need if you want to work on the site.

-glyph
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] txThings - simple library for CoAP protocol

[Tobias Oberstein]

> > E.g., as a start, we could have a dedicated page on the Twistedmatrix
> > Web site "Twisted for Things" for intro and collecting links, articles
> > etc
> 
> Fun fact: the very first class in the very first thing that would eventually
> become Twisted was called "Thing".  ;-)

What a prevision;)

> 
> > Dummy question: how would I contribute to the Trac-based Web site
> content?
> 
> Just click on the "edit" button at the bottom of any wiki page.  Some of the
> pages (like the front page) are locked to prevent abuse, but I can give you
> whatever extra permissions you need if you want to work on the site.

Yes please, I'd like to contribute to the site.

I have visited a dozen pages from the Index, and I have no "edit" button .. 
nowhere. I am logged in ("oberstet") .. I can file/edit tickets.

I would start by creating a new page, following 
http://twistedmatrix.com/trac/wiki/WikiNewPage, and - at this point - only add 
a link to the new page from the Index page.

A general question regarding using Trac as a Website system: the landing page 
does only links to a couple of further pages.
How are user supposed to navigate around? Always via the Index page?

You know, I haven't done a lot systematic looking around exactly for that 
reason .. when I look for Twisted docs/pages, I basically Google for them 
(sometimes restricting the search to Twistedmatrix).
The UX of the Website is .. unusual .. or I just don't get it.

/Tobias

> 
> -glyph
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] AutobahnPython 0.6.3 - WebSocket compression and more

[Glyph]

On Oct 7, 2013, at 6:13 AM, Phil Mayers  wrote:

> On 07/10/13 11:56, Donald Stufft wrote:
>> DNSSEC solves none of the problems with the CA system. It just moves
>> the problem around.
> 
> Disagree.
> 
> However - there are other, better forums to have this argument in (and to be 
> frank, I've no interest in having it at all) so I won't respond further.
> 
> I would however urge other people reading this to look into the issues and 
> decide for themselves.

If you have a disagreement, please say what the disagreement is (not just 
"disagree") and then link to resources instead of abstractly claiming people 
may find them themselves somehow.  You don't have to get into a big 
back-and-forth, but I believe DNSSEC implementation work is proceeding in 
Twisted so it would be good for the community to be aware of these issues.

-glyph

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] AutobahnPython 0.6.3 - WebSocket compression and more

[Phil Mayers]

On 07/10/2013 18:58, Glyph wrote:


If you have a disagreement, please say /what the disagreement is/ (not
just "disagree") and then link to resources instead of abstractly
claiming people may find them themselves somehow.  You don't have to get
into a big back-and-forth, but I believe DNSSEC implementation work is
proceeding in Twisted so it would be good for the community to be aware
of these issues.


Ok. Don't say I didn't warn you. Apologies to anyone who forces 
themselves to read all this, and please note I DO NOT claim authority on 
any of this - I'm just a random guy. People should decide for themselves.


Donald wrote:

"""
DNSSEC solves none of the problems with the CA system. It just moves the 
problem around.

"""

I believe I understand why he said this, but I think it's incorrect to 
say that DNSSEC solves "none" of the problems. I think it solves many 
(though not all) of them, and that supplementary systems - which are 
desirable in and of themselves - can take us the rest of the way.


Here's my reasoning:

I think it's fair to say that the PKIX trust model is known to have some 
serious flaws. They basically stem from the existence of far, far too 
many CAs, and the lack of constraint on what a CA can issue for.


There are various proposed solutions to this problem. DNSSEC-signed TLSA 
records (DANE; RFC 6698) offer one solution to the problem - to put 
hashes of certs/keys or issuer/chain certs/keys in DNS, and sign then 
with DNSSEC. This accomplishes two things:


 1. Reduction in the number of trusted CAs. To what degree depends on 
what deployment model you use - you can put a specific key/cert into 
DNS, or one or more traditional X.509 issuers that allowed to sign for 
you. The latter in particular seems likely to be common - reduce the CAs 
that can sign for "blah.example.com" from ~1500 by putting the hashes of 
the 1/2/N "good" CA certs (most specific parent!) into the 
"blah.example.com" TLSA records.


 2. Constraint - a DNS zone-signing key can only sign records below it, 
terminating at secure child delegations (DS keys).


The obvious objection to this solution is the necessary trust in the DNS 
root / parent zones. There are, it seems, people who are not willing to 
grant this trust. I understand that - particularly in light of recent 
revelations.


However: government agencies are not the only people who might want to 
get certs in the name of a 3rd party. Crime syndicates attacking the 
latest race-to-the-bottom CA to get "ex>ample.com" certs are a real issue, and DANE can handle these just fine.


There are arguments that DANE moves the trust problem from CAs to 
registrars and registries. I must admit, I don't understand the threat 
model here - it's asserted that registrars are cheap&cheerful (true) but 
they only handle public key material, and don't run the DNS; the 
registry is a more fruitful target, but validation of the public key 
material they publish for you is trivial (whereas proving that a CA 
somewhere hasn't signed a cert for your domain is not).


In short, I think it's a significant net win, and as a side benefit 
offers greatly reduced key management burden. The ability to publish and 
revoke TLSA records at significantly lower cost than X.509 cert 
issuance, and without need to interact with a 3rd party, would be 
valuable even without the above. It could in theory help decouple TLS 
from X.509 - useful if you want to move to PGP, for example.


However, some people don't agree. Moxie Marlinspike discusses the 
general issues and makes an argument against DANE - see:


http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/

...and the video of the talk here:

http://www.youtube.com/watch?v=Z7Wl2FW2TcA

He essentially suggests a trusted notary system - a working 
implementation of which you can see here:


http://convergence.io/

I agree that this approach is promising. I am not super-confident that 
it will take off - end-users literally DO NOT CARE about these issues 
until it's too late - but if someone (Chrome, Firefox) starts bundling 
notary functionality and prompting users to trust one or more of a 
(randomly shuffled) set of notaries on startup, it might... However, I'm 
not sure how likely that is - see:


https://www.imperialviolet.org/2011/09/07/convergence.html

[Note Adam Langley is "Google TLS person"]

For an alternative take on the problem, see:

http://www.certificate-transparency.org/

People interested in reading a pro-DNSSEC PoV should look here (warning 
- sequence of posts):


http://dankaminsky.com/2010/12/13/dnssec-ch1/

...and here:

http://www.slideshare.net/dakami/black-opspki-2

So - not as short as I'd like, but as short as I could make it. I hope 
that makes my position clear.


Finally a note on why I was reluctant to respond...

In my experience, "discussions" on TLS, X.509, DNS and DNSSEC can become 
very emotive, very quickly. There are people who care very, very deeply 
about the minutae of these i

[Twisted-Python] ANN: Crochet 0.9.0 - Use Twisted Anywhere!

[Itamar Turner-Trauring]

Crochet is an MIT-licensed library that makes it easier for blocking or 
threaded applications like Flask or Django to use the Twisted networking 
framework. Crochet provides the following features:


 * Runs Twisted's reactor in a thread it manages.
 * The reactor shuts down automatically when the process' main thread
   finishes.
 * Hooks up Twisted's log system to the Python standard library logging
   framework. Unlike Twisted's built-in logging bridge, this includes
   support for blocking Handler instances.
 * A blocking API to eventual results (i.e. Deferred instances). This
   last feature can be used separately, so Crochet is also useful for
   normal Twisted applications that use threads.

You can download Crochet at: http://pypi.python.org/pypi/crochet

Documentation can be found at: http://crochet.readthedocs.org

Bugs and feature requests should be filed at the project page: 
https://github.com/itamarst/crochet


*What's New in 0.9.0*

New features:

 * Expanded and much improved documentation, including a new section
   with design suggestions.
 * New decorator @wait_for_reactor added, a simpler alternative to
   @run_in_reactor.
 * Refactored @run_in_reactor, making it a bit more responsive.
 * Blocking operations which would otherwise never finish due to
   reactor having stopped (EventualResult.wait() or @wait_for_reactor
   decorated call) will be interrupted with a ReactorStopped exception.

Bug fixes:

 * @run_in_reactor decorated functions (or rather, their generated
   wrapper) are interrupted by Ctrl-C.
 * On POSIX platforms, a workaround is installed to ensure processes
   started by reactor.spawnProcess have their exit noticed. See Twisted
   ticket 6378  for more details about the
   underlying issue.

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python