Subject: [perpass] EFF, Mozilla et al. announce new free certificate authority...

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 18 Nov 2014 12:50:47 -0500

So cool I'll just shut my mouth and let the launch text speak for
itself... (links in the original)

- ----

https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web

# Launching in 2015: A Certificate Authority to Encrypt the Entire Web

Today EFF is pleased to announce Let?s Encrypt, a new certificate
authority (CA) initiative that we have put together with Mozilla,
Cisco, Akamai, Identrust, and researchers at the University of
Michigan that aims to clear the remaining roadblocks to transition the
Web from HTTP to HTTPS.

Although the HTTP protocol has been hugely successful, it is
inherently insecure. Whenever you use an HTTP website, you are always
vulnerable to problems, including account hijacking and identity
theft; surveillance and tracking by governments, companies, and both
in concert; injection of malicious scripts into pages; and censorship
that targets specific keywords or specific pages on sites. The HTTPS
protocol, though it is not yet flawless, is a vast improvement on all
of these fronts, and we need to move to a future where every website
is HTTPS by default.With a launch scheduled for summer 2015, the Let?s
Encrypt CA will automatically issue and manage free certificates for
any website that needs them. Switching a webserver from HTTP to HTTPS
with this CA will be as easy as issuing one command, or clicking one
button.

The biggest obstacle to HTTPS deployment has been the complexity,
bureaucracy, and cost of the certificates that HTTPS requires. We?re
all familiar with the warnings and error messages produced by
misconfigured certificates. These warnings are a hint that HTTPS (and
other uses of TLS/SSL) is dependent on a horrifyingly complex and
often structurally dysfunctional bureaucracy for authentication.

The need to obtain, install, and manage certificates from that
bureaucracy is the largest reason that sites keep using HTTP instead
of HTTPS. In our tests, it typically takes a web developer 1-3 hours
to enable encryption for the first time. The Let?s Encrypt project is
aiming to fix that by reducing setup time to 20-30 seconds. You can
help test and hack on the developer preview of our Let's Encrypt agent
software or watch a video of it in action here:

Let?s Encrypt will employ a number of new technologies to manage
secure automated verification of domains and issuance of certificates.
We will use a protocol we?re developing called ACME between web
servers and the CA, which includes support for new and stronger forms
of domain validation. We will also employ Internet-wide datasets of
certificates, such as EFF?s own Decentralized SSL Observatory, the
University of Michigan?s scans.io, and Google's Certificate
Transparency logs, to make higher-security decisions about when a
certificate is safe to issue.

The Let?s Encrypt CA will be operated by a new non-profit organization
called the Internet Security Research Group (ISRG). EFF helped to put
together this initiative with Mozilla and the University of Michigan,
and it has been joined for launch by partners including Cisco, Akamai,
and Identrust.

The core team working on the Let's Encrypt CA and agent software
includes James Kasten, Seth Schoen, and Peter Eckersley at EFF; Josh
Aas, Richard Barnes, Kevin Dick and Eric Rescorla at Mozilla; Alex
Halderman and James Kasten and the University of Michigan.

- -- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Nov 2014 17:54:23 +0000

Nice!

Sounds extremely promising.

S.

On 18/11/14 17:50, Joseph Lorenzo Hall wrote:
> ----
> Michigan that aims to clear the remaining roadblocks to transition
> the Web from HTTP to HTTPS.
> 
> inherently insecure. Whenever you use an HTTP website, you are
> always vulnerable to problems, including account hijacking and
> identity theft; surveillance and tracking by governments,
> companies, and both in concert; injection of malicious scripts into
> pages; and censorship that targets specific keywords or specific
> pages on sites. The HTTPS protocol, though it is not yet flawless,
> is a vast improvement on all of these fronts, and we need to move
> to a future where every website is HTTPS by default.With a launch
> scheduled for summer 2015, the Let?s Encrypt CA will automatically
> issue and manage free certificates for any website that needs them.
> Switching a webserver from HTTP to HTTPS with this CA will be as
> easy as issuing one command, or clicking one button.
> 
> bureaucracy, and cost of the certificates that HTTPS requires.
> We?re all familiar with the warnings and error messages produced
> by misconfigured certificates. These warnings are a hint that HTTPS
> (and other uses of TLS/SSL) is dependent on a horrifyingly complex
> and often structurally dysfunctional bureaucracy for
> authentication.
> 
> bureaucracy is the largest reason that sites keep using HTTP
> instead of HTTPS. In our tests, it typically takes a web developer
> 1-3 hours to enable encryption for the first time. The Let?s
> Encrypt project is aiming to fix that by reducing setup time to
> 20-30 seconds. You can help test and hack on the developer preview
> of our Let's Encrypt agent software or watch a video of it in
> action here:
> 
> secure automated verification of domains and issuance of
> certificates. We will use a protocol we?re developing called ACME
> between web servers and the CA, which includes support for new and
> stronger forms of domain validation. We will also employ
> Internet-wide datasets of certificates, such as EFF?s own
> Decentralized SSL Observatory, the University of Michigan?s
> scans.io, and Google's Certificate Transparency logs, to make
> higher-security decisions about when a certificate is safe to
> issue.
> 
> The Let?s Encrypt CA will be operated by a new non-profit
> organization called the Internet Security Research Group (ISRG).
> EFF helped to put together this initiative with Mozilla and the
> University of Michigan, and it has been joined for launch by
> partners including Cisco, Akamai, and Identrust.
> 
> includes James Kasten, Seth Schoen, and Peter Eckersley at EFF;
> Josh Aas, Richard Barnes, Kevin Dick and Eric Rescorla at Mozilla;
> Alex Halderman and James Kasten and the University of Michigan.
> 
> 
> _______________________________________________ perpass mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/perpass
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Nov 2014 14:07:47 -0500

> of domain validation. We will also employ Internet-wide datasets of

This is exciting; any interaction with cacert.org?
So, some kind of online certificate enrollment.
What protocols?  What open source?

I don't think this is is this going to help eliminate the invalid
certificates that seem inevitable from things like ILOMs/iDRAC/etc. because
the https interface to the service processor never knows what zone it will
use.     I'd love to find a way for such appliance uses of HTTPS to come
up secure in some way.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Patrick McManus <[email-masked]>
Date: Tue, 18 Nov 2014 14:13:32 -0500

You can read more about the project at https://letsencrypt.org/

You can see (and participate in) the work in progress protocols (called
ACME) around certificate management here:
https://github.com/letsencrypt/acme-spec

On Tue, Nov 18, 2014 at 12:54 PM, Stephen Farrell <[email-masked]
> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Nice!
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUa4fMAAoJEC88hzaAX42idrsH/1ESxXdSUtqFuE3Qea2neAs8
> yECBMM44hIFI5Vqen/YtmNDsa8/L72mUkdaCkTEBCJdRQQt6pYigKNQZ+ZBIUUi7
> VY9bhdugo/TqrszHhy+U3rCwvyBGbjBqQf4sVaNx6FOdqY0upnW8foetnYz2XbCI
> AO+N6SoNjxd5NkU3zY/mJ09a1tpY6/T0jeKdfoHAG1QG9DZs0bctCfwo07qV5vGv
> hiS1O3VrU9KRBaVcCm+IlacV1UsEc6U3n6WeXGxOG9wUTKGIvbVhyQvFUP/xgB+N
> D8QW5gTzf96Vc8oh/pc/LRdo3qwafarbCYHRENdKs2YciseK11OkjhK3cxdJlQI=
> =As8k
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> perpass mailing list
> [email-masked]

---

From: manning bill <[email-masked]>
Date: Tue, 18 Nov 2014 11:38:38 -0800

nothing more expensive than free…

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

On 18November2014Tuesday, at 11:13, Patrick McManus <[email-masked]> wrote:

> You can see (and participate in) the work in progress protocols (called ACME) around certificate management here: https://github.com/letsencrypt/acme-spec
> 
> On Tue, Nov 18, 2014 at 12:54 PM, Stephen Farrell <[email-masked]> wrote:

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Nov 2014 19:44:46 +0000

> https://github.com/letsencrypt/acme-spec

So the plan for questions/comments is just via github
or is there a mailing list?

Ta,
S.

---

From: "Songhaibin (A)" <[email-masked]>
Date: Wed, 19 Nov 2014 03:55:23 +0000

It is now calling for attacks to test its robustness?

Best Regards!
-Haibin

> -----Original Message-----
> From: perpass [mailto:[email-masked]] On Behalf Of manning bill
> Sent: Wednesday, November 19, 2014 3:39 AM
> To: Patrick McManus
> Cc: perpass; Joseph Lorenzo Hall; Stephen Farrell
> Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate
> authority...
> 
> nothing more expensive than free...
> 
> 
> /bill
> PO Box 12317
> Marina del Rey, CA 90295
> 310.322.8102
> 
> > You can see (and participate in) the work in progress protocols
> > (called ACME) around certificate management here:
> > > identity theft; surveillance and tracking by governments, companies,
> > > and both in concert; injection of malicious scripts into pages; and
> > > censorship that targets specific keywords or specific pages on
> > > sites. The HTTPS protocol, though it is not yet flawless, is a vast
> > > improvement on all of these fronts, and we need to move to a future
> > > where every website is HTTPS by default.With a launch scheduled for
> > > summer 2015, the Let?s Encrypt CA will automatically issue and
> > > manage free certificates for any website that needs them.
> > > We?re all familiar with the warnings and error messages produced by
> > > misconfigured certificates. These warnings are a hint that HTTPS
> > > and often structurally dysfunctional bureaucracy for authentication.
> > >
> > > of HTTPS. In our tests, it typically takes a web developer
> > > 1-3 hours to enable encryption for the first time. The Let?s Encrypt
> > > project is aiming to fix that by reducing setup time to
> > > of our Let's Encrypt agent software or watch a video of it in action
> > > here:
> > >
> > > higher-security decisions about when a certificate is safe to issue.
> > >
> list
> > > [email-masked] https://www.ietf.org/mailman/listinfo/perpass
> > >
> > >

---

From: Richard Barnes <[email-masked]>
Date: Tue, 18 Nov 2014 21:15:05 -1000

On Tue, Nov 18, 2014 at 9:07 AM, Michael Richardson <[email-masked]>
wrote:

> certificates.

Here's what we have so far:

Protocol:

Demo Implementations:
https://github.com/letsencrypt/node-acme
https://github.com/letsencrypt/lets-encrypt-preview

Obviously, this is a first cut, and will benefit a lot from more eyes.
(AGL already pointed out something I should have caught in the first
round.)  This will be coming to the IETF Real Soon Now.

I actually think there's a fair bit of momentum around automating
certificate management, even from commercial CAs.  I can't imagine that
Cloudflare is doing TLS on 2M sites without some degree of automation to
their cert management.

> use.     I'd love to find a way for such appliance uses of HTTPS to come

I would be interested in that as well, since those things are a major
source of cert validation bugs.  Any ideas for what the authentication
would be?  Or maybe there's no meaningful authentication here, and it's a
use case for HTTP over unauthenticated TLS.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Tue, 18 Nov 2014 21:17:26 -1000

> It is now calling for attacks to test its robustness?

If there were an actual CA, then maybe :)  What we have now are some
prototype implementations, with a goal of getting the CA stood up in the
next few months.

--Richard

> > > On Tue, Nov 18, 2014 at 12:54 PM, Stephen Farrell <
> [email-masked]>
> > wrote:

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Nov 2014 18:42:24 -0500

> use case for HTTP over unauthenticated TLS.

I agree that given what we have here, HTTP over unauthenticated TLS (with
TOFU, ideally) would be significant better than training IT managers to click
through the warning.  I think that we should have, as a goal, elimination of
the click through certificate warning... nobody should ever do that.

In the case of an ILOM, we can't predict a name or an IP address which the
device can claim... but, the manufacturer usually has a MAC address, Asset
Tag, or other identifier which is often unique.  If only *THAT* could go into
the Location Bar instead of the IP address.  Yes, this is user interface
thing... sorta.. it's really about a different kind of URI.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 19 Nov 2014 13:47:01 -1000

> thing... sorta.. it's really about a different kind of URI.

We do have some history of putting identifiers besides domain names in the
URL bar.  Namely with EV certs, browsers typically display the
authenticated owner name.

So the real question is whether it's possible to make a PKI that can
authenticate those identifiers.  We would of course need some new types for
subjectAltName, but that's just more OIDs.  The more interesting question
is how the PKI would be structured -- who are the trusted authorities for
asset tags?

--Richard

---

From: Trevor Freeman <[email-masked]>
Date: Thu, 20 Nov 2014 10:01:37 -0800

The certificate warning paradigm is over blown given that the typical alternative is no TLS. An unauthenticated TLS connection is practically speaking, no different to no TLS at all. The same of true when you see certificate warring messages  S/MIME messages when the rest of the inbox is unsigned email. As long as the two cases are treated equal why cannot you dispense with the certificate warning messages?

From: perpass [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Wednesday, November 19, 2014 3:47 PM
To: Michael Richardson
Cc: perpass
Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority...

On Wed, Nov 19, 2014 at 1:42 PM, Michael Richardson <[email-masked]> wrote:

We do have some history of putting identifiers besides domain names in the URL bar.  Namely with EV certs, browsers typically display the authenticated owner name.

So the real question is whether it's possible to make a PKI that can authenticate those identifiers.  We would of course need some new types for subjectAltName, but that's just more OIDs.  The more interesting question is how the PKI would be structured -- who are the trusted authorities for asset tags?

--Richard

--
Michael Richardson <[email-masked] <mailto:[email-masked]> >, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ben Laurie <[email-masked]>
Date: Thu, 20 Nov 2014 18:17:17 +0000

On Thu Nov 20 2014 at 6:02:00 PM Trevor Freeman <[email-masked]>
wrote:

> The certificate warning paradigm is over blown given that the typical
> alternative is no TLS. An unauthenticated TLS connection is practically
> speaking, no different to no TLS at all.
>

It is different: it is secure against passive attackers.

> The same of true when you see certificate warring messages  S/MIME
> messages when the rest of the inbox is unsigned email. As long as the two
> cases are treated equal why cannot you dispense with the certificate
> warning messages?
>
>
>
> *From:* perpass [mailto:[email-masked]] *On Behalf Of *Richard
> Barnes
> *Sent:* Wednesday, November 19, 2014 3:47 PM
> *To:* Michael Richardson
> *Cc:* perpass
>
>
> *Subject:* Re: [perpass] EFF, Mozilla et al. announce new free
> certificate authority...
>
>
>
>
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Nov 2014 13:25:13 -0500

> thing... sorta.. it's really about a different kind of URI.

    rlb> We do have some history of putting identifiers besides domain names
    rlb> in the URL bar.  Namely with EV certs, browsers typically display the
    rlb> authenticated owner name.

okay, but in my experience the EV cert still has to match the host part of
the zone that the user typed in.  ILOMs, home appliances, etc. get an IP
address by DHCP or SLAAC. In the IPv6 situation things are perhaps slightly
better because the odds that appliance vendors will tell peope to type in an
IPv6 address, vs using mDNS/Bonjour seem lower.
Maybe, in some of those situations, we can have a name like
       "dell-r420-ABCD1234.local" 
used, and then maybe Dell can convince someone to give them a certificate
with this name in it... but... ideally, Dell would have their own
intermediate CA, and would ship their iDRAC with a built-in certificate.

    rlb> So the real question is whether it's possible to make a PKI that can
    rlb> authenticate those identifiers.  We would of course need some new
    rlb> types for subjectAltName, but that's just more OIDs.  The more
    rlb> interesting question is how the PKI would be structured -- who are
    rlb> the trusted authorities for asset tags?

I think that CAs would have to have a new category for intermediate CAs
with subjectAltName constraints that mean they can only sign asset tags/
DeviceIDs.  Also see draft-richardson-6tisch-idevid-cert-00, which 6tisch
considers using as part of the ANIMA work.

I had no thoughts about ILOM and appliance use of this system until you
mentioned that browsers could put something different than an HTTP URL in the
Location bar.

Where could this work get done?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Nov 2014 15:12:13 -0500

Trevor Freeman <[email-masked]> wrote:
    > speaking, no different to no TLS at all. The same of true when you see
    > certificate warring messages  S/MIME messages when the rest of the
    > inbox is unsigned email. As long as the two cases are treated equal why
    > cannot you dispense with the certificate warning messages? 

unauthenticated TLS is resistant to passive (bend the fiber, watch the leak,
starbucks coffee shop wifi) monitoring while no TLS is not.

unauthenticated TLS is not resistant to active (hijack the BGP session, break
the fiber, etc.) attacks.
{authenticated TLS is not resistant to national security letters}

If we had unauthenticated TLS plus TOFU, many home appliances would be more
secure; and we would avoid training end users to click through warning
screens.

In the scenario of home appliances and management access to ILOMs, people are
usually confident that BGP attacks are not occuring; the machine is just a
few layer-2 hops away.

And once you connect to the home appliance, one could then instruct the
device to do "letsencrypt" if you can give it a stable name reachable from
the letsencrypt people.  IPv6 could provide the connectivity.

---

From: Trevor Freeman <[email-masked]>
Date: Thu, 20 Nov 2014 16:46:34 -0800

Technically you are correct however give the vast majority of users do not
understand  the basics of encryption and singing, let alone these nuances,
you cannot express them as differences in the connection state to the user.
Hence you should  treat them as equal in the UI.

-----Original Message-----
From: perpass [mailto:[email-masked]] On Behalf Of Michael
Richardson
Sent: Thursday, November 20, 2014 12:12 PM
To: Trevor Freeman
Cc: 'Richard Barnes'; 'perpass'
Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate
authority...

unauthenticated TLS is not resistant to active (hijack the BGP session,
break the fiber, etc.) attacks.
{authenticated TLS is not resistant to national security letters}

In the scenario of home appliances and management access to ILOMs, people
are usually confident that BGP attacks are not occuring; the machine is just
a few layer-2 hops away.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -=
IPv6 IoT consulting =-

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 20 Nov 2014 21:23:33 -0800

> cannot you dispense with the certificate warning messages? 

The reasoning behind the warning is about expectation. If the browser sees a
self-signed cert instead, it does not know whether that was the original
intent of the site, or whether someone just staged an attack and provided a
self-signed cert instead of the real one. Since there is an expectation that
a site that publishes an HTTPS URL will also provide a CA signed
certificate, the browser errs on the side of detecting an attack.

This would change if there was an easy way to detect that the site intended
to use self-sign cert. But there is no such easy way today.

-- Christian Huitema

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Nov 2014 01:00:36 -0500

> Hence you should  treat them as equal in the UI.

Nobody said that unauthenticated TLS should show a "lock"

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Nov 2014 09:05:39 -0500

> Nobody said that unauthenticated TLS should show a "lock"

Unfortunately I think more people notice "https://" than the lock.   Although perhaps I think that because I am a geek who knows what https:// means, and regular folk actually do look at the lock icon.   In any case, I think that a cert signed by this free CA does the job, because it is not a self-signed cert: there would presumably be an independent verification step, even if that step is only to show that the person getting the cert actually has control over the domain.

Of course, if that is the test that is used, this sort of cert is no better than a DANE cert.   I guess the one advantage is that it doesn't require DNSSEC.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Nov 2014 14:11:38 +0000

On 21/11/14 14:05, Ted Lemon wrote:
> Unfortunately I think more people notice "https://" than the lock.  

The relevant proposal here is the httpbis WG draft. [1] I'm not
sure when a -01 will pop out, but there have been some comments
on this (incl. from me:-) on the WG list, so best to check there
in case you're repeating stuff that's already planned to change.

That is based on use of HTTP URIs and also not indicating that
TLS is in use via any lock icons or similar.

Seems like a fine idea to me fwiw, though somewhat controversial
amongst some browser folks still.

S.

[1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 21 Nov 2014 06:18:10 -0800

> On Nov 21, 2014, at 6:05 AM, Ted Lemon <[email-masked]> wrote:
> 

Thats actually the genius portion of the scheme: its a DV cert because the default flow has the certificate management program receives a request from the CA to put a token on the web site in question which the CA can then verify, so it allows fully automated proof of control for the site.

If anything, its arguably better than many CAs Domain Verification process.

> Of course, if that is the test that is used, this sort of cert is no better than a DANE cert.   I guess the one advantage is that it doesn't require DNSSEC.

Given that, because this will be cross signed (agreements are already in place) as well as an accepted root, this will be accepted by effectively all browsers, while ~1% of systems measured can not get DNSSEC information period.

Overall, this is a really clever scheme, with really smart people behind it.

I expect a smashing success, and the only thing IMO they should do in addition is try for low friction payment as well, so that those who WOULD want to pay (couched in terms of "2 lattes" or something like that) can easily put in their credit card #.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 21 Nov 2014 15:24:27 +0100

On Thu, Nov 20, 2014 at 09:23:33PM -0800,
 Christian Huitema <[email-masked]> wrote 
 a message of 29 lines which said:

> This would change if there was an easy way to detect that the site
> intended to use self-sign cert.

That's precisely what RFC 6698 does... Deploying this standard-track
RFC would help a lot more than creating a new CA (we already have a
gratis and automatic CA, CAcert).

---

From: Ben Laurie <[email-masked]>
Date: Fri, 21 Nov 2014 14:26:15 +0000

On Fri Nov 21 2014 at 2:18:19 PM Nicholas Weaver <[email-masked]>
wrote:

> > Of course, if that is the test that is used, this sort of cert is no
> better than a DANE cert.   I guess the one advantage is that it doesn't
> require DNSSEC.
>
> Given that, because this will be cross signed (agreements are already in
> place) as well as an accepted root, this will be accepted by effectively
> all browsers, while ~1% of systems measured can not get DNSSEC information
> period.
>

Our somewhat-out-of-date tests indicated ~4%.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 21 Nov 2014 10:25:55 -0500

Sent from my iPhone

> On Nov 21, 2014, at 9:11 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

That's in line with consensus from the STRINT workshop.  Fallback to unauthenticated crypto would appear to the user same as an http session.

Regards,
Kathleen

---

From: Patrick McManus <[email-masked]>
Date: Fri, 21 Nov 2014 10:39:44 -0500

On Fri, Nov 21, 2014 at 10:25 AM, Kathleen Moriarty <
[email-masked]> wrote:

> That's in line with consensus from the STRINT workshop.  Fallback to
> unauthenticated crypto would appear to the user same as an http session.

I bet we're on the same page, but I think there is a little potential
confusion in that statement that I want to clarify.

https:// cannot fallback to unauthenticated crypto and automatically change
the scheme to http:// when it does so for at least 2 reasons:

1] https:// demands authenticated crypto and the users of those links
expect that property and we want to promote that

2] https://foo/bar and http://foo/bar are simply different origins and
independent resources. There is nothing about the web model that says they
carry the same content over different transports despite our intuition when
looking at them. So we can't go automatically converting from one to the
other and have web compatibility unless the server issues a redirect.

Instead of being a fallback for https, O-S is an opportunistic upgrade for
otherwise plaintext http://.. ciphertext is the new plaintext for http://
and it isn't treated any differently in the UI because of it. https:// urls
with self signed certificates will continue to get giant warnings even in
the presence of O-E; nothing about https:// handling changes.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 21 Nov 2014 11:38:26 -0500

On 11/21/14, 9:24 AM, Stephane Bortzmeyer wrote:
> On Thu, Nov 20, 2014 at 09:23:33PM -0800, Christian Huitema
> <[email-masked]> wrote a message of 29 lines which said:
> 
>> This would change if there was an easy way to detect that the
>> site intended to use self-sign cert.
> 
> That's precisely what RFC 6698 does... Deploying this
> standard-track RFC would help a lot more than creating a new CA (we
> already have a gratis and automatic CA, CAcert).

Correct me if I'm wrong but there's not much EFF, Mozilla, et al. can
do to directly catalyze deployment of DANE.

And the Let's Encrypt effort will be both a new CA that I expect to be
more widely supported than CAcert [1] but also a highly-usable
doman-validation tool similar to sslmate (check that out if you have not).

best, Joe

[1]: http://wiki.cacert.org/InclusionStatus

- -- 
Joseph Lorenzo Hall
Chief Technologist

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 21 Nov 2014 17:40:10 +0100

On Fri, Nov 21, 2014 at 11:38:26AM -0500,
 Joseph Lorenzo Hall <[email-masked]> wrote 

> do to directly catalyze deployment of DANE.

Quite the contrary. Mozilla, for instance, could include DANE support
in Firefox.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 21 Nov 2014 12:01:30 -0500

On Fri, Nov 21, 2014 at 10:39 AM, Patrick McManus <[email-masked]> wrote:
>
> On Fri, Nov 21, 2014 at 10:25 AM, Kathleen Moriarty
> <[email-masked]> wrote:
>>
> 1] https:// demands authenticated crypto and the users of those links expect
> that property and we want to promote that
>

Thanks, Patrick.  As long as OS doesn't look the same to the user as
an authenticated encrypted session... so not fallback (wrong term),
but OS might look the same as HTTP.  Sounds good, thanks for your work
on this effort!

Kathleen

-- 

Best regards,
Kathleen