Subject: Mandatory encryption as part of HTTP2

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 14 Nov 2013 21:42:41 +0100

Forgive me if this has been discussed before, but I haven't been active on this list for a while and I didn't see subject lines that indicated recent discussions on this.

Apparently the chair of the httpbis wg is proposing to make encryption a mandatory part HTTP version 2:

http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0625.html

I have many medium-sized problems with this, including the issues with CAs, the additional fragility of depending on certs with limited lifetimes, performance and energy efficiency issues (both the batteries in mobile hosts and the power use in datacenters), severely reduced cacheability and debugging which are reasonable tradeoffs when privacy and authentication are needed, but are wasteful when they're not, which is still very often the case.

But a more fundamental problem with this approach is that it ties HTTP2 to TLS, while TLS is not a very good technology, except that it has proven easy to deploy. When we finally figure out how to get IPsec deployed as a general purpose solution for privacy and authentication, it would be quite annoying to have to run TLS, too, because HTTP2 requires it.

I'm not entirely sure why the existing problematic solution with certs and CAs was proposed here, as the intended goal, keep the NSA and friends out of our business, would be hard to reach that way. Using some kind of opportunistic encryption would serve that purpose much better, IMO.

(However, I do think there is value in making it possible to enable encryption when needed/desired without requiring the use of the https URL scheme.)

Deliberating exactly these kinds of issues is why the IAB gets paid the big bucks. So I hope the IAB can take on this issue.

Iljitsch

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 14 Nov 2013 13:47:40 -0700

On 11/14/13 1:42 PM, Iljitsch van Beijnum wrote:
> Forgive me if this has been discussed before, but I haven't been 
> active on this list for a while and I didn't see subject lines
> that indicated recent discussions on this.

There was a lively HTTP WG session in Vancouver on this topic, and I
suggest that we use the ietf-http-wg list for further discussion. IMHO
it is not yet an IETF-wide topic.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: <[email-masked]>
Date: Fri, 15 Nov 2013 04:41:18 +0000

+1

mandating encryption is unwise.

Make encrytpion attractive. Make it easy to use and to deploy. Make the risks of not adopting encryption clear.

But NEVER make it mandatory.

Lloyd Wood
http://sat-net.com/L.Wood/

If we had widespread encryption earlier, we wouldn't have an open web.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Iljitsch van Beijnum [[email-masked]]
Sent: 14 November 2013 20:42
To: [email-masked]
Cc: [email-masked]
Subject: Mandatory encryption as part of HTTP2

Iljitsch

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 23:14:13 -0800

Please follow on the HTTPbis list and contribute there.
We don't need to rehash this again here.
-=R

On Thu, Nov 14, 2013 at 8:41 PM, <[email-masked]> wrote:

> Forgive me if this has been discussed before, but I haven't been active on
> this list for a while and I didn't see subject lines that indicated recent
> discussions on this.
>
> I have many medium-sized problems with this, including the issues with
> CAs, the additional fragility of depending on certs with limited lifetimes,
> performance and energy efficiency issues (both the batteries in mobile
> hosts and the power use in datacenters), severely reduced cacheability and
> debugging which are reasonable tradeoffs when privacy and authentication
> are needed, but are wasteful when they're not, which is still very often
> the case.
>
> But a more fundamental problem with this approach is that it ties HTTP2 to
> TLS, while TLS is not a very good technology, except that it has proven
> easy to deploy. When we finally figure out how to get IPsec deployed as a
> general purpose solution for privacy and authentication, it would be quite
> annoying to have to run TLS, too, because HTTP2 requires it.
>
> I'm not entirely sure why the existing problematic solution with certs and
> CAs was proposed here, as the intended goal, keep the NSA and friends out
> of our business, would be hard to reach that way. Using some kind of
> opportunistic encryption would serve that purpose much better, IMO.
>
> (However, I do think there is value in making it possible to enable
> encryption when needed/desired without requiring the use of the https URL
> scheme.)
>
> Deliberating exactly these kinds of issues is why the IAB gets paid the
> big bucks. So I hope the IAB can take on this issue.
>
> Iljitsch
>

---

From: <[email-masked]>
Date: Fri, 15 Nov 2013 10:33:21 +0000

I was making a general point wider than the specific example of httpbis.

That point is well worth making here.

Lloyd Wood

________________________________________
From: Roberto Peon [[email-masked]]
Sent: 15 November 2013 07:14
To: Wood L  Dr (Electronic Eng)
Cc: [email-masked]; IETF Discussion; [email-masked]
Subject: Re: Mandatory encryption as part of HTTP2

On Thu, Nov 14, 2013 at 8:41 PM, <[email-masked]<mailto:[email-masked]>> wrote:
+1

Lloyd Wood

If we had widespread encryption earlier, we wouldn't have an open web.
________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of Iljitsch van Beijnum [[email-masked]<mailto:[email-masked]>]
Sent: 14 November 2013 20:42
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Mandatory encryption as part of HTTP2

Iljitsch

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 15 Nov 2013 12:14:09 +0100

> If we had widespread encryption earlier, we wouldn't have an open web.

These are the types of claims we will never find out whether they are 
true or not (even though it is not even clear what you mean by 'open' 
here and whether it refers to the confidential communication between the 
browser and the Web site).

We mandate other things in protocol specification as well (that aim to 
take performance, for example, to a specific level) then why not also 
certain security features.

Ciao
Hannes

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 15 Nov 2013 13:55:18 +0100

On 15 nov 2013, at 12:14, Hannes Tschofenig <[email-masked]> wrote:

> We mandate other things in protocol specification as well (that aim to take performance, for example, to a specific level) then why not also certain security features.

I'm all for mandating certain security features. A big part of that is not having insecure stuff in version 1 of protocols, because once the can is open, the worms never (completely) crawl back in. However, mandates in the form "if you do X you may only do it in manner Y" don't mean much, because the IETF has no real-world power beyond the text of its specifications.

That aside, just saying "you MUST do TLS with HTTP/2.0" doesn't buy much security in a world where CAs are not trustworthy, people still use RC4/MD5, use woefully short keys for otherwise strong algorithms, browsers have effectively trained people to always click "visit anyway" and so on.

Also, there are cases where encryption isn't needed, and cases where it's not desired. An example close to home: a while back, some IETF meeting related page, the agenda perhaps, would only be available over HTTPS. And it was extremely slow. Not sure if this was because the server was overloaded, session keys were negotiated every time (which shouldn't be necessary) or the page wouldn't be cached (which should be possible), but the end result was that a static file that is available to everyone without credentials was much harder to access for no benefit. Unless you pad all your pages as well as their URLs to the same length, it's trivial for snoops to see who got which page simply by observing the length of the exchange.

With security, the perfect tends to be the enemy of the good. Let's focus our efforts on getting everything encrypted that needs to be encrypted, and do so according to the state of the art rather than sloppily as often happens today, rather than fight over whether people get to serve unencrypted stuff over HTTP/1.1 or HTTP/2.0. "Encrypt everything" makes for a good soundbite, but it's a terrible policy.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Nov 2013 08:07:28 -0500

On Fri, Nov 15, 2013 at 7:55 AM, Iljitsch van Beijnum <[email-masked]>wrote:

> I'm all for mandating certain security features. A big part of that is not
> having insecure stuff in version 1 of protocols, because once the can is
> open, the worms never (completely) crawl back in. However, mandates in the
> form "if you do X you may only do it in manner Y" don't mean much, because
> the IETF has no real-world power beyond the text of its specifications.
>
> That aside, just saying "you MUST do TLS with HTTP/2.0" doesn't buy much
> security in a world where CAs are not trustworthy, people still use
> RC4/MD5, use woefully short keys for otherwise strong algorithms, browsers
> have effectively trained people to always click "visit anyway" and so on.
>

Well fortunately we don't live in that world.

How many security vulnerabilities does Microsoft patch every month? how
many does Cisco patch? how many do the browser vendors patch? How about
Apple?

How many are known but not patched?

I know it is the fashionable and popular thing to blather on about CAs but
our industry can count the number of failures. That is not something the
rest of the industry can claim.

PKIX has a mechanism for dealing with failures in the trust system
including the far more common failures as system managers lose control of
keys and legitimately credentialed subjects defect. One might think that if
there was really a problem in the CA system that browser providers would be
anxious to implement revocation properly but instead many are moving to
abandon it.

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Nov 2013 08:29:42 -0500

On Fri, Nov 15, 2013 at 6:14 AM, Hannes Tschofenig <
[email-masked]> wrote:

> These are the types of claims we will never find out whether they are true
> or not (even though it is not even clear what you mean by 'open' here and
> whether it refers to the confidential communication between the browser and
> the Web site).
>

Rob McCool and myself were implementing public key systems on the Web back
in 1993-4. So were EKR and Alan Schifman at EIT.

Have you ever tried to do RSA1024 on a 20MHz machine? How many connections
do you think can be supported on a 200MHz server?

The reason the Web does not have built in crypto is due to the problems of
performance and key distribution. The SSL ecology is not designed to
provide confidentiality except as a side effect. It was designed to make
shopping online as safe as shopping in a store.

What the 'SSL everywhere' schemes are offering is more encryption but with
a weak or non existent authentication model. That is ok if all SSL
everywhere is intended to do is to replace traffic that is currently sent
en-clair without authentication. But this is a weaker security control than
current SSL.

Deferring the hard problems till later is the reason the Web works.
Attempting to boil the ocean is the reason Xanadu could never be finished.
We can make very definite statements about what was practical in 1993.

The strategy is very interesting, the claim is that HTTP 2.0 with SSL is
just as fast as HTTP 1.0. Which sounds good until you remember that the
purported benefit of HTTP 2.0 is performance rather than security.

That might turn out to be a problem.

---

From: Yaakov Stein <[email-masked]>
Date: Fri, 15 Nov 2013 13:54:33 +0000

> That aside, just saying "you MUST do TLS with HTTP/2.0" doesn't buy much security in a world 
> where CAs are not trustworthy, people still use RC4/MD5, use woefully short keys for 
> otherwise strong algorithms, browsers have effectively trained people to always click 
> "visit anyway" and so on.

I believe that this proposal was in line with Bruce Schneier's suggestion at the plenary.
Do anything to make more work for people trying to listen in to everything on the Internet.

For example, put a key at the top of the content and then encrypt using this key.
This is meaningless from the confidentiality point of view, 
but eats up computational resources and energy for someone trying to vacuum up everything.

Even better - when you don't have anything to transmit, send meaningless supposed encrypted packets. 
If everyone did this their storage costs would skyrocket.
Even better, send packets with easily broken encryption containing keywords of interest.

Y(J)S

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 15 Nov 2013 15:29:57 +0100

Am 15.11.13 13:55, schrieb Iljitsch van Beijnum:
> That aside, just saying "you MUST do TLS with HTTP/2.0" doesn't buy
> much security in a world where CAs are not trustworthy, people still
> use RC4/MD5, use woefully short keys for otherwise strong algorithms,
> browsers have effectively trained people to always click "visit
> anyway" and so on.

That's a common argument I hear. We cannot do "X" because there is also 
this security issue with "Y". With that approach you will never get 
anything done.

For that reason our approach to improve the design of new protocols 
(like HTTP2) and at the same time try to improve the CA eco-system as 
well. In fact, we even have a work item on that topic within the 
recently created IAB security program, which I happen to lead.

> With security, the perfect tends to be the enemy of the good.

With the current state of security of the Internet, as we clearly get 
demonstrated right now, I don't think we are talking about the "perfect" 
here at all.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 15 Nov 2013 15:42:41 +0100

Am 15.11.13 14:38, schrieb JFC Morfin:
> because the IETF has no real-world power beyond the text of its
> specifications.

That's also incorrect.

We have people working in the IETF who not just here to write documents 
but who actually have interest to implement the protocols and to deploy 
them. Of course, the entire eco-system is complex and every area of work 
has it's own challenges but we are constantly seeing IETF folks reaching 
out to implementers and communities who deploy IETF technology.

Just to give you one example: Peter, who had been working in the IETF on 
XMPP standards, recently distributed a manifesto, which encourages those 
who deploy XMPP servers to improve their security. Since he is in close 
contact with the XMPP community I expect that many will follow his call 
for action.

Here is the manifesto, in case you are interested: 
https://github.com/stpeter/manifesto/blob/master/manifesto.txt

He also created a test site, an IM Observatory, so you can get your XMPP 
security evaluated: http://xmpp.net/

What we do, however, need is more people who take action.

Ciao
Hannes

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Nov 2013 09:43:37 -0500

On Fri, Nov 15, 2013 at 8:54 AM, Yaakov Stein <[email-masked]> wrote:

> security in a world

I made a similar proposal at the link layer, which I think is where things
like flood fill really belong.

At the HTTP layer, there is no point in passing raw keys in band. At least
do a DH exchange.

The problem I have with TLS everywhere is that TLS is a pretty heavy
protocol stack with a huge amount of complexity and HTTP/2.0 is meant to be
reducing complexity. I think what the people are really trying to do is to
optimize HTTP for the narrow use case they are familiar with. Which is not
what I want which is to reduce the complexity.

I recently proposed a fix for HTTP authentication cookies that exchanges a
key in-band:

https://datatracker.ietf.org/doc/draft-hallambaker-httpsession/

Now that scheme could be easily modified to add in a D-H exchange so as to
provide ephemeral keying and defend against pervasive attack. And it would
be very easy to add in encryption of the message content. In fact the
original prototype actually did just that. It is even possible to specify a
new key with the content which allows cached content to be encrypted.

This approach gives all the security advantages of weak-SSL-everywhere
without the cost of kicking the proxies in the head and disrupting caching
and all the other problems that the proposaed change in the security model
will cause.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 15 Nov 2013 15:43:41 +0100

Yaakov, you have very nicely summarized the strategy: We need to make 
attacks more expensive.

---

From: Steve Crocker <[email-masked]>
Date: Fri, 15 Nov 2013 11:56:14 -0300

I've been watching this thread for a while.  The idea of making it harder without actually expecting the encryption to work seems like an implicit admission of failure.  I think the right posture is to make privacy via encryption the default at every level, or perhaps even mandatory, and to expect it to work.  Key management has to be seamless and automatic, and the software and hardware have to be trusted.  Let's button up the net and protect our communication from prying eyes, whether they be ISPs wanting to charge us for "high value" traffic, governments wanting to gather intelligence, or others.

There will still be lots of information that we can't easily protect, e.g. "metadata."  I am not worried about that even though that really does disclose a lot of information.  People who need anonymity or other strong protection will need to use special services or third parties, just the way they do in real life.

This my personal view and does not represent anyone else's.  In particular, I am not speaking for ICANN in this note.

Steve

On Nov 15, 2013, at 11:43 AM, Hannes Tschofenig <[email-masked]> wrote:

> Yaakov, you have very nicely summarized the strategy: We need to make attacks more expensive.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Nov 2013 10:29:27 -0500

On Fri, Nov 15, 2013 at 9:56 AM, Steve Crocker <[email-masked]> wrote:

> I've been watching this thread for a while.  The idea of making it harder
> without actually expecting the encryption to work seems like an implicit
> admission of failure.

+1

> I think the right posture is to make privacy via encryption the default at
> every level, or perhaps even mandatory, and to expect it to work.  Key
> management has to be seamless and automatic, and the software and hardware
> have to be trusted.

+1

The question is what the attack model is and how we measure the work factor.

By 'secure' we mean 'increase the work factor to an infeasible level'. This
is how the NSA thinks about systems when it is protecting them rather than
trying to break them. I do not hold any security clearances and never have
but I do have that part of NSA doctrine from multiple sources at the very
highest levels in the organization.

Under the old metric the objective was to increase the cost of an attack to
some multiple of the GNP of all potential adversaries for some number of
years. Deciding on the work factor for the crypto part of the problem is
really easy as there is virtually no cost to increasing the work factor
exponentially. The hard part has always been calibrating the interface
between the crypto and the real world. That is the WebPKI.

The attack model that the WebPKI was calibrated against was an organized
criminal attack against commercial assets.

Pervasive monitoring is a different attack. The attacker brings a different
set of resources and has different goals and costs.

I have it on very high authority that the NSA is going to consider the risk
of being caught as being far higher in the future. They have been caught
twice through technical measures (StuxNet, Flame) and now they understand
that they face an insider threat.

A trust management scheme that is vulnerable to active attack is completely
unacceptable against a commercial attacker. We have numerous cases where
that type of attack has been used.

Active attack is also unacceptable as a control against targeted attack.
And anyone who participates in IETF security area at a certain level is
possible a target of attack.

A scheme that forces an attacker to perform an active attack rather than a
passive one is empirically a valuable control against covert passive
monitoring provided that it is backed up with controls capable of detecting
the active attacks and reporting them.

We need to be very clear about the difference between 'encryption
everywhere' and 'TLS everywhere'. While there are obvious commercial
advantages to a CA in TLS everywhere, I do worry that attempting that goal
might well end up with TLS being reduced in security strength to the lowest
common denominator.

In a complete security stack I would want all of the following encryption
controls in place simultaneously:

1) Link level encryption to defend against traffic analysis attack.
2) Transport layer Security to protect metadata against confidentiality and
integrity attacks
3) Message layer security to provide strong end-to-end confidentiality and
integrity

For Web services I would want multiple overlapping encryption protections
at the message layer. An email needs to be signed by both the sender and
the mail gateways it passes through.

---

From: Ted Faber <[email-masked]>
Date: Fri, 15 Nov 2013 08:45:37 -0800

> But NEVER make it mandatory.

Amen.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP:
http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See
http://www.isi.edu/~faber/FAQ.html#SIG

---

From: Roberto Peon <[email-masked]>
Date: Fri, 15 Nov 2013 09:01:15 -0800

The fact that you are ignoring the deployment reasons for using encryption,
which are orthogonal to any security reasons is part of the reason why it
is frustrating for me to not have you participate or at least read the
discussions going on within the httpbis list.

-=R
On Nov 15, 2013 4:55 AM, "Iljitsch van Beijnum" <[email-masked]> wrote:

> Also, there are cases where encryption isn't needed, and cases where it's
> not desired. An example close to home: a while back, some IETF meeting
> related page, the agenda perhaps, would only be available over HTTPS. And
> it was extremely slow. Not sure if this was because the server was
> overloaded, session keys were negotiated every time (which shouldn't be
> necessary) or the page wouldn't be cached (which should be possible), but
> the end result was that a static file that is available to everyone without
> credentials was much harder to access for no benefit. Unless you pad all
> your pages as well as their URLs to the same length, it's trivial for
> snoops to see who got which page simply by observing the length of the
> exchange.
>
> With security, the perfect tends to be the enemy of the good. Let's focus
> our efforts on getting everything encrypted that needs to be encrypted, and
> do so according to the state of the art rather than sloppily as often
> happens today, rather than fight over whether people get to serve
> unencrypted stuff over HTTP/1.1 or HTTP/2.0. "Encrypt everything" makes for
> a good soundbite, but it's a terrible policy.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 15 Nov 2013 11:52:30 -0800

> make privacy via encryption the default at every level, or perhaps
> even mandatory, and to expect it to work.  Key management has to be
> seamless and automatic, and the software and hardware have to be
> trusted.  Let's button up the net and protect our communication from
> prying eyes, whether they be ISPs wanting to charge us for "high
> value" traffic, governments wanting to gather intelligence, or
> others.

As a goal statement, the above seems to me one of the better and more 
concise summaries of the IETF community 'tone' right now.  And it 
certainly is extremely appealing.

And it's probably reasonable as a goal statement, as long as there is an 
understanding of the challenges in achieving it.  My own concern is less 
with whether, for any specific security enhancement, we are "expecting 
the encryption to work" but with what it will cost and whether it will 
be useful.

What I've noticed in most/all of the discussions surrounding the privacy 
concerns is a general lack of attention to limitations, tradeoffs or 
even outright barriers.  Discussions are being conducted as if every 
kind of security mechanism is cost-free, easy and useful.

A ready response to such concerns is that the community is interested in 
a "belts and suspenders" approach.  The problem with invoking that 
reference is that the functions of a belt and a suspender are 
well-understood, the use is cheap and easy, and the relationship between 
the two is also well-understood.

None of those properties apply for Internet-scale, mass-market 
application of widespread security mechanisms.  To date, the only 
mechanisms that qualify for this are, indeed, https to many (but not 
all) servers over the open Internet, and variations of SSL use with IMAP 
or POP, within subscribed environments.  I suppose use of IPSec for 
VPNs, within a relatively small range of enterprises also qualifies. 
But given the scope of what is currently being discussed, I'll suggest 
that this is actually a rather modest base of operational experience.

Security, in particular, can be extremely expensive.  I'm not so worried 
about computational cost -- although it can be significant -- but ops, 
admin and management cost for security are typically significant.

The reality is that these mechanisms often are expensive and sometimes 
are quite literally beyond the state of the art.  (Not just beyond 
current products, but actually beyond what research has yet 
demonstrated.)  The most notable piece that is beyond the state of the 
art is the entirely appropriate reference to neeing key management to be 
seamless.  Sorry, but we don't know how to do that.

So, what am I suggesting?

I'm suggesting that proposals be diligent in considering reasoanble 
drawbacks to implementation of the proposal.  How will an added 
mechanism be useful?  What sorts of attacks will it prevent?  What is 
the evidence that such attacks are already happening?  (That an attack 
hasn't been happening doesn't mean it should be ignored, but it does 
mean it is not known to be an immediate threat.)  What are the OA&M 
barriers to adoption and use?  What are the possible interaction effects 
with other security mechanisms?  What is the experiential base for the 
proposal and how will widespread deployment challenge that?

In other words, please stop looking only at ideal benefits and start 
considering serious pragmatics.

d/

ps. FWIW, I'm also concerned that nearly all discussions are about 
protecting one-hop transfers, with no real concern for exposures at the 
relaying point, where most violations actually occur...

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Martin Thomson <[email-masked]>
Date: Fri, 15 Nov 2013 11:56:19 -0800

On 15 November 2013 11:52, Dave Crocker <[email-masked]> wrote:
> concerns is a general lack of attention to limitations, tradeoffs or even
> outright barriers.

I disagree.  That seems to be near 100% of the discussion thus far in
HTTPbis, with just a few exceptions.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Nov 2013 15:06:43 -0500

> HTTPbis, with just a few exceptions.

The problem is that it takes rather longer to write about the limitations,
tradeoffs or barriers than say 'please don't kill the kitten'

---

From: Theodore Ts'o <[email-masked]>
Date: Fri, 15 Nov 2013 20:32:31 -0500

On Fri, Nov 15, 2013 at 11:56:14AM -0300, Steve Crocker wrote:
> I've been watching this thread for a while.  The idea of making it
> harder without actually expecting the encryption to work seems like
> an implicit admission of failure.

There's a question which is being begged here when using the
terminology "to work".  What's your definition of success?

For example, using D-H with no attempt to authenticate the endpoints
means does not protect you against an active attacker who is carrying
out a MITM attack.  However, it does protect you against a passive
attacker which is vaccuuming up all networking packets and either
looking for keywords or storing it all in some big data warehouse in
Utah.  It forces said attacker to play MITM games, with all of the
attendant costs of decrypting and re-encrypting all of the data
streams, such that the attacker would consume a lot more power, and
make it much harder for pervasive surveillance to be hidden in some
tiny phone closet in some telecom's fiber room.

The old world-view was if you couldn't protect against an active
attacker, you might as well not do anything at all.  So admitting
failure with the old world view, which required us to "go big or go
home" (with the result that in many cases vendors just went home, and
left huge portions of internet traffic completely unencrypted) might
be first step to wisdom.  We've tried things the old way, with the
result that IPSEC is so painful that it only gets used in a very
restricted problem domain such as VPN's.  Maybe it's time to try
something new, that indeed only makes things harder for pervasive
surveillance, without necessarily making it impossible against a
directed attack.

As far as I'm concerned, making things harder, even if it is not
guaranteed to protect against all attack scenarios, is an example of
something which works --- it works to protect against a specific
threat model that appears to be a real one that we need to be worried
about.

>  I think the right posture is to
> trusted.

I agree that we will probably need encryption at multiple levels; but
I also think we can't assume that software and hardware "have" to be
trusted.  The design must be robust, and not fragile, which is one of
ther reasons to have encryption at multiple layers.  It also means
that we should have at least one layer which doesn't assume (for
example) that we can trust that all 600+ CA's which are authorized to
certify all web sites in the world are trustworthy.  That's not an
admission of failure; that's an engineering design which is designed
to robust, in the face of failures, which *WILL* happen.

						- Ted

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 16 Nov 2013 01:41:31 +0000

> threat model that appears to be a real one that we need to be worried

Very well put.

For this community, this is *the* most important lesson to
learn from snowdonia.

> to robust, in the face of failures, which *WILL* happen.

Other than maybe s/600+ CAs/~100 organisations/ also true.

I hope a lot of people read the top half of this at least.

S.

---

From: Randy Bush <[email-masked]>
Date: Sat, 16 Nov 2013 10:55:08 +0900

ted, great post.

two things i might further stress.

encrypting as much as reasonably possible spreads the cash of the
pervasive passive attcker.

there may be 600+ 'trusted' CAs.  but what is actually used is a bit
surprising  
    "Analysis of the HTTPS Certificate Ecosystem",
    Z. Durumeric, J. Kasten, M. Bailey, J.A. Halderman (University of
    Michigan)
    http://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf
fix needed here.

randy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Nov 2013 22:11:16 -0500

> http://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf
Actually as has been demonstrated repeatedly, the EFF has been deceptive
bordering on outright dishonesty about the 600 CAs. Over 300 of what they
identified as separate CAs are all run by a single organization that hands
out certs to educational institutions in Germany. There is only one CA with
separate intermediate certs for each institution. At least 200 of the other
certificates they identify as 'CAs' have a similar origin.

What the EFF study measured was Certificate signing certs where the issuer
and the subject are different parties. That does not make them a CA with
authority to issue any cert for any web site. As has been confirmed in the
case of the German CA, and as the EFF could and should have checked
themselves, the German CA maintains full control of all the signing keys.

The EFF people could have checked this out very easily and despite
admitting that they can't support the claim in private refuse to make a
public correction. Which I think really damages their credibility. It is
the Fox News approach to lobbying.

The fact is that there is no way to measure what they are trying to measure
by looking at the issued certificates. Issuing an inaccurate figure and
then refusing to correct it is not acceptable.

---

From: SM <[email-masked]>
Date: Sat, 16 Nov 2013 09:35:02 -0800

Hi Phillip, Ted,
At 19:11 15-11-2013, Phillip Hallam-Baker wrote:
>Actually as has been demonstrated repeatedly, the EFF has been 
>deceptive bordering on outright dishonesty about the 600 CAs. Over 
>300 of what they identified as separate CAs are all run by a single 
>organization that hands out certs to educational institutions in 
>Germany. There is only one CA with separate intermediate certs for 
>each institution. At least 200 of the other certificates they 
>identify as 'CAs' have a similar origin.

I don't have any material interest in the EFF or any CA.

I did a quick check and I found 165 CAs.  I didn't look into the 
details of the number of CAs linked to a single organization.

Regards,
-sm

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 16 Nov 2013 15:11:34 -0500

On Sat, Nov 16, 2013 at 12:35 PM, SM <[email-masked]> wrote:

> I did a quick check and I found 165 CAs.  I didn't look into the details
> of the number of CAs linked to a single organization.
>

But as is well known, many CAs own multiple embedded roots, typically three
or four brands per large CA and each brand often has several roots. The
conclusion that the EFF has been peddling is that there are 600 parties
that can introduce spurious certs, this is not what their evidence
demonstrates.

My point was that like the 'Gore claimed to invent internet meme' this has
become a zombie lie that is repeated by people despite the fact that it has
been repeatedly shown to be false. People like to believe it because it
reinforces their prejudices but that does not make it true.

We should not be making policy decisions on the basis of zombie lies.

---

From: Theodore Ts'o <[email-masked]>
Date: Sat, 16 Nov 2013 17:08:23 -0500

> We should not be making policy decisions on the basis of zombie lies.

Whether the number is 100, or 600, or a thousand (and note that even
if there are dozens or even hundreds of CA's being run by one
"organization", those CA's may be run by different personnel, and have
different policies, and have their certificate signing keys stored in
different ways (i.e., some may be stored on some minimum wage worker's
laptop; others may be stored in some Tempest Shielded fancy-shamancy
BBN secure signing box requiring multiple crypto ignitition keys
before certificates can be issued) --- how you count the CA's or
organizations I don't think is really all that important.  Even if
it's only 100 organizations, or even 50, do you really believe they
can all be trusted, and are you willing to assert that they will all
never having any process or technological failures?

And if you believe that all dozen, or 50, or 100 certificate
organizations can be considered trustworthy, care to explain some of
the more spectacular failures (i.e., Comodo, Diginotar, etc.)?

Quibbling over numbers doesn't change the the fundamental premise,
which is that the certificate signing architecture for the web is
considered by some (including myself), to be pretty badly broken.

Regards,

							- Ted

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 16 Nov 2013 23:00:54 -0500

> never having any process or technological failures?

Well first I think that it is important to use facts when making decisions.
When someone misrepresents the facts by an order of magnitude and refuses
to correct it after it has been demonstrated to be false, that is a data
point.

If you are interested in the technical criteria for running a public CA
then go look at the Basic Requirements on the CABForum Web site and they
will answer all the hypotheticals you raise above.

Nobody uses the BBN Tempest shielded box any more as it hasn't been made in
a decade. They do use FIPS certified hardware though.

I am far more certain of the ability of CAs to do their job than any other
potential point of failure. I don't have absolute trust but I trust them
more than I trust the end-points. I am also rather concerned about the
black box crypto hardware we have to use. But right now there isn't a
better alternative.

> the more spectacular failures (i.e., Comodo, Diginotar, etc.)?

How many CERT reports of significant security holes are filed on Linux
every month? Care to explain them?

You think you are making a strong argument but the only reason the CA
issues received notice is that they are so very unusual. Software security
disasters are a daily occurrence.

> considered by some (including myself), to be pretty badly broken.

Pointing out that you are repeating a propaganda point that has been proved
false is not quibbling over details. If you want to make the case against
my industry then you need to check the figures you use as carefully as you
would check a PGP key before signing it.

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 17 Nov 2013 17:09:21 +0900

> considered by some (including myself), to be pretty badly broken.

To say so, one CA under US legislation or one CA using key
handling hardware made by a company under US legislation
is a lot more than enough.

						Masataka Ohta

---

From: Yoav Nir <[email-masked]>
Date: Sun, 17 Nov 2013 08:20:20 +0000

Hi, phil

I think we all agree that there are not 600 root CAs (just looking at the root store of your favorite OS or browser shows that), and the actual number of organizations is "only" several dozens. 

What both the EFF and this discussion are missing, is that the number of organizations running root CAs is not the biggest part of the problem. In addition to the root CAs, the big organizations have sub-CAs and RAs. I trust you remember that ComodoHacker did not actually hack Comodo. He hacked instantssl.it.  And those researchers didn't trick Verisign into signing a sub-CA certificate using an MD5 collision, they did it to RapidSSL[1].

So how many InstantSSL.it and RapidSSLs are there? Don't they outnumber the root CAs? Are they subject to the same rules set by the CABF? NameConstraints are very rare on the web, so these Sub-CAs or RAs can issue a certificate for anything. Isn't that right?

Yoav

[1] Is it just my imagination, or do the names of CAs indicate that marketing believes that quickly getting the cert is the only thing that customers care about?

---

From: Randy Bush <[email-masked]>
Date: Sun, 17 Nov 2013 18:30:04 +0900

i'll try once again,

randy

---

From: SM <[email-masked]>
Date: Sun, 17 Nov 2013 02:03:33 -0800

Hi Yoav,
At 00:20 17-11-2013, Yoav Nir wrote:
>[1] Is it just my imagination, or do the names of CAs indicate that 
>marketing believes that quickly getting the cert is the only thing 
>that customers care about?

According to 
http://support.godaddy.com/godaddy/get-near-instant-gratification-with-our-extended-validation-ssls/ 
it has something to do with near-instant gratification.

Regards,
-sm

---

From: Yoav Nir <[email-masked]>
Date: Sun, 17 Nov 2013 11:16:21 +0000

On Nov 17, 2013, at 12:03 PM, SM <[email-masked]> wrote:

> According to http://support.godaddy.com/godaddy/get-near-instant-gratification-with-our-extended-validation-ssls/ it has something to do with near-instant gratification.
> 

Makes sense. When IT departments forget to get a new certificate in time, and learn about it when users complain, it's not a pretty sight. They want their instant gratification. :-)

---

From: mutek <[email-masked]>
Date: Sun, 17 Nov 2013 13:15:32 +0100

> considered by some (including myself), to be pretty badly broken.

there is another point to take into account:

switching to a CA based web means kill the natural peering nature of the web

I can easy publish a plain http html page on my router without ask for permission at any CA out there and the client Firefox shows it

forcing a new crypto-web based on the actual CA multilevel grants could kill the web as we know now

Luca

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 17 Nov 2013 08:28:02 -0500

> is a lot more than enough.

This discussion really belongs on the PERPASS list.

Remember that as far as the US is concerned, the only is covert
surveillance. The NSA is not going to attempt any operation if they believe
that the risk of getting caught.

This is why transparency schemes such as CT are interesting.They don't
prevent the attack but they deter it by raising the probability of being
caught to 1.

One of the reasons that we are in this situation is that the highest levels
of the NSA had a very shallow and ignorant understanding of what the
Internet is. They only seem to understand defense as a tactical move to
protect the ability to attack. Which is probably why they didn't bother to
take the rather trivial efforts it would have required to prevent
Snowdonia. They certainly have not been doing what they should have and
protecting critical infrastructure from attack.

They do understand that it will be at least two Congresses before they have
the chance for further increasing their legal authority. We have until 2017
to lock down the net and render any such capabilities moot.

But I think it very likely that by that time the organization of the NSA
will be very different.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 17 Nov 2013 08:41:19 -0500

On Sun, Nov 17, 2013 at 3:20 AM, Yoav Nir <[email-masked]> wrote:

> Hi, phil
>
> I think we all agree that there are not 600 root CAs (just looking at the
> root store of your favorite OS or browser shows that), and the actual
> number of organizations is "only" several dozens.
>
> What both the EFF and this discussion are missing, is that the number of
> organizations running root CAs is not the biggest part of the problem. In
> addition to the root CAs, the big organizations have sub-CAs and RAs. I
> trust you remember that ComodoHacker did not actually hack Comodo. He
> hacked instantssl.it.  And those researchers didn't trick Verisign into
> signing a sub-CA certificate using an MD5 collision, they did it to
> RapidSSL[1].
>
> So how many InstantSSL.it and RapidSSLs are there? Don't they outnumber
> the root CAs? Are they subject to the same rules set by the CABF?
> NameConstraints are very rare on the web, so these Sub-CAs or RAs can issue
> a certificate for anything. Isn't that right?
>

The reason that name constraints were not very common on the web was that
the PKIX specification requires them to be marked critical which makes them
unusable as there is enough legacy infrastructure that does not recognize
them and will reject NCs marked critical to make this unacceptable.

The industry has found a solution which is to ignore the PKIX
specification. According to the industry standard, it is now acceptable to
use NCs that are not marked critical. The IETF can correct the spec or not,
but that is now the de facto standard.

Also according to the requirements of Mozilla and other browsers, any party
that has the capability of issuing certificates under a root has to be
audited. I can't tell you if the transition process is complete or not,
there are so many deadlines for different things I can't keep them all
straight.

So hopefully the number of those parties is currently zero. But that does
not rule out the possibility of a Flame like situation.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 17 Nov 2013 08:50:49 -0500

> http://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf

Their number of intermediate certs is more accurate. But they make the same
mistake of conflating an intermediate cert with control of a CA. Also
rather odd to be talking about VeriSign which has not been in the CA
business for three years now.

The DFN root which has 300+ members issues an intermediary cert to every
university in its network. But they maintain full control of all the
private keys and these reside in the same type of secure crypto hardware as
the embedded root.

The reason this is done is to enable access control restrictions of the
type 'only to a site in my university'.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 17 Nov 2013 09:00:42 -0500

On Sun, Nov 17, 2013 at 7:15 AM, mutek <[email-masked]> wrote:

> I can easy publish a plain http html page on my router without ask for
> permission at any CA out there and the client Firefox shows it
>

They can't do that. The most they can do is to write a document that
requires use of TLS to do HTTP/2.0. Which not incidentally is exactly what
was originally tried with IPSEC and IPv6.

What I predict the outcome of such a choice would be is takeup of HTTP 2.0
limited to very large sites. Which does not seem to worry the companies
active in the HTTP/2.0 work.

Fortunately that is not the only option for preventing passive
surveillance. We could add an ephemeral DH keying mechanism to HTTP/1.1 and
encrypt only the content. This does not protect metadata in the headers but
does limit the scope of hoovering the net very greatly.

Security is hard and right now TLS is the only security mechanism that is a
success. Whatever else we do in response to Snowdonia, we must not weaken
TLS to make it practical to use pervasively.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 17 Nov 2013 08:37:42 -0800

On Nov 16, 2013, at 8:00 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> If you are interested in the technical criteria for running a public CA then go look at the Basic Requirements on the CABForum Web site and they will answer all the hypotheticals you raise above.

... but only for organizations that have joined the CABForum and abide by its guidelines, which is a subset of the CAs trusted by the browsers.

As far as I can tell from the public CABForum web site, a member CA not following the guidelines would not necessarily be thrown out of the group (but I would be happy to be mistaken about that).

--Paul Hoffman

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 18 Nov 2013 07:12:50 +0900

Theodore Ts'o wrote:

> out a MITM attack.

That being said, the problem for PKI is that, assuming active
MITM attacks both on ISP chains and CA chains, it offer no
better security than DH,

As DH involves end systems only, there is no point of deploying
PKI with no additional benefits.

						Masataka Ohta

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 17 Nov 2013 23:23:10 +0100

I know that it is very popular to bash the PKI system but there are
security differences between an anonymous DH and PKI deployment that
provides server-side authentication.

And: Keep in mind that we have various activities in the IETF ongoing
that help to improve the security of the PKI.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 18 Nov 2013 07:23:16 +0900

> http://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf

It correctly states:

	1,800 entities that are able to issue
	certificates vouching for the identity of any website

that is one insecure entity is a lot more than enough.

Phillip Hallam-Baker wrote:

> Their number of intermediate certs is more accurate. But they make
> the same mistake of conflating an intermediate cert with control
> of a CA.

Why do you insist on counting the number of Angels when just one
fallen one is a lot more than enough?

A CA a few key managing personnel of which are under US legislation
is a lot more than enough.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 18 Nov 2013 07:43:12 +0900

> provides server-side authentication.

Assuming active MITM attacks both on ISP chains and CA chains,
what, do you think, are the differences?

A concrete example is especially welcome.

Note that we, none US citizens, must expect such attacks, because
active MITM attacks of NSA on people without US citizenship are,
under US legislation, even legal.

> that help to improve the security of the PKI.

As PKI is fundamentally insecure against active attacks, there is
no point of improving it.

I do realize stupidity level of IETF, especially on DNSSEC.

						Masataka Ohta

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 18 Nov 2013 00:01:29 +0100

I am also worried about the developments with the NSA. I guess we are on
the same page there.

The PKI concept by itself does not say how many trust anchors you need
to use at your client. You are complaining about the way how the WebPKI
looks like and how the CA/Browser Forum is handling their business.
Allowing new trust anchors to be added means giving new CAs a chance to
enter the market. Let's say we only have one trust anchor. Would you
like that more? Probably not. I am not saying that there are issues with
the CA/Browser Forum but it is just difficult to pick the right number
of trust anchors in a browser.

One challenge is, of course, nobody trust every CA and the intersection
of what everyone's trusted CA list is the empty set. That may give you
the impression that the PKI model is inadequate and there are, of
course, other models as well that provide different properties (for
example, the AAA model). I am not sure you will find them appropriate
either. Have you had a chance to look at them?

There have been various ideas on how to improve the PKI, and the IAB has
a security program that aims to make some progress in that area. I am
currently working on a draft update of
http://tools.ietf.org/html/draft-tschofenig-iab-webpki-evolution based
on the feedback I have received. Have you had a chance to look at the
different approaches people had suggested?

Finally, in your threat model, however, the use of a DH will also not
help since you have, as stated, the MITM attack at the ISP.

Ciao
Hannes

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 18 Nov 2013 08:37:25 +0900

Hannes Tschofenig wrote:

> enter the market.

Why do you insist on counting the number of Angels so much?

> Let's say we only have one trust anchor.

A CA under US legislation, a CA key management hardware/software
is developed by a company under US legislation or a CA a few
key managing personnel of which are under US legislation is
a lot more than enough.

Note that root zone of DNSSEC is managed by ICANN/ISOC incorporated
in US.

> a security program that aims to make some progress in that area.

I'm tired of reading lengthy abstract nonsenses.

A simple and concrete example could help you convince people.

> I am
> on the feedback I have received.

A draft with 19 pages is already too bad on such a simple
problem only to have obscurity instead of security.

> help since you have, as stated, the MITM attack at the ISP.

As I wrote in a recent mail:

   the problem for PKI is that, assuming active
   MITM attacks both on ISP chains and CA chains, it offer no
   better security than DH,

my point is that complex PKI, which you are trying to make even
more complex, is no more secure than simple DH.

It does not mean DH is very secure.

						Masataka Ohta

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 17 Nov 2013 19:05:04 -0500

> PKI with no additional benefits.

If we assume that the attack model is flying horses armed with lasers there
is no additional benefit.

The point is not what the consequences of the assumptions are, the question
is how likely the assumptions are. If you leave that out of the equation
then the result is nonsense.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 17 Nov 2013 19:20:43 -0500

> is a lot more than enough.

The four most widely used browsers are all produced by US companies.

If you posit an attack against the US CAs you must also accept that the NSA
could make the same threats against the browser providers which would have
the same effect with far less risk of being caught and far fewer
consequences to being caught.

If the NSA was to coerce a CA into issuing a false certificate I would
imagine their lawyers would point out to the court that doing so would
threaten the stability of the entire Internet economy and that if
discovered the CA would lose its business.

The NSA would then be facing the downside of a multi-billion dollar lawsuit
in public court. The very last thing they want to risk is their
unconstitutional search orders being litigated by a plaintiff with standing.

---

From: Theodore Ts'o <[email-masked]>
Date: Sun, 17 Nov 2013 19:49:07 -0500

> then the result is nonsense.

Actually, the attack was called "FLYING PIG" --- that was the GHCQ
code name, per the Snowden leaks[1].  Some have speculated that
Diginotar was so badly penetrated that it wasn't just the Iranians
which penetrated it, but the NSA/GHCQ as well.

One of the reasons why the bogus Diginotar certificates were detected
was because Google Chrome had a feature called "certificate pinning"
--- which is not a feature normally associated with PKI's.  It's
unfortunately not all that scalable, since it involved hard-coding
certificates, or their hashes, in the browser binary.  The challenge
is coming up with a solution that *is* more scalable, and less
dependent on trusting that CA's are competently run.

					- Ted

[1] http://www.techdirt.com/articles/20130910/10470024468/

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 18 Nov 2013 10:03:00 +0900

> The four most widely used browsers are all produced by US companies.

Open source helps a lot.

> consequences to being caught.

It does not deny my point that PKI is no better than DH.

> discovered the CA would lose its business.

Could you explain why google, apple, microsoft etc. did not behave so?

> unconstitutional search orders being litigated by a plaintiff with standing.

"would then be facing"??? If it's not "is now facing", then, it means
"will never face".

							Masataka Ohta

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 17 Nov 2013 20:24:47 -0500

> > The four most widely used browsers are all produced by US companies.

Not unless you compile your browser from source and verify the source each
time you compile. They have demonstrated an ability to hide compromise
pretty well.

> It does not deny my point that PKI is no better than DH.

You are conflating the possibility of an attack with the certainty of an
attack succeeding.

> Could you explain why google, apple, microsoft etc. did not behave so?

Subpoenaing the software providers and the CAs are two different issues.
Google could not credibly claim that its business would be destroyed if
PRISM was exposed but Symantec could and would make the claim that they
would lose a business unit they paid $1.2 billion for.

Issuing a bogus certificate is a very visible event. The NSA is very risk
averse when it comes to actions that are likely to be exposed.

---

From: Conrad Rockenhaus <[email-masked]>
Date: Sun, 17 Nov 2013 20:25:48 -0500

> > But NEVER make it mandatory.
This is the wisest statement I've seen on this thread.  Encryption is
wonderful but making it mandatory may cause unforeseen issues.

Respectfully,

Conrad Rockenhaus

http://www.rockenhaus.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 17 Nov 2013 20:32:34 -0500

> which penetrated it, but the NSA/GHCQ as well.

I think there are enough proven horrors in Snowdonia without speculating
additional ones.

> dependent on trusting that CA's are competently run.

Which is exactly what Ben Laurie and myself proposed some time ago in the
original CAA scheme which included cert pinning and a notification scheme.

Unfortunately that approach was deemed to conflict with DANE and so we were
forced to remove the feature. Which is a pity as the CAA pining scheme did
not depend on DNSSEC as a precondition.

Diginotar would have noticed the issue if they had been checking their OCSP
logs as well.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 18 Nov 2013 15:25:33 +0900

Phillip Hallam-Baker wrote:

> time you compile.

Wrong, because your compiler may also be compromised.

	http://en.wikipedia.org/wiki/Backdoor_%28computing%29

	Thompson's paper describes a modified version of the Unix C
	compiler that would:

		Put an invisible backdoor in the Unix login command
		when it noticed that the login program was being
		compiled, and as a twist

		Also add this feature undetectably to future compiler
		versions upon their compilation as well.

> They have demonstrated an ability to hide compromise
> pretty well.

See above. I know better than you how to hide it.

Still, I can say open source helps a lot.

> You are conflating the possibility of an attack with the certainty of an

Assuming active MITM attacks both on ISP chains and CA chains, the
attacks on PKI always suceed.

> PRISM was exposed but

Are you saying that it's OK even though google's software business
has damaged a lot?

Note that google also has cloud provider business, which is also
damaged a lot.

> Symantec could and would make the claim that they

Because PKI business is a fallacy, they really don't loss any
real business.

> Issuing a bogus certificate is a very visible event.

Assuming active MITM attacks both on ISP chains and CA chains, the
attacks are invisible.

						Masataka Ohta

---

From: Yoav Nir <[email-masked]>
Date: Mon, 18 Nov 2013 06:40:09 +0000

> dependent on trusting that CA's are competently run.

Pinning every HTTPS certificate on the planet is not scalable. What you *can* do is have each site pin their site. That's the point of HPKP ([1]).

For this to work, you need to at some point be without the MITM. I guess that wouldn't help you much where MITM are pervasive, like Iran or Syria, but it would work where attacks are the exception.

Another option in DANE. That has its own DNSSEC trust chain, and I don't know whether it's more or less vulnerable to interference when compared to the web PKI.

Yoav

[1] http://tools.ietf.org/html/draft-ietf-websec-key-pinning

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 18 Nov 2013 15:40:56 +0900

Theodore Ts'o wrote:

> --- which is not a feature normally associated with PKI's.

It has nothing to do with PKI, because security key is directly
shared end to end.

It is a simple public key cryptography without PKI.

> It's
> unfortunately not all that scalable,

End to end security is inevitably not scalable.

> The challenge
> is coming up with a solution that *is* more scalable,

There is no royal road in secure communication.

					Masataka Ohta

---

From: SM <[email-masked]>
Date: Sun, 17 Nov 2013 23:04:08 -0800

>dependent on trusting that CA's are competently run.

Yes.

The certificate was issued on July 10, 2011.  The user report was 
filed on August 27, 2011.

At 17:32 17-11-2013, Phillip Hallam-Baker wrote:
>Diginotar would have noticed the issue if they had been checking 
>their OCSP logs as well.

This raises the question of whether the ETSI audits were of any use.

Regards,
-sm

---

From: Vinayak Hegde <[email-masked]>
Date: Mon, 18 Nov 2013 13:09:27 +0530

> time you compile. They have demonstrated an ability to hide compromise

How much can you trust your compiler. Ken Kernighan has a good essay on
this -> http://cm.bell-labs.com/who/ken/trust.html

-- Vinayak

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 18 Nov 2013 18:11:02 +0900

Yoav Nir wrote:

> Pinning every HTTPS certificate on the planet is not scalable. What
> you *can* do is have each site pin their site. That's the point of
> HPKP ([1]).
> 
> For this to work, you need to at some point be without the MITM. I
> guess that wouldn't help you much where MITM are pervasive, like Iran
> or Syria, but it would work where attacks are the exception.

What? Do you mean pervasive attack by NSA for Iran or Syria?

Anyway, pervasive attack longer than lifetime of pinning can
demolish HPKP.

Moreover, it is still no better than DH, because initially shared
DH key can be kept forever or as long as the lifetime of pinning.

						Masataka Ohta

---

From: Randy Bush <[email-masked]>
Date: Mon, 18 Nov 2013 19:00:26 +0900

> this -> http://cm.bell-labs.com/who/ken/trust.html

http://www.dwheeler.com/trusting-trust/

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 18 Nov 2013 19:47:03 +0900

> http://www.dwheeler.com/trusting-trust/

You can make application programs written in high level language
on your computers *completely* secure if you can correctly perform
the following:

	1) you manufacture CPU and related key chips and intra and
	inter board wiring.

	2) you code or check code, and hand assemble IPL

	3) you code or check code, and hand assemble OS

	4) you code or check code, and hand assemble an assembler

	5) you code or check code, and hand compile an compiler
	into assembly language.

	6) you code or check code, and use secure compiler for
	the applications.

Thus, it is obvious that, though it is not perfect, open source
helps a lot as it enables a lot of people check code.

Though I do have some experiences on some of 1), all of 2), 3) and
the first halves of 4), 5) and 6), it is very hard to do the rest.

However, open source still helps a lot.

							Masataka Ohta

---

From: Tony Finch <[email-masked]>
Date: Mon, 18 Nov 2013 11:53:13 +0000

Phillip Hallam-Baker <[email-masked]> wrote:
>
> Also rather odd to be talking about VeriSign which has not been in the
> CA business for three years now.

VeriSign is still used as a brand name by Symantec in their CA business.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 18 Nov 2013 12:20:25 +0000

> 	6) you code or check code, and use secure compiler for

So, I guess we have a plan for the next code sprint?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 Nov 2013 07:30:30 -0500

> VeriSign is still used as a brand name by Symantec in their CA business.

As are GeoTrust and Thawte. The paper recognizes the difference between
brands and the companies that use them. Then makes an error about what they
describe as the largest operating company.

Symantec loses the rights to use that brand in a short while, they may sell
the brand to Symantec or re-enter the CA business under their own brand.

The its not just a sloppy mistake, it is a mistake that would have been
caught by anyone in the business. So it is a group of academics talking
about an industry they have no direct knowledge of or it seems
anyinclination to find out.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 Nov 2013 07:42:35 -0500

>                 versions upon their compilation as well.

The attack is easily defeated these days because we have time stamp
authorities. I don't think that the compilers I use are smart enough to put
a back door in code written after they were.

> See above. I know better than you how to hide it.

The paper is hardly obscure. I generally assume people have read freshman
Comp Sci

> Note that google also has cloud provider business, which is also

It is a much trickier case because any damage comes from the risk of using
the unconstitutional powers not from having exercised them. The cause of
action is nowhere near as clear cut as it would be if a court exceeded its
powers and granted an injunction requiring a CA to make a
misrepresentation.about the identity of a certificate holder.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 Nov 2013 07:53:52 -0500

On Mon, Nov 18, 2013 at 2:04 AM, SM <[email-masked]> wrote:

> The certificate was issued on July 10, 2011.  The user report was filed on
> August 27, 2011.
>
>
>> Diginotar would have noticed the issue if they had been checking their
>> OCSP logs as well.
>>
>

DigiNotar did not have an audit for the system that was compromised.

They had an audit for a PKI they were running for the federal govt. It did
not actually cover the public CA.

---

From: Tony Finch <[email-masked]>
Date: Mon, 18 Nov 2013 13:06:52 +0000

> describe as the largest operating company.

I can't see the error you refer to. On page 6 "Symantec" is top of the
list of parent companies in table 4, and on the same page the text says
"Symantec owns Equifax, GeoTrust, TC TrustCenter, Thawte, and VeriSign".
The name they use to refer to each CA seems to come from the organization
field in its certificate DN, which explains the heading in table 5 and
the references to VeriSign, Inc.

Tony.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Nov 2013 14:33:15 +0000

Phillip, if all you've got to contribute to the discussion is an ad hominem argument about the EFF, I think you've already conceded, and this is all just noise.   This is why ad hominem arguments are generally fallacious.   If you want to make your point, your argument needs to be of the form "the conclusion here is wrong because of this fact that contradicts it," not "the EFF is wrong because of this fact that shows that, in my opinion, their conclusions generally can't be trusted."

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 Nov 2013 13:19:20 -0500

> the references to VeriSign, Inc.

Ah yes, you are right, my bad, sorry.

In my day half the VeriSign certs came up as RSA...

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 Nov 2013 13:21:12 -0500

On Mon, Nov 18, 2013 at 9:33 AM, Ted Lemon <[email-masked]> wrote:

> Phillip, if all you've got to contribute to the discussion is an ad
> hominem argument about the EFF,

Pointing out that a statement is untrue and the party refuses to retract it
after their error is pointed out is not Ad Hominem.

What you are engaging in here is a logical fallacy called ad nauseam which
is using a false claim of ad hominem to dismiss a claim.

If a man has lied it is not ad hominem to point out that he is a liar and
future claims he makes may be lies.

DFN accounts for half the graph that the EFF showed. They made no attempt
to find out if their assertion as to what the graph said was accurate and
they continue to make the claim that they have found 600 independent
entities able to issue certs even after agreeing in private that this is
not true.

I suggest that rather than criticizing me for pointing it out you should
ask members of the EFF board why they tolerate this.