Subject: Re: [therightkey] Other solutions to the problem

From: Ben Laurie <[email-masked]>
Date: Thu, 1 Nov 2012 09:10:28 +0000

On 31 October 2012 23:57, Rick Andrews <[email-masked]> wrote:
>> -----Original Message-----
>> From: Ben Laurie [mailto:[email-masked]]
>> Sent: Monday, October 29, 2012 3:10 AM
>> To: Rick Andrews
>> Cc: Rob Stradling; [email-masked]; Paul Hoffman
>> Subject: Re: [therightkey] Other solutions to the problem
>>
>> On 26 October 2012 22:31, Rick Andrews <[email-masked]>
>> wrote:
>> >> -----Original Message-----
>> >> From: Ben Laurie [mailto:[email-masked]]
>> >> Sent: Friday, October 26, 2012 1:51 AM
>> >> To: Rob Stradling
>> >> Cc: Rick Andrews; [email-masked]; Paul Hoffman
>> >> Subject: Re: [therightkey] Other solutions to the problem
>> >>
>> >> On 26 October 2012 09:24, Rob Stradling <[email-masked]>
>> >> wrote:
>> >> > On 26/10/12 00:58, Rick Andrews wrote:
>> >> > <snip>
>> >> >
>> >> >> AFAICT, for CT to really work it will require participation from
>> >> every CA
>> >> >> whose roots are in browsers. I think you're underestimating how
>> hard
>> >> it will
>> >> >> be to achieve that.
>> >> >
>> >> >
>> >> > Rick,
>> >> >
>> >> > Ultimately, assuming the RFC5878 TLS extension gains widespread
>> >> support in
>> >> > server and client software, CT won't _require_ participation from
>> any
>> >> CA.
>> >> > Each certificate holder will be able to configure their server to
>> >> send their
>> >> > certificate's CT proof to each client.
>> >
>> > I see, so the certificate holder can submit their newly-minted
>> certificate to a log server to get a CT proof. Instead of requiring the
>> participation of every CA, you now require the participation of every
>> certificate holder.
>>
>> No, it is an option.
>
> I understand that. I was trying to point out that for CT to be effective, you either need all CAs to participate, or for every CA that doesn't participate, their customers who want protection have to participate directly. I feel that's a pretty high bar to surmount.

Its only software. The process of participating in CT for a server operator is:

1. Run command line tool once, giving it your certificate as input and
an SCT file as output.

2. Add one line of configuration to your server config.

Not exactly rocket science. If people _really_ find it hard, we could
build it into the servers so there was no manual step at all.

>> >You might say that not every certificate holder will need or want CT,
>> but I would guess that the number that would want the protection would
>> be far greater than the number of CAs.
>>
>> Given that the plan is browsers will refuse non-CTed certs, I imagine
>> most holder of certificates used by the public will want CT.
>
> Do you have agreements with the major browser vendors to do this? It's possible that not all of them will be on board.

In practice, only one major browser needs to participate to give herd
immunity. Obviously it would be nice if they all did, but it is not an
urgent problem.

>> >> > But with participation from the CAs, it should be possible to
>> realize
>> >> the CT
>> >> > dream far sooner.  And (even in a future world where RFC5878 is
>> >> supported
>> >> > everywhere) if the CA takes care of CT proof distribution, then
>> that
>> >> makes
>> >> > life easier for the certificate holder.
>> >> >
>> >> >
>> >> >> Further, no one has yet brought up the privacy issue. CAs sell a
>> lot
>> >> of
>> >> >> certificates to companies for their internal use. Some of them
>> may
>> >> object to
>> >> >> publishing all their internal domain names.
>> >> >
>> >> >
>> >> > This has been a concern for Comodo too, so I spoke to AGL about it
>> a
>> >> few
>> >> > weeks ago.  AIUI, the plan is that CT clients will have a user-
>> >> configurable
>> >> > whitelist (empty by default) of domain names for which CT proofs
>> will
>> >> not be
>> >> > required.  Participating CAs should allow customers to opt-out
>> from
>> >> having
>> >> > their certs automatically logged with CT.
>> >
>> > I believe in your plan each browser will be a CT client. Aside from
>> the fact that the white list is an attractive target for hackers, I
>> don't see how the average user is going to know how to configure this
>> white list. I'm reminded of Adam's arguments against Convergence
>> (http://www.imperialviolet.org/2011/09/07/convergence.html).
>>
>> This is why I think the best solution is to issue private certs
>> through a name constrained intermediate which is logged.
>
> I agree.

I'm glad we agree on something!

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 1 Nov 2012 07:22:46 -0400

Zero net admin steps is probably a necessary criteria. What you think not
hard might as well be rocket science to most.

On Thu, Nov 1, 2012 at 5:10 AM, Ben Laurie <[email-masked]> wrote:

> > I understand that. I was trying to point out that for CT to be
> effective, you either need all CAs to participate, or for every CA that
> doesn't participate, their customers who want protection have to
> participate directly. I feel that's a pretty high bar to surmount.
>
> > Do you have agreements with the major browser vendors to do this? It's
> possible that not all of them will be on board.
>
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey
>

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

---

From: Ben Laurie <[email-masked]>
Date: Thu, 1 Nov 2012 11:26:36 +0000

> hard might as well be rocket science to most.

Maybe, but the rocket science involved in getting a cert in the first
place is far worse.

>> > doesn't participate, their customers who want protection have to participate
>> > directly. I feel that's a pretty high bar to surmount.
>>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 1 Nov 2012 08:14:56 -0700

> build it into the servers so there was no manual step at all.

As someone who has to trust every CA in the root pile in my browsers and OSs, I find it frightening that a CA who can say "this is your bank's certificate" cannot handle new requirements for how to say that. If adopting a simple protocol like this causes an ossified CA too many problems, maybe I don't trust that CA to be able to issue certificates for my bank, much less to be able to know which certificates that they are actually issuing.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 1 Nov 2012 12:29:31 -0400

This is about barely capable sysadmins.

Different problem.

On Thu, Nov 1, 2012 at 11:14 AM, Paul Hoffman <[email-masked]> wrote:

> As someone who has to trust every CA in the root pile in my browsers and
> OSs, I find it frightening that a CA who can say "this is your bank's
> certificate" cannot handle new requirements for how to say that. If
> adopting a simple protocol like this causes an ossified CA too many
> problems, maybe I don't trust that CA to be able to issue certificates for
> my bank, much less to be able to know which certificates that they are
> actually issuing.
>
> --Paul Hoffman

---

From: Lucy Lynch <[email-masked]>
Date: Thu, 1 Nov 2012 09:38:28 -0700 (PDT)

> This is about barely capable sysadmins.

I'm a barely capable sysadmin and the steps Ben outlined seem both 
reasonable and do-able to me. I also like the option to build it into the 
server where smart hands can build it into the default options for 
configuration -

- Lucy

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 1 Nov 2012 09:46:21 -0700

> This is about barely capable sysadmins. 

From the perspective of the relying party (me, caring about making a secure connection to my bank), the problems are indistinguishable. A CA who retains a sysadmin who is barely capable deserves less trust than one who retains sysadmins who are capable.

My bank, when trying to decide which CAs might get removed from the root piles in the future, should also see the problems as indistinguishable. That is, I would hope that my bank would pick a CA who is capable and non-ossified so that, when the incapable and ossified CAs are removed from the root piles, my bank doesn't need to get a new cert.

I would not mind if adoption of certificate transparency hastens the shedding of barely-capable CAs; the one-time hassle for some users would be far outweighed by the longer-term benefit to the security of the Internet.

--Paul Hoffman

---

From: Rick Andrews <[email-masked]>
Date: Thu, 1 Nov 2012 10:08:14 -0700

> From: [email-masked] [mailto:therightkey-
> [email-masked]] On Behalf Of Paul Hoffman
> Sent: Thursday, November 01, 2012 8:15 AM
> To: [email-masked]
> Subject: [therightkey] Barely-capable CAs
> 
> As someone who has to trust every CA in the root pile in my browsers
> and OSs, I find it frightening that a CA who can say "this is your
> bank's certificate" cannot handle new requirements for how to say that.
> If adopting a simple protocol like this causes an ossified CA too many
> problems, maybe I don't trust that CA to be able to issue certificates
> for my bank, much less to be able to know which certificates that they
> are actually issuing.

Paul, I find your statements to be oversimplifications:

1) That the CT protocol is simple: I've been trying to make the point on this list that it may be conceptually simple but pretty difficult to implement to the scale that is required.

2) That CAs can't handle new requirements: I'm not convinced that CT is the silver bullet that some appear to claim it is. If you were referring to my statements on this list, please don't interpret my criticism as inability to handle new requirements. I think a debate on the merits is healthy.

-Rick

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 1 Nov 2012 13:22:35 -0400

>From my perspective it is much cheaper for me to build a tool that does the
job right and give it to you than to follow the usual approach of yet more
poorly designed and documented stuff that might work or might not.

Having worked in Web security over 20 years now, I have still to see a case
where a system was breached because of a really subtle design flaw. Every
security issue I have seen has been really simple once it has been
identified and isolated.

Computer systems are hard to run and harder to secure because of the volume
of complexity rather than the degree of complexity. Each individual step is
trivial in itself but the cumulative effect is very large. I am sitting
next to the print edition of the Oxford English Dictionary which is 20
volumes of dense print. It is something like 200Mb in total. That was the
pinacle of achievement of Victorian research taking several decades and
thousands of authors. Modern operating systems and applications are much
larger. And because we design and build them in the wrong way it only takes
one mistake for them to fail.

One way that real world sysops defend themselves against complexity is to
refuse to learn anything that is new.

Judging the deployability of a protocol change based on whether IETF
participants are able to do so and willing to invest the necessary effort
skews the sample badly. If it were left to us we would have been using IPv6
for over a decade already.

On Thu, Nov 1, 2012 at 12:38 PM, Lucy Lynch <[email-masked]> wrote:

>>>  Its only software. The process of participating in CT for a server
>>>>
>>> operator is:
>>>
>>>>
>>> for
>>> ______________________________**_________________
>>> therightkey mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/therightkey<https://www.ietf.org/mailman/listinfo/therightkey>
>>>
>>>
>>
>>
>>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 01 Nov 2012 18:00:36 +0000

On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote:
> where a system was breached because of a really subtle design flaw. 

Bleichenbacher?

S.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 1 Nov 2012 11:01:37 -0700

> 1) That the CT protocol is simple: I've been trying to make the point on this list that it may be conceptually simple but pretty difficult to implement to the scale that is required.

Required by whom? Your scale arguments have, I believe, been that we need the same number of CAs in the root pile as we do now, and that we need dozens of auditors for the relying parties to choose from. For me as a relying part, neither of those are true.

If I'm wrong about my interpretation of your scale arguments, by all means start a new thread on this list with a concise statement of what you think is required for scaling. 

> 2) That CAs can't handle new requirements:

That's silly: I believe that many CAs can handle the new requirements just fine.

> I'm not convinced that CT is the silver bullet that some appear to claim it is.

Now you're putting words in other people's mouths, not a great tactic in the IETF. The term "silver bullet" has not appeared on this list, and I don't remember anyone using anything at all similar when describing certificate transparency.

> If you were referring to my statements on this list, please don't interpret my criticism as inability to handle new requirements.

I didn't.

> I think a debate on the merits is healthy.

Yes, that's why we are all here.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 1 Nov 2012 14:13:30 -0400

Which depended on a subtle mistake in the SSL 3.0 protocol. Specifically,
it gave a different report depending on whether the text decrypted or not.

Rather ironically here, the specific flaw in SSL 3.0 that made the attack
possible was one that the designer of 3.0 had actually played a major part
in raising in the civil field. Paul Kocher's other work being exploiting
differences in the physical behavior of devices running crypto (timing,
behavior in fault situation, radiation).

Now if Netscape had not been so chronically mismanaged as to only allow
Paul two weeks to review the spec and to only give Knight 10 days to write
Javascript, well the history of Web Security might have been rather
different.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 1 Nov 2012 18:35:11 +0000

>> where a system was breached because of a really subtle design flaw.

TLS renegotiation?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 1 Nov 2012 14:38:47 -0400

Again, does it appear so subtle after it has been discovered?

Would the flaw have been discovered sooner if there was not so much dead
code?

---

From: Rob Stradling <[email-masked]>
Date: Thu, 01 Nov 2012 18:52:39 +0000

On 01/11/12 16:46, Paul Hoffman wrote:
>>From the perspective of the relying party (me, caring about making a secure connection to my bank), the problems are indistinguishable. A CA who retains a sysadmin who is barely capable

Paul, this is about barely capable sysadmins _at your bank_, not at the CA.

(Ben wrote "The process of participating in CT for a _server operator_ 
is...")

> deserves less trust than one who retains sysadmins who are capable.

Obviously I agree that CAs should retain capable sysadmins.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Nico Williams <[email-masked]>
Date: Thu, 1 Nov 2012 14:26:00 -0500

> This is about barely capable sysadmins.

And the barely capable management that fails to make up for barely
capable sysadmins by, e.g., hiring actually capable sysadmins or
engaging consultants to help with occasional operations changes like
CT.

Nico
--

---

From: Ben Laurie <[email-masked]>
Date: Thu, 1 Nov 2012 19:52:26 +0000

> Again, does it appear so subtle after it has been discovered?

Well, I find I have to remind myself how it works. So ... yeah.

Also, I assumed Bliechanbacher was the exponent 3 thing, which was
also pretty subtle.

> Would the flaw have been discovered sooner if there was not so much dead

I don't think dead code had any influence on either of these.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 1 Nov 2012 12:54:18 -0700

On Nov 1, 2012, at 11:52 AM, Rob Stradling <[email-masked]> wrote:

> (Ben wrote "The process of participating in CT for a _server operator_ is...")

OK, maybe I'm confused here, or maybe you are. If my bank has a certificate issued by a CA who is actively participating in CT, there is no requirement on the bank at all, correct?

--Paul Hoffman

---

From: Rob Stradling <[email-masked]>
Date: Thu, 01 Nov 2012 20:00:01 +0000

> OK, maybe I'm confused here, or maybe you are. If my bank has a certificate issued by a CA who is actively participating in CT, there is no requirement on the bank at all, correct?

If by "actively participating" you mean that the CA has embedded the CT 
proof in the cert, then yes, there is no requirement on the bank.

If the CA instead embeds the CT proof in OCSP Responses relating to the 
cert, then there is no requirement on the bank apart from to use OCSP 
Stapling.

If the CA is not participating in either of these 2 ways, then there is 
a requirement on the bank (aka the "server operator"), which may or may 
not be rocket science, depending on your opinion.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 1 Nov 2012 16:01:03 -0400

OK so some examples do exist. But really what proportion of real world
compromises do not involve something bone headed like using a 512 bit key
for DKIM signatures?

What I am saying here is not 'don't do CT', I am saying that we have to
make the ease of administration a high priority in the design.

On Thu, Nov 1, 2012 at 3:52 PM, Ben Laurie <[email-masked]> wrote:

> >> >> Having worked in Web security over 20 years now, I have still to see
> a
> >> >> case

---

From: Rob Stradling <[email-masked]>
Date: Thu, 01 Nov 2012 20:06:28 +0000

On 01/11/12 20:01, Phillip Hallam-Baker wrote:
> compromises do not involve something bone headed like using a 512 bit
> key for DKIM signatures?
>

I would say that "ease of administration" for server operators is one of 
the main reasons why Ben is interested in getting CAs to participate!  ;-)

> On Thu, Nov 1, 2012 at 3:52 PM, Ben Laurie <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On 1 November 2012 18:38, Phillip Hallam-Baker <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      > On Thu, Nov 1, 2012 at 2:35 PM, Ben Laurie <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >>
>      >> On 1 November 2012 18:00, Stephen Farrell
>     <[email-masked] <mailto:[email-masked]>>
>      >> wrote:
>      >> >
>      >> >
>      >> >> Having worked in Web security over 20 years now, I have still
>     to see a
>      >> >> case
>      >> > [email-masked] <mailto:[email-masked]>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 01 Nov 2012 20:12:52 +0000

> the main reasons why Ben is interested in getting CAs to participate!  ;-)

I'm not saying that CA participation in CT will magically make 
administration easy.  ;-)

I am suggesting that having no extra steps to perform is probably 
_easier_ than having some extra steps to perform.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 1 Nov 2012 13:33:58 -0700

On Nov 1, 2012, at 1:00 PM, Rob Stradling <[email-masked]> wrote:

> If by "actively participating" you mean that the CA has embedded the CT proof in the cert, then yes, there is no requirement on the bank.

That's one definition of "actively participating", but there are others, such as publishing a list that the auditors pick up.

> If the CA instead embeds the CT proof in OCSP Responses relating to the cert, then there is no requirement on the bank apart from to use OCSP Stapling.

This confuses me. If the CA is putting the CT proof in its OCSP responses, why does the bank have to do anything?

> If the CA is not participating in either of these 2 ways, then there is a requirement on the bank (aka the "server operator"), which may or may not be rocket science, depending on your opinion.

If the CA is not participating, why should that CA be in the trust pile of software that relies on CT?

--Paul Hoffman

---

From: Rob Stradling <[email-masked]>
Date: Thu, 01 Nov 2012 21:55:54 +0000

> That's one definition of "actively participating", but there are others, such as publishing a list that the auditors pick up.

What sort of list did you have in mind?

Would this list be "transparent"?
(i.e. if the CA were to publish an inaccurate or incomplete list, would 
the auditor definitely notice?)

> This confuses me. If the CA is putting the CT proof in its OCSP responses, why does the bank have to do anything?

Because not all clients do online OCSP checks.
Because far too many online OCSP checks fail due to the Responder being 
unreachable.
Because OCSP Stapling is not currently enabled by default in (at least) 
Apache and nginx.

> If the CA is not participating, why should that CA be in the trust pile of software that relies on CT?

AFAIK, this is the first time it's been suggested that CT should require 
CA participation.  I think it's an idea we should consider seriously.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 01 Nov 2012 22:08:07 +0000

On 01/11/12 21:55, Rob Stradling wrote:
>>> If by "actively participating" you mean that the CA has embedded the
>>> CT proof in the cert, then yes, there is no requirement on the bank.
>>
>> That's one definition of "actively participating", but there are
>> others, such as publishing a list that the auditors pick up.
>
 > (i.e. if the CA were to publish an inaccurate or incomplete list,
 > would the auditor definitely notice?)

Ah, perhaps you've got this agenda item in mind:

"JSON format for CAs to report recent certificate
issuance, Phill Hallam-Baker – 10 mins"

I think Phill coined the term "weak transparency" for this sort of 
thing.  I'd only been thinking about Ben's "strong transparency" 
sunlight-02 proposal in this thread so far.

<snip>

---

From: [email-masked] (Martin Rex)
Date: Fri, 2 Nov 2012 20:08:46 +0100 (CET)

> > where a system was breached because of a really subtle design flaw. 

Debian OpenSSL CPRNG goof?

-Martin

---

From: Jon Callas <[email-masked]>
Date: Fri, 2 Nov 2012 17:52:39 -0700

>> where a system was breached because of a really subtle design flaw. 

Maybe. By the time Bleichenbacher was actually an issue, a number of us had been screaming for years. I suppose you can say that it was really subtle because the people concerned about it weren't listened to. But that has its own ick factor, too. Everything that people don't believe is subtle. Is it subtle that you shouldn't be using 1024 bit RSA keys? 512?

	Jon

---

From: Jon Callas <[email-masked]>
Date: Fri, 2 Nov 2012 17:57:58 -0700

> As someone who has to trust every CA in the root pile in my browsers and OSs, I find it frightening that a CA who can say "this is your bank's certificate" cannot handle new requirements for how to…

I'm mostly with Paul on this. I think that a CA that doesn't see CT as an incredible boon to be ossified to say the least. I'd add that this can be something the market solves -- move your business to one that gets it.

I can't say enough good things about CT because I think it lets everyone win without being the TSA of the Internet. I can go on, but really, CT is almost all upside. The only real downside is that it puts stresses on genuinely private PKIs, but it's only a stress, and arguably the few of those that really exist can opt out. Ben has pointed out that the same sorts of problems that CT would put on such things are induced by the SSL Observatory and similar efforts.

	Jon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 2 Nov 2012 22:10:56 -0400

My original point was that adding additional complexity into the system is
never simple. It is not just the small increment of complexity added that
is the issue, it is how it interacts with all the existing increments of
complexity.

Network admin is very hard because the tools provided are total crap. It
would be very easy for parts of the network to give feedback such as 'which
port is hogging bandwidth by jabbering away in NETBIOS' but they don't.

Net admins tend to be very suspicious of changes to configurations for good
reason, they have been burned many times before by 'simple' changes.

As for people warning about bugs... well yes, I told netscape about the
flaw in their PRNG over a year before someone decompiled the code and
'discovered' it. Jeff Schiller and Alan Schiffman had both been on at me
about the pitfalls of RNGs. Jeff because the Kerberos people got burned
that way.

What it comes down to in part is that some of us have a very different
model of how to write code than the rest of you. Cross site scripting, SQL
injection, buffer overruns, simply cannot occur in my coding world because
I would never use a scripting language that way or SQL or have code without
pervasive bound checking.

The NSA avoids errors like Bleichenbacher in the same way. Perhaps we can
learn from them.

In the meantime, if we want to get past the net admins we have to give them
a royal road and not lecture them.

On Fri, Nov 2, 2012 at 8:52 PM, Jon Callas <[email-masked]> wrote:

> Maybe. By the time Bleichenbacher was actually an issue, a number of us
> had been screaming for years. I suppose you can say that it was really
> subtle because the people concerned about it weren't listened to. But that
> has its own ick factor, too. Everything that people don't believe is
> subtle. Is it subtle that you shouldn't be using 1024 bit RSA keys? 512?
>
>         Jon
>