On Oct 7, 2013, at 4:10 PM, Phil Mayers wrote:
> 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 hav
> 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.
Nothing to apologize .. I have learned from your post. And the pointers you
g
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 impl
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
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".
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
> 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 OpenP
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 enti
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".
_
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 tr
>>>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
> On Oct 6, 2013, at 5:23 PM, exar...@twistedmatrix.com wrote:
>
> On 6 Oct, 11:02 pm, tobias.oberst...@tavendo.de wrote:
Personally, I assume root CA private keys of any CA vendor are owned by
the NSA anyway.
>>>
>>> There's no rule that says you have to use a "root CA" signed certif
On 6 Oct, 11:02 pm, tobias.oberst...@tavendo.de wrote:
Personally, I assume root CA private keys of any CA vendor are owned
by
the NSA anyway.
There's no rule that says you have to use a "root CA" signed
certificate
for your TLS connections.
Sure, in theory, but there are multiple practica
>> Personally, I assume root CA private keys of any CA vendor are owned by
>> the NSA anyway.
>
> There's no rule that says you have to use a "root CA" signed certificate
> for your TLS connections.
Sure, in theory, but there are multiple practical problems when using
self-signed certs or certs s
On 02:51 pm, tobias.oberst...@tavendo.de wrote:
.. , since I like compression but I also send credentials over TLS :)
IMHO, credentials should never be sent over the wire (be it encrypted
or not) and never be stored in plaintext.
FWIW, Autobahn provides a challenge-response authentication sc
>.. , since I like compression but I also send credentials over TLS :)
IMHO, credentials should never be sent over the wire (be it encrypted or not)
and never be stored in plaintext.
FWIW, Autobahn provides a challenge-response authentication scheme ("WAMP_CRA")
that also allows for salted/hash
On 5 Oct, 02:24 pm, tobias.oberst...@tavendo.de wrote:
Hi,
AutobahnPython 0.6.3 was just released to PyPi
https://pypi.python.org/pypi/autobahn with lots of new features,
including _WebSocket compression_, an upcoming extension to the
WebSocket protocol.
Heya Tobias,
Great news! Thanks fo
>If I get a chance, I'll try to apply the recent attacks by Rizzo et al. on TLS
>compression and the compressed stream over TLS equivalent by Prado et al.,
>since I like >compression but I also send credentials over TLS :)
I guess you are referring to CRIME/BEAST, right?
I haven't had a deep lo
Congratulations! Please keep the announcements coming.
If I get a chance, I'll try to apply the recent attacks by Rizzo et al. on
TLS compression and the compressed stream over TLS equivalent by Prado et
al., since I like compression but I also send credentials over TLS :)
cheers
lvh
On Oct 5, 2013, at 7:24 AM, Tobias Oberstein
wrote:
> AutobahnPython 0.6.3 was just released to PyPi
> https://pypi.python.org/pypi/autobahn with lots of new features, including
> _WebSocket compression_, an upcoming extension to the WebSocket protocol.
Congratulations, Tobias! And thanks
Hi,
AutobahnPython 0.6.3 was just released to PyPi
https://pypi.python.org/pypi/autobahn with lots of new features, including
_WebSocket compression_, an upcoming extension to the WebSocket protocol.
We have seen compression ratios of 2-15x with JSON payload over WebSocket,
which is great, in
21 matches
Mail list logo
