On Fri, Nov 14, 2014 at 8:00 PM, Patrick McManus mcma...@ducksong.com wrote:
On Thu, Nov 13, 2014 at 11:16 PM, Henri Sivonen hsivo...@hsivonen.fi
wrote:
The part that's hard to accept is: Why is the countermeasure
considered effective for attacks like these, when the level of how
active the
On Friday, November 14, 2014 6:25:43 PM UTC+11, Henri Sivonen wrote:
This is obvious to everyone reading this mailing list. My concern is
that if the distinction between http and https gets fuzzier, people
who want encryption but who want to avoid ever having to pay a penny
to a CA will think
On 2014-11-13, at 21:25, Henri Sivonen hsivo...@hsivonen.fi wrote:
Your argument relies on there being no prior session that was not
intermediated by the attacker. I’ll concede that this is a likely situation
for a large number of clients, and not all servers will opt for protection
On Fri, Nov 14, 2014 at 10:51 AM, Martin Thomson m...@mozilla.com wrote:
How so given that
http://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01
exists and explicitly seeks to defeat the defense that TLS traffic
arising from https and TLS traffic arising from already-upgraded OE
On Thu, Nov 13, 2014 at 11:16 PM, Henri Sivonen hsivo...@hsivonen.fi
wrote:
The part that's hard to accept is: Why is the countermeasure
considered effective for attacks like these, when the level of how
active the MITM needs to be to foil the countermeasure (by
inhibiting the upgrade by
I’m not all that enthused by the blow-by-blow here. Nonetheless, there are
some distortions to correct.
On 2014-11-12, at 20:23, Henri Sivonen hsivo...@hsivonen.fi wrote:
That's true if the server presents a publicly trusted cert for the
wrong hostname (as is common if you try to see what
I haven't really waded into this iteration of the discussion because there
isn't really new information to talk about. But I know everyone is acting
in good faith so I'll offer my pov again. We're all trying to serve our
users and the Internet - same team :)
OE means ciphertext is the new
On Thu, Nov 13, 2014 at 8:29 PM, Martin Thomson m...@mozilla.com wrote:
This is true for TLS = 1.2, but will not be true for TLS 1.3. Certificates
are available to a MitM currently, but in future versions, that sort of
attack will be detectable.
Great. I was unaware of this. (This is
On Mon, Sep 15, 2014 at 7:56 PM, Adam Roach a...@mozilla.com wrote:
The whole line of argumentation that web browsers and servers should be
taking advantage of opportunistic encryption is explicitly informed by
what's actually happening elsewhere. Because what's *actually* happening
is an
On Nov 12, 2014, at 4:35 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Sep 15, 2014 at 7:56 PM, Adam Roach a...@mozilla.com wrote:
The whole line of argumentation that web browsers and servers should be
taking advantage of opportunistic encryption is explicitly informed by
what's
On Wed, Nov 12, 2014 at 11:12 PM, Richard Barnes rbar...@mozilla.com wrote:
On Nov 12, 2014, at 4:35 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Sep 15, 2014 at 7:56 PM, Adam Roach a...@mozilla.com wrote:
The whole line of argumentation that web browsers and servers should be
On Mon, Sep 15, 2014 at 11:34 AM, Anne van Kesteren ann...@annevk.nl wrote:
It seems very bad if those kind of devices won't use authenticated
connections in the end. Which makes me wonder, is there some activity
at Mozilla for looking into an alternative to the CA model?
What happened to
On Sun, Sep 21, 2014 at 1:14 PM, Aryeh Gregor a...@aryeh.name wrote:
What happened to serving certs over DNSSEC? If browsers supported
that well, it seems it has enough deployment on TLDs and registrars to
be usable to a large fraction of sites.
DNSSEC does not help with authentication of
Pretty sure that what he's referring to is called DANE. It lets a domain
holder assert a certificate or key pair, using DNSSEC to bind it to the domain
instead of PKIX (or in addition to PKIX).
https://tools.ietf.org/html/rfc6698
On Sep 21, 2014, at 8:01 AM, Anne van Kesteren
On Fri, Sep 12, 2014 at 6:07 PM, Trevor Saunders
trev.saund...@gmail.com wrote:
Do we really want all servers to have to authenticate themselves?
On the level of DV, yes, I think. (I.e. the user has a good reason to
believe that the [top-level] page actually comes from the host named
in the
On Mon, 15 Sep 2014, Henri Sivonen wrote:
What the Chrome folks suggest for HTTP/2 would give rise to a situation
where your alternatives are still one one hand unencrypted and
unauthenticated and on the other hand encrypted and authenticated *but* the
latter is *faster*.
You mess up that
On Mon, Sep 15, 2014 at 10:24 AM, Daniel Stenberg dan...@haxx.se wrote:
Shouldn't we strive to make the user experience better for all
users, even those accessing HTTP sites?
Well, the question is whether we want HTTP in the end. E.g. we are
opting to not enable new powerful features such as
On Mon, Sep 15, 2014 at 11:24 AM, Daniel Stenberg dan...@haxx.se wrote:
On Mon, 15 Sep 2014, Henri Sivonen wrote:
What the Chrome folks suggest for HTTP/2 would give rise to a situation
where your alternatives are still one one hand unencrypted and
unauthenticated and on the other hand
On Sep 15, 2014, at 5:11 AM, Henri Sivonen hsivo...@hsivonen.fi wrote:
On Mon, Sep 15, 2014 at 11:24 AM, Daniel Stenberg dan...@haxx.se wrote:
On Mon, 15 Sep 2014, Henri Sivonen wrote:
What the Chrome folks suggest for HTTP/2 would give rise to a situation
where your alternatives are still
On Mon, Sep 15, 2014 at 5:59 PM, Richard Barnes rbar...@mozilla.com wrote:
On Sep 15, 2014, at 5:11 AM, Henri Sivonen hsivo...@hsivonen.fi wrote:
I think the primary way for making the experience better for users
currently accessing http sites should be getting the sites to switch
to https so
On Mon, Sep 15, 2014 at 9:08 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Sep 15, 2014 at 5:59 PM, Richard Barnes rbar...@mozilla.com
wrote:
On Sep 15, 2014, at 5:11 AM, Henri Sivonen hsivo...@hsivonen.fi wrote:
I think the primary way for making the experience better for users
On 9/15/14 11:08, Anne van Kesteren wrote:
Google seems to have the right trade off
and the IETF consensus seems to be unaware of what is happening
elsewhere.
You're confused.
The whole line of argumentation that web browsers and servers should be
taking advantage of opportunistic encryption
On Thu, Sep 11, 2014 at 6:56 PM, Richard Barnes rbar...@mozilla.com wrote:
No, WebCrypto on an http:// origin is not a replacement for TLS.
Addressing confusion on this point seems to be the main driver of
Chrome's restriction of Web Crypto to authenticated origins. Is there
any way to quantify
On Thu, Sep 11, 2014 at 6:58 PM, Adam Roach a...@mozilla.com wrote:
When you force people into an all or nothing situation regarding
security,
Nature finds his own way: As nothing was invented for doing Javscript
Cryptography, someone started using Java Applets. Java applets are much
more
On Fri, Sep 12, 2014 at 1:55 AM, Henri Sivonen hsivo...@hsivonen.fi wrote:
tion to https
that obtaining, provisioning and replacing certificates is too
expensive.
Related concepts are at the core of why I'm going to give Opportunistic
Security a try with http/2. The issues you cite are real
On Fri, Sep 12, 2014 at 08:55:51AM +0300, Henri Sivonen wrote:
On Thu, Sep 11, 2014 at 9:00 PM, Richard Barnes rbar...@mozilla.com wrote:
On Sep 11, 2014, at 9:08 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Sep 11, 2014 at 5:56 PM, Richard Barnes rbar...@mozilla.com
wrote:
On 2014-09-11, at 22:55, Henri Sivonen hsivo...@hsivonen.fi wrote:
Moreover, https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-00
has the performance overhead of TLS, so it doesn't really address the
TLS takes too much compute power objection to https, which is the
usual
On Fri, Sep 12, 2014 at 6:06 PM, Martin Thomson m...@mozilla.com wrote:
And the restrictions on the Referer header field also mean that some
resources can’t be served over HTTPS (their URL shortener is apparently the
last hold-out for http:// at Twitter).
That is something that we should
On 9/12/14 10:07, Trevor Saunders wrote:
[W]hen it comes to the NSA we're pretty much just not going to be able
to force everyone to use something strong enough they can't beat it.
Not to get too far off onto this sidebar, but you may find the following
illuminating; not just for potentially
Hey all,
Sorry for being late to the party here. I now subscribe to dev.platform :)
On the issue of whether WebCrypto should be restricted to secure origins: In
discussions I've had with folks around Mozilla, we have not seen sufficient
security risks to motivate cutting off the potential
On Thu, Sep 11, 2014 at 5:56 PM, Richard Barnes rbar...@mozilla.com wrote:
Most notably, even over non-secure origins, application-layer encryption can
provide resistance to passive adversaries.
See https://twitter.com/sleevi_/status/509723775349182464 for a long
thread on Google's security
On 9/11/14 11:08, Anne van Kesteren wrote:
On Thu, Sep 11, 2014 at 5:56 PM, Richard Barnes rbar...@mozilla.com wrote:
Most notably, even over non-secure origins, application-layer encryption can
provide resistance to passive adversaries.
See
On Sep 11, 2014, at 9:08 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Sep 11, 2014 at 5:56 PM, Richard Barnes rbar...@mozilla.com wrote:
Most notably, even over non-secure origins, application-layer encryption can
provide resistance to passive adversaries.
See
Is the argument still valid that active attacks are detectable while
passive attacks are not, making the costs/risks to an active attacker
significantly higher?
Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro
On Thu, Sep 11, 2014 at 9:00 PM, Richard Barnes rbar...@mozilla.com wrote:
On Sep 11, 2014, at 9:08 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Sep 11, 2014 at 5:56 PM, Richard Barnes rbar...@mozilla.com wrote:
Most notably, even over non-secure origins, application-layer encryption
35 matches
Mail list logo