On Fri, Nov 21, 2014 at 5:44 PM, Patrick McManus mcma...@ducksong.com wrote:
On Fri, Nov 21, 2014 at 10:09 AM, Anne van Kesteren ann...@annevk.nl
wrote:
Why would they be allowed to use OE?
The reasons why any individual resource has to be http:// and may (or may
not) be able to run OE vary
Hi Anne,
On Tue, Nov 25, 2014 at 9:13 AM, Anne van Kesteren ann...@annevk.nl wrote:
They are doing this with opportunistic encryption (via the
Alternate-Protocol response header) for http:// over QUIC from chrome.
In
Or are you saying that
because Google experiments with OE in QUIC,
On Fri, Nov 21, 2014 at 4:53 PM, Patrick McManus mcma...@ducksong.com wrote:
Hi -
On Fri, Nov 21, 2014 at 5:41 AM, Henri Sivonen hsivo...@hsivonen.fi wrote:
Indeed. Huge thanks to everyone who is making Let's Encrypt happen.
regulatory compliance,
What's this about?
On Wed, Nov 19, 2014 at 4:50 PM, Patrick McManus mcma...@ducksong.com wrote:
On Wed, Nov 19, 2014 at 1:45 AM, Henri Sivonen hsivo...@hsivonen.fi wrote:
Does Akamai's logo appearing on the Let's Encrypt announcements change
Akamai's need for OE? (Seems *really* weird if not.)
let's encrypt
On Fri, Nov 21, 2014 at 3:53 PM, Patrick McManus mcma...@ducksong.com wrote:
nosslsearch.google.com is an example of the weight of regulatory compliance
in action. Google talks loudly about all https (and has the leading track
record), yet there it is. And google isn't special in that regard.
On 2014-11-21, at 08:19, Justin Dolske dol...@mozilla.com wrote:
Is that a direct or indirect cause? AFAIK nothing directly requires Google to
offer this, but the alternative would be organizations and networks who do
want/need to see traffic simply blocking Google services. And so Google
On 18/11/14 04:03, voracity wrote:
The issue isn't that people are cheapskates, and will lose 'a few
dollars'. The issue is that transaction costs
http://en.wikipedia.org/wiki/Transaction_cost can be crippling.
https://letsencrypt.org/ .
Gerv
___
On Wed, Nov 19, 2014 at 1:45 AM, Henri Sivonen hsivo...@hsivonen.fi wrote:
Does Akamai's logo appearing on the Let's Encrypt announcements change
Akamai's need for OE? (Seems *really* weird if not.)
let's encrypt is awesome - more https is awesome.
The availability of let's encrypt (or
On 11/19/14 04:50, Patrick McManus wrote:
There are basically 2 arguments against OE here: 1] you don't need OE
because everyone can run https and 2] OE somehow undermines https
I don't buy them because [1] remains a substantial body of data and [2] is
unsubstantiated speculation and borders on
On Wednesday, November 19, 2014 11:12:42 PM UTC+11, Gervase Markham wrote:
https://letsencrypt.org/ .
When I first saw Let's Encrypt (the very next day after my post) I got excited,
but when I read how it works, I got even more excited. There's still things it
doesn't (seem to) solve
On 11/17/14 1:48 AM, Henri Sivonen wrote:
As for cat and mouse, I'd prefer putting our cat-and-mouse energies
into patching up https PKI instead of introducing a new cat-and-mouse
situation to pay attention to. (Despite being able to walk and chew
gum, our end isn't 100% immune to opportunity
On Wed, Nov 19, 2014 at 1:20 PM, Chris Peterson cpeter...@mozilla.com
wrote:
On 11/17/14 1:48 AM, Henri Sivonen wrote:
As for cat and mouse, I'd prefer putting our cat-and-mouse energies
into patching up https PKI instead of introducing a new cat-and-mouse
situation to pay attention to.
On Wed, Nov 19, 2014 at 1:20 PM, Chris Peterson cpeter...@mozilla.com
wrote:
Given Mozilla's announcements around Let's Encrypt, are there still use
cases for HTTP+OE?
https://letsencrypt.org/2014/11/18/announcing-lets-encrypt.html
In particular:
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 15/09/14 16:34, Anne van Kesteren 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 makes you think that switching away from the CA
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 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 12/09/14 13:37, Anne van Kesteren wrote:
That is something that we should have fixed a long time ago. It's
called meta name=referrer and is these days also part of CSP.
I'll forward that on to those involved. Thanks.
___
dev-platform mailing list
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
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
43 matches
Mail list logo
