Re: [therightkey] Barely-capable CAs

[Phillip Hallam-Baker]

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  wrote:

>
> On Nov 1, 2012, at 11:00 AM, Stephen Farrell 
> wrote:
>
> >
> >
> > On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote:
> >> 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.
> >
> > Bleichenbacher?
>
> 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
>
> ___
> therightkey mailing list
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey
>



-- 
Website: http://hallambaker.com/
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Jon Callas]

On Nov 1, 2012, at 8:14 AM, Paul Hoffman  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.

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

___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Jon Callas]

On Nov 1, 2012, at 11:00 AM, Stephen Farrell  wrote:

> 
> 
> On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote:
>> 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. 
> 
> Bleichenbacher?

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

___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Martin Rex]

Stephen Farrell wrote:
> 
> 
> On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote:
> > 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. 
> 
> Bleichenbacher?

Debian OpenSSL CPRNG goof?

-Martin
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Rob Stradling]

On 01/11/12 21:55, Rob Stradling wrote:

On 01/11/12 20:33, Paul Hoffman wrote:

On Nov 1, 2012, at 1:00 PM, 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.


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?)

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.




--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Rob Stradling]

On 01/11/12 20:33, Paul Hoffman wrote:

On Nov 1, 2012, at 1:00 PM, 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.


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?)



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?


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 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?


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.


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Paul Hoffman]

On Nov 1, 2012, at 1:00 PM, 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.

> 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
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Rob Stradling]

On 01/11/12 20:06, Rob Stradling wrote:

On 01/11/12 20:01, Phillip Hallam-Baker wrote:

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.


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!  ;-)


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.



On Thu, Nov 1, 2012 at 3:52 PM, Ben Laurie mailto:b...@google.com>> wrote:

On 1 November 2012 18:38, Phillip Hallam-Baker mailto:hal...@gmail.com>> wrote:
 > 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
 > code?

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

 >
 >
 > On Thu, Nov 1, 2012 at 2:35 PM, Ben Laurie mailto:b...@google.com>> wrote:
 >>
 >> On 1 November 2012 18:00, Stephen Farrell
mailto:stephen.farr...@cs.tcd.ie>>
 >> wrote:
 >> >
 >> >
 >> > On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote:
 >> >> 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.
 >> >
 >> > Bleichenbacher?
 >>
 >> TLS renegotiation?
 >>
 >> >
 >> > S.
 >> > ___
 >> > therightkey mailing list
 >> > therightkey@ietf.org 
 >> > https://www.ietf.org/mailman/listinfo/therightkey
 >
 >
 >
 >
 > --
 > Website: http://hallambaker.com/
 >




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



___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey





--
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.

___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Rob Stradling]

On 01/11/12 20:01, Phillip Hallam-Baker wrote:

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.


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 mailto:b...@google.com>> wrote:

On 1 November 2012 18:38, Phillip Hallam-Baker mailto:hal...@gmail.com>> wrote:
 > 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
 > code?

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

 >
 >
 > On Thu, Nov 1, 2012 at 2:35 PM, Ben Laurie mailto:b...@google.com>> wrote:
 >>
 >> On 1 November 2012 18:00, Stephen Farrell
mailto:stephen.farr...@cs.tcd.ie>>
 >> wrote:
 >> >
 >> >
 >> > On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote:
 >> >> 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.
 >> >
 >> > Bleichenbacher?
 >>
 >> TLS renegotiation?
 >>
 >> >
 >> > S.
 >> > ___
 >> > therightkey mailing list
 >> > therightkey@ietf.org 
 >> > https://www.ietf.org/mailman/listinfo/therightkey
 >
 >
 >
 >
 > --
 > Website: http://hallambaker.com/
 >




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



___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey



--
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.

___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Phillip Hallam-Baker]

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  wrote:

> On 1 November 2012 18:38, Phillip Hallam-Baker  wrote:
> > 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
> > code?
>
> I don't think dead code had any influence on either of these.
>
> >
> >
> > On Thu, Nov 1, 2012 at 2:35 PM, Ben Laurie  wrote:
> >>
> >> On 1 November 2012 18:00, Stephen Farrell 
> >> wrote:
> >> >
> >> >
> >> > On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote:
> >> >> 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.
> >> >
> >> > Bleichenbacher?
> >>
> >> TLS renegotiation?
> >>
> >> >
> >> > S.
> >> > ___
> >> > therightkey mailing list
> >> > therightkey@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/therightkey
> >
> >
> >
> >
> > --
> > Website: http://hallambaker.com/
> >
>



-- 
Website: http://hallambaker.com/
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Rob Stradling]

On 01/11/12 19:54, Paul Hoffman wrote:

On Nov 1, 2012, at 11:52 AM, Rob Stradling  wrote:


On 01/11/12 16:46, Paul Hoffman wrote:

On Nov 1, 2012, at 9:29 AM, Phillip Hallam-Baker  wrote:


This is about barely capable sysadmins.

Different problem.



 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...")


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.


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Paul Hoffman]

On Nov 1, 2012, at 11:52 AM, Rob Stradling  wrote:

> On 01/11/12 16:46, Paul Hoffman wrote:
>> On Nov 1, 2012, at 9:29 AM, Phillip Hallam-Baker  wrote:
>> 
>>> This is about barely capable sysadmins.
>>> 
>>> Different problem.
>> 
>>> 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...")

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
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Ben Laurie]

On 1 November 2012 18:38, Phillip Hallam-Baker  wrote:
> 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
> code?

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

>
>
> On Thu, Nov 1, 2012 at 2:35 PM, Ben Laurie  wrote:
>>
>> On 1 November 2012 18:00, Stephen Farrell 
>> wrote:
>> >
>> >
>> > On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote:
>> >> 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.
>> >
>> > Bleichenbacher?
>>
>> TLS renegotiation?
>>
>> >
>> > S.
>> > ___
>> > therightkey mailing list
>> > therightkey@ietf.org
>> > https://www.ietf.org/mailman/listinfo/therightkey
>
>
>
>
> --
> Website: http://hallambaker.com/
>
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Nico Williams]

On Thu, Nov 1, 2012 at 11:29 AM, Phillip Hallam-Baker  wrote:
> 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
--
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Rob Stradling]

On 01/11/12 16:46, Paul Hoffman wrote:

On Nov 1, 2012, at 9:29 AM, Phillip Hallam-Baker  wrote:


This is about barely capable sysadmins.

Different problem.



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
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Phillip Hallam-Baker]

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?


On Thu, Nov 1, 2012 at 2:35 PM, Ben Laurie  wrote:

> On 1 November 2012 18:00, Stephen Farrell 
> wrote:
> >
> >
> > On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote:
> >> 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.
> >
> > Bleichenbacher?
>
> TLS renegotiation?
>
> >
> > S.
> > ___
> > therightkey mailing list
> > therightkey@ietf.org
> > https://www.ietf.org/mailman/listinfo/therightkey
>



-- 
Website: http://hallambaker.com/
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Ben Laurie]

On 1 November 2012 18:00, Stephen Farrell  wrote:
>
>
> On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote:
>> 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.
>
> Bleichenbacher?

TLS renegotiation?

>
> S.
> ___
> therightkey mailing list
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Phillip Hallam-Baker]

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.




On Thu, Nov 1, 2012 at 2:00 PM, Stephen Farrell
wrote:

>
>
> On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote:
> > 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.
>
> Bleichenbacher?
>
> S.
>



-- 
Website: http://hallambaker.com/
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Paul Hoffman]

On Nov 1, 2012, at 10:08 AM, Rick Andrews  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, 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.

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
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Stephen Farrell]

On 11/01/2012 05:22 PM, Phillip Hallam-Baker wrote:
> 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. 

Bleichenbacher?

S.
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Phillip Hallam-Baker]

>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  wrote:

> On Thu, 1 Nov 2012, Phillip Hallam-Baker wrote:
>
>  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
>
>
>  Different problem.
>>
>>
>> On Thu, Nov 1, 2012 at 11:14 AM, Paul Hoffman 
>> wrote:
>>
>>  On Nov 1, 2012, at 2:10 AM, Ben Laurie  wrote:
>>>
>>>  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.

>>>
>>> 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
>>> __**_
>>> therightkey mailing list
>>> therightkey@ietf.org
>>> https://www.ietf.org/mailman/**listinfo/therightkey
>>>
>>>
>>
>>
>>
> ___
> therightkey mailing list
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey
>
>


-- 
Website: http://hallambaker.com/
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Rick Andrews]

> -Original Message-
> From: therightkey-boun...@ietf.org [mailto:therightkey-
> boun...@ietf.org] On Behalf Of Paul Hoffman
> Sent: Thursday, November 01, 2012 8:15 AM
> To: therightkey@ietf.org
> Subject: [therightkey] Barely-capable CAs
> 
> On Nov 1, 2012, at 2:10 AM, Ben Laurie  wrote:
> 
> > 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.
> 
> 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
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Paul Hoffman]

On Nov 1, 2012, at 9:29 AM, Phillip Hallam-Baker  wrote:

> This is about barely capable sysadmins. 
> 
> Different problem.

>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
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Lucy Lynch]

On Thu, 1 Nov 2012, Phillip Hallam-Baker wrote:


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


Different problem.


On Thu, Nov 1, 2012 at 11:14 AM, Paul Hoffman  wrote:


On Nov 1, 2012, at 2:10 AM, Ben Laurie  wrote:


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.


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
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey





___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] Barely-capable CAs

[Phillip Hallam-Baker]

This is about barely capable sysadmins.

Different problem.


On Thu, Nov 1, 2012 at 11:14 AM, Paul Hoffman  wrote:

> On Nov 1, 2012, at 2:10 AM, Ben Laurie  wrote:
>
> > 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.
>
> 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
> ___
> therightkey mailing list
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey
>



-- 
Website: http://hallambaker.com/
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey