Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Ralph Holz]

Hi,

>> Tell me something new. ;-) Although in fact, the whole thing goes much
>> deeper. A broken hash algorithm means root cert-like compromise as it
>> means the capacity to imitate a correct signature by a root cert. There
>> is no fix for this but blacklisting. Not in any model with TTPs, by the
>> way.
> 
> You mean blacklisting the algorithm, right?

Ultimately, yes. That's what Moz etc. did, but you cannot force CAs to
switch to new algorithms at once. New root certs have to be added to the
root stores, new certs issued for existing customers, etc. Thus the
grace period until 2011.

In the meantime, all you can do is blacklist known-rogue certs.
Alternatively, pull the root cert from which MD5 signatures were issued.
As the MD5 attack still had considerable cost (for the hobby blackhat,
not a 3-letter agency), it was deemed that this must suffice for a while.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Stephen Farrell]

Folks - Phill is right that the subject line here is wrong.

Please fix if there's more to be discussed on this topic.

And I'd welcome some more discussion on CT and the proposal
to form a WG. Some drafts would be even better!

S.

On 01/03/2014 05:15 PM, Carl Wallace wrote:
> On 1/3/14, 12:12 PM, "Ralph Holz"  wrote:
>> Tell me something new. ;-) Although in fact, the whole thing goes much
>> deeper. A broken hash algorithm means root cert-like compromise as it
>> means the capacity to imitate a correct signature by a root cert. There
>> is no fix for this but blacklisting. Not in any model with TTPs, by the
>> way.
> 
> You mean blacklisting the algorithm, right?
> 
> 
> ___
> 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] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Carl Wallace]

On 1/3/14, 12:12 PM, "Ralph Holz"  wrote:
>Tell me something new. ;-) Although in fact, the whole thing goes much
>deeper. A broken hash algorithm means root cert-like compromise as it
>means the capacity to imitate a correct signature by a root cert. There
>is no fix for this but blacklisting. Not in any model with TTPs, by the
>way.

You mean blacklisting the algorithm, right?


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

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Ralph Holz]

Hi,

> Assumes you run an updated browser, right?

I think the cert was blacklisted immediately after the publication/talk,
that means at least 4 years ago. At least in IE, the auto-update may
have helped. Not sure about the Fox.

There really is nothing we can do for users that haven't updated since.
Any 2nd Web site they may visit may exploit those old vehicles.

> Blacklisting isn't part of the PKIX trust model, but a band-aid used to
> fix the lack of deployed/able revocation.

Tell me something new. ;-) Although in fact, the whole thing goes much
deeper. A broken hash algorithm means root cert-like compromise as it
means the capacity to imitate a correct signature by a root cert. There
is no fix for this but blacklisting. Not in any model with TTPs, by the way.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Rob Stradling]

On 03/01/14 14:29, Leif Johansson wrote:

On 2014-01-03 14:24, Ralph Holz wrote:

Hi,


My understanding of what Jakob wrote is that he holds the key for a
subordinate CA. Unless the CA that "signed" that subordinate has
been removed from trust lists then that subordinate would still be
useful, yes.

The subordinate certificate is blacklisted in browsers. Furthermore,
Mozilla does not accept any non-root certs with MD5 signatures since
mid-2011.

Ralph


Assumes you run an updated browser, right?


Yes.

There's only so much we can do to protect folks who don't update their 
browsers.  It seems very unlikely that MD5 signatures are the biggest 
threat that they face.



Blacklisting isn't part of the PKIX trust model, but a band-aid used to
fix the lack of deployed/able revocation.


So?

--
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] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Leif Johansson]

On 2014-01-03 14:24, Ralph Holz wrote:
> Hi,
>
>> My understanding of what Jakob wrote is that he holds the key for a 
>> subordinate CA. Unless the CA that "signed" that subordinate has
>> been removed from trust lists then that subordinate would still be
>> useful, yes.
> The subordinate certificate is blacklisted in browsers. Furthermore,
> Mozilla does not accept any non-root certs with MD5 signatures since
> mid-2011.
>
> Ralph
>

Assumes you run an updated browser, right?

Blacklisting isn't part of the PKIX trust model, but a band-aid used to
fix the lack of deployed/able revocation.

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

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Ralph Holz]

Hi,

> My understanding of what Jakob wrote is that he holds the key for a 
> subordinate CA. Unless the CA that "signed" that subordinate has
> been removed from trust lists then that subordinate would still be
> useful, yes.

The subordinate certificate is blacklisted in browsers. Furthermore,
Mozilla does not accept any non-root certs with MD5 signatures since
mid-2011.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Leif Johansson]

On 2014-01-02 23:50, Paul Hoffman wrote:
> On Jan 2, 2014, at 10:57 AM, Jacob Appelbaum  wrote:
>
>> I control the private key for the rouge CA that we created.
> True. However, that rogue CA is not trusted in any root pile, right? You 
> holding a private key for a trusted CA was, appropriately a big deal. You 
> holding a private key for an untrusted CA is uninteresting.
>

My understanding of what Jakob wrote is that he holds the key for a
subordinate CA. Unless the CA that "signed" that subordinate has been
removed from trust lists then that subordinate would still be useful, yes.


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

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Paul Hoffman]

On Jan 2, 2014, at 10:57 AM, Jacob Appelbaum  wrote:

> I control the private key for the rouge CA that we created.

True. However, that rogue CA is not trusted in any root pile, right? You 
holding a private key for a trusted CA was, appropriately a big deal. You 
holding a private key for an untrusted CA is uninteresting.


>> As you certainly know, that attack only
>> applied to a very limited number of CAs in the root piles at the
>> time.
> 
> I'm not sure where you came to this impression?

By counting the number of CAs who used MD5 and had predictable serial numbers.

> There were a few CAs who
> were vulnerable, we picked one to perform the research. It worked. That
> work produced a valid signature that we could apply to our second
> certificate, which is a sub-CA certificate. Thus, the attack we did only
> applied to a single CA and we did not destroy the private key for the
> corresponding certificate. So yes, we most certainly do have the private
> key for that intermediate certificate authority that we created.

All true, but no longer relevant.

>> I I remember correctly, it applied to zero of them
>> approximately six months later.
> 
> Unless one explicitly distrusts (all) MD5 signed certificates, pre-loads
> our certificate to mark it as untrusted, or a few other things relating
> to time constraints - it will probably still work for MITM attacks.

It sounds like you are saying that the contents of the issued certificates 
don't need to be predictable for the collision to happen. That would be absurd. 
Again, please don't overstate the value of your demonstration. It was a very 
good thing because it got people to look and *and fix* the problem. Can you 
point to a single CA in any of the common trust stores that both use MD5 and 
issue certificates with less than 2^64 bits of unpredictability?

> Many
> applications fail to do proper constraint checking.

Which is just fine. It should be up to the people putting together the trust 
pile to do the checking, not the relying parties.

> I'm not overstating anything.

We disagree.

> I think you don't understand what we
> actually did if you think that later, patching things will somehow
> magically stop previously successful attacks...

Ummm, where did I say anything about "patching"? I said that I believed that 
there were no more CAs who were vulnerable, and asked you to show where you 
thought there was. If you're right, then that's very valuable information. I 
don't see any more in the trust piles that I look through, but I could be 
missing something.

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

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Leif Johansson]

> 2 jan 2014 kl. 22:57 skrev Phillip Hallam-Baker :
> 
> 
> 
> 
>> On Thu, Jan 2, 2014 at 4:00 PM, Leif Johansson  wrote:
>> 
>> 
>> 2 jan 2014 kl. 21:25 skrev Phillip Hallam-Baker :
>> 
 > Please don't overstate the results of
 > the excellent research that you did; doing so diminishes the
 > research.
 
 I'm not overstating anything. I think you don't understand what we
 actually did if you think that later, patching things will somehow
 magically stop previously successful attacks...
>>> 
>>> 
>>> You are confusing people by using a valid attack against the algorithm to 
>>> argue against the trust model. PKIX is designed on the assumption that the 
>>> digest algorithm chosen is secure against a second preimage attack.
>> 
>> The fundamental flaw in the pkix trust model is that there is no deployable 
>> mechanism for limiting the impact of such an attack.
>> 
>> That realization should inform future design and that bit is certainly on 
>> topic ;-)
> 
> It is on topic but not limited to PKIX. 
> 
> We have since learned that algorithm agility is not quite the security 
> benefit we once thought as the security of the system is determined by the 
> weakest algorithm you support, not the strongest one you implement.
> 

A trust model based on shorter-time-to-live keys would have limited the impact 
too.


> 
> Problem is that I can't see a way to really control this type of attack 
> without a very considerable cost in usability and I think it would constrain 
> other defenses.
> 
> Anyone using Windows XP in the Enterprise for any purpose other than finding 
> viruses is guilty of security malpractice at this point. It is an obsolete OS 
> that would have been at EOL if lazy sysadmins hadn't begged to keep it.
>  
> 
> My current solution in my email project is to attempt to require SHA512 for 
> all certificates. But I am not sure that is actually sustainable.
> 
> -- 
> Website: http://hallambaker.com/
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Santosh Chokhani]

LTANS WG had produced an RFC (RFC 5698) to protect the relying parties from 
weak algorithms.

If that RFC is implemented on the certificate consuming side, these attacks 
will be thwarted.

From: therightkey [mailto:therightkey-boun...@ietf.org] On Behalf Of Phillip 
Hallam-Baker
Sent: Thursday, January 02, 2014 4:58 PM
To: Leif Johansson
Cc: therightkey@ietf.org; Paul Hoffman; Jacob Appelbaum
Subject: Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes 
HTTPS security



On Thu, Jan 2, 2014 at 4:00 PM, Leif Johansson 
mailto:le...@mnt.se>> wrote:


2 jan 2014 kl. 21:25 skrev Phillip Hallam-Baker 
mailto:hal...@gmail.com>>:
> Please don't overstate the results of
> the excellent research that you did; doing so diminishes the
> research.
I'm not overstating anything. I think you don't understand what we
actually did if you think that later, patching things will somehow
magically stop previously successful attacks...

You are confusing people by using a valid attack against the algorithm to argue 
against the trust model. PKIX is designed on the assumption that the digest 
algorithm chosen is secure against a second preimage attack.

The fundamental flaw in the pkix trust model is that there is no deployable 
mechanism for limiting the impact of such an attack.

That realization should inform future design and that bit is certainly on topic 
;-)

It is on topic but not limited to PKIX.

We have since learned that algorithm agility is not quite the security benefit 
we once thought as the security of the system is determined by the weakest 
algorithm you support, not the strongest one you implement.


Problem is that I can't see a way to really control this type of attack without 
a very considerable cost in usability and I think it would constrain other 
defenses.

Anyone using Windows XP in the Enterprise for any purpose other than finding 
viruses is guilty of security malpractice at this point. It is an obsolete OS 
that would have been at EOL if lazy sysadmins hadn't begged to keep it.


My current solution in my email project is to attempt to require SHA512 for all 
certificates. But I am not sure that is actually sustainable.

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

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Phillip Hallam-Baker]

On Thu, Jan 2, 2014 at 4:00 PM, Leif Johansson  wrote:

>
>
> 2 jan 2014 kl. 21:25 skrev Phillip Hallam-Baker :
>
> > Please don't overstate the results of
>> > the excellent research that you did; doing so diminishes the
>> > research.
>>
>> I'm not overstating anything. I think you don't understand what we
>> actually did if you think that later, patching things will somehow
>> magically stop previously successful attacks...
>>
>
> You are confusing people by using a valid attack against the algorithm to
> argue against the trust model. PKIX is designed on the assumption that the
> digest algorithm chosen is secure against a second preimage attack.
>
>
> The fundamental flaw in the pkix trust model is that there is no
> deployable mechanism for limiting the impact of such an attack.
>
> That realization should inform future design and that bit is certainly on
> topic ;-)
>

It is on topic but not limited to PKIX.

We have since learned that algorithm agility is not quite the security
benefit we once thought as the security of the system is determined by the
weakest algorithm you support, not the strongest one you implement.


Problem is that I can't see a way to really control this type of attack
without a very considerable cost in usability and I think it would
constrain other defenses.

Anyone using Windows XP in the Enterprise for any purpose other than
finding viruses is guilty of security malpractice at this point. It is an
obsolete OS that would have been at EOL if lazy sysadmins hadn't begged to
keep it.


My current solution in my email project is to attempt to require SHA512 for
all certificates. But I am not sure that is actually sustainable.

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

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Leif Johansson]

> 2 jan 2014 kl. 21:25 skrev Phillip Hallam-Baker :
> 
> 
> 
> 
>> On Thu, Jan 2, 2014 at 1:57 PM, Jacob Appelbaum  wrote:
>> Paul Hoffman:
>> > On Jan 1, 2014, at 10:22 AM, Jacob Appelbaum 
>> > wrote:
>> >
>> >> I do control the private key for the aforementioned intermediate
>> >> certificate[0] authority. :)
>> >
>> > No, you really do not.
>  
>> Unless one explicitly distrusts (all) MD5 signed certificates, pre-loads
>> our certificate to mark it as untrusted, or a few other things relating
>> to time constraints - it will probably still work for MITM attacks. Many
>> applications fail to do proper constraint checking.
> 
> Anyone who trusts MD5 for signing any form of keying material is vulnerable 
> to this type of attack. It does not matter whether there is a CA involved or 
> not or the number of sub CAs. A variation of the attack could be performed on 
> PGP or DNSSEC.
> 
> The fix here is to disable MD5 completely in the browser or for CAs to not 
> use MD5 in any certificate. The industry has chosen to do the second since we 
> can't actually recall legacy browsers. However, Microsoft's recent decision 
> to end of life SHA-1 will have the effect of rendering most of the legacy 
> browsers unusable in any case.
> 
> 
> 
>> > Please don't overstate the results of
>> > the excellent research that you did; doing so diminishes the
>> > research.
>> 
>> I'm not overstating anything. I think you don't understand what we
>> actually did if you think that later, patching things will somehow
>> magically stop previously successful attacks...
> 
> 
> You are confusing people by using a valid attack against the algorithm to 
> argue against the trust model. PKIX is designed on the assumption that the 
> digest algorithm chosen is secure against a second preimage attack.

The fundamental flaw in the pkix trust model is that there is no deployable 
mechanism for limiting the impact of such an attack.

That realization should inform future design and that bit is certainly on topic 
;-)


> 
> We have a lot of security issues to deal with right now and we want to make 
> sure we are paying attention to the ones that matter most. This is really not 
> helping.
> 
> -- 
> Website: http://hallambaker.com/
> ___
> 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] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Phillip Hallam-Baker]

On Thu, Jan 2, 2014 at 1:57 PM, Jacob Appelbaum  wrote:

> Paul Hoffman:
> > On Jan 1, 2014, at 10:22 AM, Jacob Appelbaum 
> > wrote:
> >
> >> I do control the private key for the aforementioned intermediate
> >> certificate[0] authority. :)
> >
> > No, you really do not.
>


> Unless one explicitly distrusts (all) MD5 signed certificates, pre-loads
> our certificate to mark it as untrusted, or a few other things relating
> to time constraints - it will probably still work for MITM attacks. Many
> applications fail to do proper constraint checking.


Anyone who trusts MD5 for signing any form of keying material is vulnerable
to this type of attack. It does not matter whether there is a CA involved
or not or the number of sub CAs. A variation of the attack could be
performed on PGP or DNSSEC.

The fix here is to disable MD5 completely in the browser or for CAs to not
use MD5 in any certificate. The industry has chosen to do the second since
we can't actually recall legacy browsers. However, Microsoft's recent
decision to end of life SHA-1 will have the effect of rendering most of the
legacy browsers unusable in any case.



> Please don't overstate the results of
> > the excellent research that you did; doing so diminishes the
> > research.
>
> I'm not overstating anything. I think you don't understand what we
> actually did if you think that later, patching things will somehow
> magically stop previously successful attacks...
>

You are confusing people by using a valid attack against the algorithm to
argue against the trust model. PKIX is designed on the assumption that the
digest algorithm chosen is secure against a second preimage attack.

We have a lot of security issues to deal with right now and we want to make
sure we are paying attention to the ones that matter most. This is really
not helping.

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

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Jacob Appelbaum]

Paul Hoffman:
> On Jan 1, 2014, at 10:22 AM, Jacob Appelbaum 
> wrote:
> 
>> I do control the private key for the aforementioned intermediate 
>> certificate[0] authority. :)
> 
> No, you really do not.

I control the private key for the rouge CA that we created. I'm not the
only one with the private key material - all of my fellow researchers
likely still have it as well.

Perhaps you think that I said something that I didn't say. I'm not
claiming that I have the private key for the CA's actual correct CA
signing key.

> As you certainly know, that attack only
> applied to a very limited number of CAs in the root piles at the
> time.

I'm not sure where you came to this impression? There were a few CAs who
were vulnerable, we picked one to perform the research. It worked. That
work produced a valid signature that we could apply to our second
certificate, which is a sub-CA certificate. Thus, the attack we did only
applied to a single CA and we did not destroy the private key for the
corresponding certificate. So yes, we most certainly do have the private
key for that intermediate certificate authority that we created.

> I I remember correctly, it applied to zero of them
> approximately six months later.

Unless one explicitly distrusts (all) MD5 signed certificates, pre-loads
our certificate to mark it as untrusted, or a few other things relating
to time constraints - it will probably still work for MITM attacks. Many
applications fail to do proper constraint checking.

> Please don't overstate the results of
> the excellent research that you did; doing so diminishes the
> research.

I'm not overstating anything. I think you don't understand what we
actually did if you think that later, patching things will somehow
magically stop previously successful attacks...

All the best,
Jacob
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Paul Hoffman]

On Jan 1, 2014, at 10:22 AM, Jacob Appelbaum  wrote:

> I do control the private key for the aforementioned intermediate
> certificate[0] authority. :)

No, you really do not. As you certainly know, that attack only applied to a 
very limited number of CAs in the root piles at the time. I I remember 
correctly, it applied to zero of them approximately six months later. Please 
don't overstate the results of the excellent research that you did; doing so 
diminishes the research.

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

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Jacob Appelbaum]

Rob Stradling:
> On 23/12/13 18:29, Jacob Appelbaum wrote:
>> Phillip Hallam-Baker:
> 
>>> You can't calculate the number of CAs the way the EFF tried to. An
>>> intermediate certificate does not equate to a CA. Pretending it does to
>>> peddle an alternative PKI scheme calls into question their veracity.
>>
>> I disagree strongly. I have an intermediate certificate. I am as
>> powerful CA as a result.
> 
> Jake, you're only that powerful if you control the intermediate private
> key.

I do control the private key for the aforementioned intermediate
certificate[0] authority. :)

... and I'm not the only one, obviously.

Happy new year,
Jake

[0] http://www.win.tue.nl/hashclash/rogue-ca/
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Rob Stradling]

On 23/12/13 18:29, Jacob Appelbaum wrote:

Phillip Hallam-Baker:



You can't calculate the number of CAs the way the EFF tried to. An
intermediate certificate does not equate to a CA. Pretending it does to
peddle an alternative PKI scheme calls into question their veracity.


I disagree strongly. I have an intermediate certificate. I am as
powerful CA as a result.


Jake, you're only that powerful if you control the intermediate private key.



Other estimates appear to be much higher than the EFF count. What is
your qualification for what counts as a CA? For example - Debian
GNU/Linux ships with one set of ca-certificates, Chrome on Windows ships
with another, heck Microsoft even adds new CA certs dynamically, right?
So what is your metric exactly?


I would prefer to count the number of distinct organizations that 
control at least 1 private key that is associated with at least 1 
non-Name-Constrained root or intermediate certificate that chains to (or 
is) a root in the Microsoft, Mozilla and/or Apple root store and which 
can issue certs that are trusted for Server Authentication.


It's not possible to measure this purely by examining the body of 
root/intermediate certificates that are known to exist (although this 
body of certificates is of course useful for cross-referencing).



2) Continuing to count the DFN as 300 CAs when they know it is one.


The number matters because it isn't just an issue of control over a
single signing key. I'd be interested to hear how many of those
CAs/sub-CAs are able to sign leaf certificates.


All of the DFN Sub-CAs are able to sign leaf certificates, but it is 
_only_ DFN that controls the private keys that would be used to sign 
these leaf certificates.  The various German universities are 
essentially only RAs, even though they are named as the Subjects of the 
intermediate certificates.


Many Sub-CA certificates issued by major commercial Root CAs exist 
purely for branding reasons.  i.e. the Subject is at most an RA, and 
sometimes only a Reseller.


On the other hand, if there are still any RAs/Resellers that control 
root or intermediate private keys, then by my metric they should be 
counted as CAs.


My gut feeling is that the real number (by my metric) is likely to be a 
lot nearer to 60 than to 600.


--
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] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Ralph Holz]

Hi,

[The EFF's count]

>> You can't calculate the number of CAs the way the EFF tried to. An
>> intermediate certificate does not equate to a CA. Pretending it does to
>> peddle an alternative PKI scheme calls into question their veracity.
>>
> 
> I disagree strongly. I have an intermediate certificate. I am as
> powerful CA as a result.
> Please also see these estimates which are even higher:
> 
> https://zakird.com/slides/durumeric-https-imc13.pdf
> 
> "Identified 1,832 CA certificates  belonging to 683 organizations"
> "311 (45%) of the organizations were provided certificates by
> German National Research and Education Network (DFN) "

I was there at IMC and spoke with Zakir. He was not aware of the fact
that the private keys to all the intermediate certificates are held by
the central DFN Verein, not the RAs themselves. In the case of DFN, the
intermediate certs only identify the RAs. The RAs do not carry signing
power.

It is the same at TUM, where I work, BTW.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Jacob Appelbaum]

Phillip Hallam-Baker:
> On Sun, Dec 15, 2013 at 8:50 PM, Tao Effect  wrote:
> 
>> And for someone who is accusing others of being 'fraudulent', not a good
>> move to start off repeating figures already exposed as bogus like the oft
>> repeated but still untrue claim of 600 CAs.
>>
>>
>> I thought the EFF was a reputable source.
>>
>> There has been no update or correction to their post:
>> https://www.eff.org/deeplinks/2011/10/how-secure-https-today
>>
> 
> Which kind of calls their credibility into question.

No, I don't think so, actually.

> HALF the 'CAs' in
> their graph are from the DFN root. You can check that out for yourself, it
> is a German CA that issues certs to higher education institutions. As has
> been demonstrated (and agreed by the EFF people), DFN do not sign certs for
> key signing keys they do not hold.

Their count isn't off simply because you want to reduce a large number
of keys into a single entity.

> 
> You can't calculate the number of CAs the way the EFF tried to. An
> intermediate certificate does not equate to a CA. Pretending it does to
> peddle an alternative PKI scheme calls into question their veracity.
> 

I disagree strongly. I have an intermediate certificate. I am as
powerful CA as a result.

Please also see these estimates which are even higher:

https://zakird.com/slides/durumeric-https-imc13.pdf

"Identified 1,832 CA certificates  belonging to 683 organizations"
"311 (45%) of the organizations were provided certificates by
German National Research and Education Network (DFN) "

http://link.springer.com/chapter/10.1007%2F978-3-642-39884-1_28

"More than 1200 root and intermediate CAs can currently sign
certificates for any domain and be trusted by popular browsers."

> I have tried to get members of the EFF board to look into this but they
> never get back. Too much trouble to get it right.

I've cc'ed Seth Schoen from the EFF - I'd be surprised if he had no
response.

Later you said:

> 1) Failing to examine the issue when the DFN root accounted for half of the
> purported '600 CAs'
> 

Other estimates appear to be much higher than the EFF count. What is
your qualification for what counts as a CA? For example - Debian
GNU/Linux ships with one set of ca-certificates, Chrome on Windows ships
with another, heck Microsoft even adds new CA certs dynamically, right?
So what is your metric exactly?

> 2) Continuing to count the DFN as 300 CAs when they know it is one.

The number matters because it isn't just an issue of control over a
single signing key. I'd be interested to hear how many of those
CAs/sub-CAs are able to sign leaf certificates.


All the best,
Jacob
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Tao Effect]

The list moderator asked a few participants (including myself) to let this 
issue go, but I just want to mention that I've posted a minor update to the 
PDF, and have included a link to this thread in it, as well as a footnote next 
to the 600+ figure, mentioning that, "Phillip Hallam-Baker disputes the EFF’s 
figure on [therightkey] mailing list, but did not provided citable references 
for his claims."

URL remains the same, but it should say Version 1.1 in the lower-left of the 
cover page:

http://okturtles.com/other/dnsnmc_okturtles_overview.pdf

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Dec 16, 2013, at 5:54 PM, Tao Effect  wrote:

> Oh, sorry, I just saw (after sending that email), that I didn't answer your 
> question.
> 
> Why bother quoting it at all? Because whether the number is 600+ or 300+, it 
> still serves to support the point that browsers will take the word of any one 
> of over a hundred potentially untrustworthy strangers as "proof" that a 
> connection to a website is secure.
> 
> - Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> 
> On Dec 16, 2013, at 5:48 PM, Tao Effect  wrote:
> 
>> On Dec 16, 2013, at 5:37 PM, Phillip Hallam-Baker  wrote:
>>> 
>>> Since the 600 number is inaccurate and not particularly necessary, why 
>>> bother to quote it at all?
>> 
>> Dude, how did you manage to ignore that entire email?
>> 
>> One more time, since you somehow missed it:
>> 
 OK, in order for me to correct this in the paper I need the following 
 information:
 
 1. A link to who "DFN" is.
 2. A 'yes' or 'no' as to whether DFN is a root cert that browsers are 
 shipped with (and details about this, like, do all 3 major browsers 
 include DFN?)
 3. A link to a paper, a blog post, or an article somewhere that describes 
 in detail your side of the argument
 
>> 
>> 
>> You cannot just say "the EFF is lying", throw your hands in the air, and 
>> leave it at that.
>> 
>> Unlike you, the EFF provided sources and proof for their claim.
>> 
>> The then wrote a widely cited blog post containing their claim and their 
>> evidence for it.
>> 
>> Where is your blog post? Where is your evidence that the EFF is lying?
>> 
>> These emails of yours don't cut it. Heck, I'd even post a link to an 
>> archived email of yours if you provided the necessary information in it.
>> 
>> - Greg
>> 
>> --
>> Please do not email me anything that you are not comfortable also sharing 
>> with the NSA.
>> 
>> On Dec 16, 2013, at 5:37 PM, Phillip Hallam-Baker  wrote:
>> 
>>> When you make an assertion in a paper then you are accepting the burden of 
>>> proof. 
>>> 
>>> 
>>> If the source for the '600' claim was lying then the claim has to be taken 
>>> off the table completely. The DFN root issue demonstrates that the 
>>> methodology is bogus rather than just being a single inaccurate data point.
>>> 
>>> If you want to make assertions about the number of CAs then the most 
>>> accurate measure currently available is still the number of roots in the 
>>> commonly used browsers. While there are a handful of CAs using roots cross 
>>> certified by another CA, such CAs now have to have a full audit statement 
>>> and meet all the acceptance criteria in their own right. So there would be 
>>> little point in not applying to have the root entered in independently.
>>> 
>>> Since the 600 number is inaccurate and not particularly necessary, why 
>>> bother to quote it at all?
>>> 
>>> 
>>> 
>>> 
>>> On Mon, Dec 16, 2013 at 1:44 PM, Tao Effect  wrote:
 Which kind of calls their credibility into question. HALF the 'CAs' in 
 their graph are from the DFN root. You can check that out for yourself, it 
 is a German CA that issues certs to higher education institutions. As has 
 been demonstrated (and agreed by the EFF people), DFN do not sign certs 
 for key signing keys they do not hold.
 
 You can't calculate the number of CAs the way the EFF tried to. An 
 intermediate certificate does not equate to a CA. Pretending it does to 
 peddle an alternative PKI scheme calls into question their veracity.
 
 I have tried to get members of the EFF board to look into this but they 
 never get back. Too much trouble to get it right.
>>> 
>>> 
>>> OK, in order for me to correct this in the paper I need the following 
>>> information:
>>> 
>>> 1. A link to who "DFN" is.
>>> 2. A 'yes' or 'no' as to whether DFN is a root cert that browsers are 
>>> shipped with (and details about this, like, do all 3 major browsers include 
>>> DFN?)
>>> 3. A link to a paper, a blog post, or an article somewhere that describes 
>>> in detail your side of the argument
>>> 
>>> Let me emphasize that none of this ultimately matters to the points that 
>>> were made in the paper.
>>> 
>>> Whether the number is 600+ or 300+, it's still an insecure, broken mess.
>>> 

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Ralph Holz]

Hi,

> yep, DFN is a 'private' sub-CA under tight control but it could still be
> attacked the way diginotar was and though I believe their secuity is a
> lot better than their less fortunate Dutch cousins, a successful attack
> would be just as bad.

That is true for any CA, sub-* or not. The important point is where the
private key is kept.

In the case of the DFN, the 'many subCAs' are actually RAs without
signing capacity. I'd be much more worried about some resellers of the
very popular CAs. Anyone remember Comodo's InstantSSL reseller?

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Tao Effect]

Sorry, that's got to be a new level of typo for me:

> he basic idea is already be explained in the paper.

*The basic idea is already touched on in the paper.

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Dec 16, 2013, at 8:59 PM, Tao Effect  wrote:

>> More of a marketing announcement than a technical proposal … perhaps I 
>> missed the URL, but is there any technical specification?  
> 
> he basic idea is already be explained in the paper.
> 
> A detailed specification will be published to Github soon.
> 
> You're welcome to comment on what's already suggested in the paper (here or 
> in the corresponding Namecoin thread).
> 
> Cheers,
> Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> 
> On Dec 16, 2013, at 7:53 PM, Paul Lambert  wrote:
> 
>> 
>> 
>> 
>> 
>>> Though this thread is more of an announcement, it can also be considered a 
>>> first draft of a proposal for DNSNMC.
>>> 
>>> Paper was linked to in the first post, here it is again:
>>> 
>>> http://okturtles.com/other/dnsnmc_okturtles_overview.pdf
>> 
>> 
>> More of a marketing announcement than a technical proposal … perhaps I 
>> missed the URL, but is there any technical specification?  
>> Seem like the charter of this group could provide a more generic worked out 
>> solution.
>> 
>> Paul
>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Tao Effect]

> More of a marketing announcement than a technical proposal … perhaps I missed 
> the URL, but is there any technical specification?  

he basic idea is already be explained in the paper.

A detailed specification will be published to Github soon.

You're welcome to comment on what's already suggested in the paper (here or in 
the corresponding Namecoin thread).

Cheers,
Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Dec 16, 2013, at 7:53 PM, Paul Lambert  wrote:

> 
> 
> 
> 
>> Though this thread is more of an announcement, it can also be considered a 
>> first draft of a proposal for DNSNMC.
>> 
>> Paper was linked to in the first post, here it is again:
>> 
>> http://okturtles.com/other/dnsnmc_okturtles_overview.pdf
> 
> 
> More of a marketing announcement than a technical proposal … perhaps I missed 
> the URL, but is there any technical specification?  
> Seem like the charter of this group could provide a more generic worked out 
> solution.
> 
> Paul
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Paul Lambert]

Though this thread is more of an announcement, it can also be considered a 
first draft of a proposal for DNSNMC.

Paper was linked to in the first post, here it is again:

http://okturtles.com/other/dnsnmc_okturtles_overview.pdf

More of a marketing announcement than a technical proposal … perhaps I missed 
the URL, but is there any technical specification?
Seem like the charter of this group could provide a more generic worked out 
solution.

Paul


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

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Tao Effect]

Oh, sorry, I just saw (after sending that email), that I didn't answer your 
question.

Why bother quoting it at all? Because whether the number is 600+ or 300+, it 
still serves to support the point that browsers will take the word of any one 
of over a hundred potentially untrustworthy strangers as "proof" that a 
connection to a website is secure.

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Dec 16, 2013, at 5:48 PM, Tao Effect  wrote:

> On Dec 16, 2013, at 5:37 PM, Phillip Hallam-Baker  wrote:
>> 
>> Since the 600 number is inaccurate and not particularly necessary, why 
>> bother to quote it at all?
> 
> Dude, how did you manage to ignore that entire email?
> 
> One more time, since you somehow missed it:
> 
>>> OK, in order for me to correct this in the paper I need the following 
>>> information:
>>> 
>>> 1. A link to who "DFN" is.
>>> 2. A 'yes' or 'no' as to whether DFN is a root cert that browsers are 
>>> shipped with (and details about this, like, do all 3 major browsers include 
>>> DFN?)
>>> 3. A link to a paper, a blog post, or an article somewhere that describes 
>>> in detail your side of the argument
>>> 
> 
> 
> You cannot just say "the EFF is lying", throw your hands in the air, and 
> leave it at that.
> 
> Unlike you, the EFF provided sources and proof for their claim.
> 
> The then wrote a widely cited blog post containing their claim and their 
> evidence for it.
> 
> Where is your blog post? Where is your evidence that the EFF is lying?
> 
> These emails of yours don't cut it. Heck, I'd even post a link to an archived 
> email of yours if you provided the necessary information in it.
> 
> - Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> 
> On Dec 16, 2013, at 5:37 PM, Phillip Hallam-Baker  wrote:
> 
>> When you make an assertion in a paper then you are accepting the burden of 
>> proof. 
>> 
>> 
>> If the source for the '600' claim was lying then the claim has to be taken 
>> off the table completely. The DFN root issue demonstrates that the 
>> methodology is bogus rather than just being a single inaccurate data point.
>> 
>> If you want to make assertions about the number of CAs then the most 
>> accurate measure currently available is still the number of roots in the 
>> commonly used browsers. While there are a handful of CAs using roots cross 
>> certified by another CA, such CAs now have to have a full audit statement 
>> and meet all the acceptance criteria in their own right. So there would be 
>> little point in not applying to have the root entered in independently.
>> 
>> Since the 600 number is inaccurate and not particularly necessary, why 
>> bother to quote it at all?
>> 
>> 
>> 
>> 
>> On Mon, Dec 16, 2013 at 1:44 PM, Tao Effect  wrote:
>>> Which kind of calls their credibility into question. HALF the 'CAs' in 
>>> their graph are from the DFN root. You can check that out for yourself, it 
>>> is a German CA that issues certs to higher education institutions. As has 
>>> been demonstrated (and agreed by the EFF people), DFN do not sign certs for 
>>> key signing keys they do not hold.
>>> 
>>> You can't calculate the number of CAs the way the EFF tried to. An 
>>> intermediate certificate does not equate to a CA. Pretending it does to 
>>> peddle an alternative PKI scheme calls into question their veracity.
>>> 
>>> I have tried to get members of the EFF board to look into this but they 
>>> never get back. Too much trouble to get it right.
>> 
>> 
>> OK, in order for me to correct this in the paper I need the following 
>> information:
>> 
>> 1. A link to who "DFN" is.
>> 2. A 'yes' or 'no' as to whether DFN is a root cert that browsers are 
>> shipped with (and details about this, like, do all 3 major browsers include 
>> DFN?)
>> 3. A link to a paper, a blog post, or an article somewhere that describes in 
>> detail your side of the argument
>> 
>> Let me emphasize that none of this ultimately matters to the points that 
>> were made in the paper.
>> 
>> Whether the number is 600+ or 300+, it's still an insecure, broken mess.
>> 
>>> I was under the impression that Bitcoin was the preferred currency of 
>>> libertopia. It is the only one that gets mention in the mainstream press. 
>>> It is not clear to me how namecoin can be part of BitCoin and another 
>>> currency.
>> 
>> 
>> I'll be happy to clear this up:
>> 
>> - Bitcoin is not the "market leader" of distributed DNS systems. Namecoin is.
>> - Namecoin and Bitcoin are designed with completely different goals in mind. 
>> They are not competitors.
>> - Namecoin is not intended to be a bitcoin replacement, nor the other way 
>> around. It is not like "litecoin" or any of the other bitcoin competitors, 
>> because it is not a competitor to bitcoin.
>> 
>>> Gold Age, eGold, Liberty Reserve. All the ones that were taken apart by the 
>>> Feds.
>> 
>> 
>> I'll be happy to clear this up too:
>> 

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Tao Effect]

On Dec 16, 2013, at 5:37 PM, Phillip Hallam-Baker  wrote:
> 
> Since the 600 number is inaccurate and not particularly necessary, why bother 
> to quote it at all?

Dude, how did you manage to ignore that entire email?

One more time, since you somehow missed it:

>> OK, in order for me to correct this in the paper I need the following 
>> information:
>> 
>> 1. A link to who "DFN" is.
>> 2. A 'yes' or 'no' as to whether DFN is a root cert that browsers are 
>> shipped with (and details about this, like, do all 3 major browsers include 
>> DFN?)
>> 3. A link to a paper, a blog post, or an article somewhere that describes in 
>> detail your side of the argument
>> 


You cannot just say "the EFF is lying", throw your hands in the air, and leave 
it at that.

Unlike you, the EFF provided sources and proof for their claim.

The then wrote a widely cited blog post containing their claim and their 
evidence for it.

Where is your blog post? Where is your evidence that the EFF is lying?

These emails of yours don't cut it. Heck, I'd even post a link to an archived 
email of yours if you provided the necessary information in it.

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Dec 16, 2013, at 5:37 PM, Phillip Hallam-Baker  wrote:

> When you make an assertion in a paper then you are accepting the burden of 
> proof. 
> 
> 
> If the source for the '600' claim was lying then the claim has to be taken 
> off the table completely. The DFN root issue demonstrates that the 
> methodology is bogus rather than just being a single inaccurate data point.
> 
> If you want to make assertions about the number of CAs then the most accurate 
> measure currently available is still the number of roots in the commonly used 
> browsers. While there are a handful of CAs using roots cross certified by 
> another CA, such CAs now have to have a full audit statement and meet all the 
> acceptance criteria in their own right. So there would be little point in not 
> applying to have the root entered in independently.
> 
> Since the 600 number is inaccurate and not particularly necessary, why bother 
> to quote it at all?
> 
> 
> 
> 
> On Mon, Dec 16, 2013 at 1:44 PM, Tao Effect  wrote:
>> Which kind of calls their credibility into question. HALF the 'CAs' in their 
>> graph are from the DFN root. You can check that out for yourself, it is a 
>> German CA that issues certs to higher education institutions. As has been 
>> demonstrated (and agreed by the EFF people), DFN do not sign certs for key 
>> signing keys they do not hold.
>> 
>> You can't calculate the number of CAs the way the EFF tried to. An 
>> intermediate certificate does not equate to a CA. Pretending it does to 
>> peddle an alternative PKI scheme calls into question their veracity.
>> 
>> I have tried to get members of the EFF board to look into this but they 
>> never get back. Too much trouble to get it right.
> 
> 
> OK, in order for me to correct this in the paper I need the following 
> information:
> 
> 1. A link to who "DFN" is.
> 2. A 'yes' or 'no' as to whether DFN is a root cert that browsers are shipped 
> with (and details about this, like, do all 3 major browsers include DFN?)
> 3. A link to a paper, a blog post, or an article somewhere that describes in 
> detail your side of the argument
> 
> Let me emphasize that none of this ultimately matters to the points that were 
> made in the paper.
> 
> Whether the number is 600+ or 300+, it's still an insecure, broken mess.
> 
>> I was under the impression that Bitcoin was the preferred currency of 
>> libertopia. It is the only one that gets mention in the mainstream press. It 
>> is not clear to me how namecoin can be part of BitCoin and another currency.
> 
> 
> I'll be happy to clear this up:
> 
> - Bitcoin is not the "market leader" of distributed DNS systems. Namecoin is.
> - Namecoin and Bitcoin are designed with completely different goals in mind. 
> They are not competitors.
> - Namecoin is not intended to be a bitcoin replacement, nor the other way 
> around. It is not like "litecoin" or any of the other bitcoin competitors, 
> because it is not a competitor to bitcoin.
> 
>> Gold Age, eGold, Liberty Reserve. All the ones that were taken apart by the 
>> Feds.
> 
> 
> I'll be happy to clear this up too:
> 
> None of these are comparable to Bitcoin or Namecoin.
> 
> Neither "Gold Age", nor "eGold", nor "Liberty Reserve" were truly 
> decentralized, distributed currencies.
> 
> - "Gold Age" was not a currency: https://en.wikipedia.org/wiki/Gold_Age
> - eGold: Centralized currency with no "reliable user identification" (not a 
> problem with Bitcoin or Namecoin)
> - Liberty Reserve: Centralized currency 
> https://en.wikipedia.org/wiki/Liberty_Reserve#Background
> 
> People who are standing back and scratching their heads, wondering why 
> Bitcoin is still around after years of being used to purchase illegal drugs, 
> murder-for-hire, and weapons (co

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Phillip Hallam-Baker]

When you make an assertion in a paper then you are accepting the burden of
proof.


If the source for the '600' claim was lying then the claim has to be taken
off the table completely. The DFN root issue demonstrates that the
methodology is bogus rather than just being a single inaccurate data point.

If you want to make assertions about the number of CAs then the most
accurate measure currently available is still the number of roots in the
commonly used browsers. While there are a handful of CAs using roots cross
certified by another CA, such CAs now have to have a full audit statement
and meet all the acceptance criteria in their own right. So there would be
little point in not applying to have the root entered in independently.

Since the 600 number is inaccurate and not particularly necessary, why
bother to quote it at all?




On Mon, Dec 16, 2013 at 1:44 PM, Tao Effect  wrote:

> Which kind of calls their credibility into question. HALF the 'CAs' in
> their graph are from the DFN root. You can check that out for yourself, it
> is a German CA that issues certs to higher education institutions. As has
> been demonstrated (and agreed by the EFF people), DFN do not sign certs for
> key signing keys they do not hold.
>
> You can't calculate the number of CAs the way the EFF tried to. An
> intermediate certificate does not equate to a CA. Pretending it does to
> peddle an alternative PKI scheme calls into question their veracity.
>
> I have tried to get members of the EFF board to look into this but they
> never get back. Too much trouble to get it right.
>
>
> OK, in order for me to correct this in the paper I need the following
> information:
>
> 1. A link to who "DFN" is.
> 2. A 'yes' or 'no' as to whether DFN is a root cert that browsers are
> shipped with (and details about this, like, do all 3 major browsers include
> DFN?)
> 3. A link to a paper, a blog post, or an article somewhere that describes
> in detail your side of the argument
>
> Let me emphasize that none of this ultimately matters to the points that
> were made in the paper.
>
> Whether the number is 600+ or 300+, it's still an *insecure*, *broken*mess.
>
> I was under the impression that Bitcoin was the preferred currency of
> libertopia. It is the only one that gets mention in the mainstream press.
> It is not clear to me how namecoin can be part of BitCoin and another
> currency.
>
>
> I'll be happy to clear this up:
>
> - Bitcoin is not the "market leader" of distributed DNS systems. Namecoin
> is.
> - Namecoin and Bitcoin are designed with completely different goals in
> mind. They are not competitors.
> - Namecoin is not intended to be a bitcoin replacement, nor the other way
> around. It is not like "litecoin" or any of the other bitcoin competitors,
> because it is not a competitor to bitcoin.
>
> Gold Age, eGold, Liberty Reserve. All the ones that were taken apart by
> the Feds.
>
>
> I'll be happy to clear this up too:
>
> *None of these are comparable to Bitcoin or Namecoin.*
>
> Neither "Gold Age", nor "eGold", nor "Liberty Reserve" were truly
> decentralized, distributed currencies.
>
> - "Gold Age" was not a currency: https://en.wikipedia.org/wiki/Gold_Age
> - eGold: *Centralized currency* with no "reliable user 
> identification" (not
> a problem with Bitcoin or Namecoin)
> - Liberty Reserve: *Centralized currency*
> https://en.wikipedia.org/wiki/Liberty_Reserve#Background
>
> People who are standing back and scratching their heads, wondering why
> Bitcoin is still around after years of being used to purchase illegal
> drugs, murder-for-hire, and weapons (continuing to this day btw), simply
> don't understand what Bitcoin is.
>
> I might be a little more inclined to make an effort if you hadn't attacked
> me as being 'fraudulent' in your opening.
>
>
> Do you represent a company that sells SSL certs? It seems like you might:
>
> *During twelve years as Principal Scientist at VeriSign Inc.,*
>
>
> Perhaps the paper is a bit harsh (and I welcome suggestions to improve its
> language), but the critiques it levies against companies that sell SSL
> certs are completely valid:
>
> Companies that sell SSL certificates usually claim that their certificates
> provide customers with “security.” Customers are led to believe that these
> certificates protect browser-server communication from eavesdropping and
> tampering. As elaborated in this paper, this simply isn’t true today.
>
>
> I have to say, that among the cert companies websites that I looked at,
> VeriSign's homepage makes the fewest claims about the security protections
> it provides.
>
> The words "usually claim" leaves room for exceptions. I could not find, on
> the customer-facing pages on VeriSign's site, any claims that VeriSign's
> SSL certs "protect browser-server communication from eavesdropping and
> tampering."
>
> Some close calls are:
>
> *In short, when it comes to securing online transactions, safeguarding
> cust

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Stephen Farrell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hiya,

(As list moderator)

On 12/16/2013 10:12 PM, Tao Effect wrote:
> Next we have to agree who should get the coin.

I don't want to shut this down too quickly but I will point
out that designing protocols via one-by-one mail messages
to an IETF list is not really something that works out so
please let's not go that route.

I'd say if a bunch of folks are interested in this proposal
then better would be to go and get together and work on it
some more and if you're interested in pursuing it in the
IETF then writing an Internet-draft is the way to go. I
assume that interested people will contact Greg and then
self-organise.

If anyone wants to do that and needs help/hints, mail me
offlist.

Thanks,
S.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJSr33CAAoJEC88hzaAX42iqcsIAIus2CxPqxn8m1PJfld24jAm
7PI2hsYkSW+AWsoEVSrqW7ZosFEZV0+6rq38ClXEMWV8Jv7v9eBtjJGS/c5zrpc4
SJGWcsJqfFQEu9dsQNVH9dfvaWKxBvJ+TzXejZsDCw1BbYSSf3M/b7JLkpMEK2Ub
V24t24V8KL0tOyEF9imACxdKA9jJixvN/3oFg2715ySayMIQreGiLElbq/z2Ryqu
kOoJv9ljq2dHtTGot9BstLF+YkiO2nSTxfADSGf5jQEf5uR0dmAEt4uruzWxQUfh
fwDJT6zlvkbk6Go044Qgc3hOyQiD2audYjBv/6KILzOrnSjj6mF3t6L9XcvLhoM=
=DIiL
-END PGP SIGNATURE-
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Tao Effect]

On Dec 16, 2013, at 5:00 PM, Ben Laurie  wrote:

> Fun though it is to debate the merits of bitcoin, the question at hand
> is whether we should form a WG.
> 
> If you want to propose a bitcoin based protocol, go right ahead.

Though this thread is more of an announcement, it can also be considered a 
first draft of a proposal for DNSNMC.

Paper was linked to in the first post, here it is again:

http://okturtles.com/other/dnsnmc_okturtles_overview.pdf

> My difficulties with bitcoin as a whole are on record.

OK... and so are the replies to your paper.

> P.S. I think you're criticising a different paper. For example, this
> one doesn't even mention IP addresses.

What are you mentioning then? What does this paragraph refer to, if not IP 
addresses?

Next we have to agree who should get the coin. This is not particularly hard. 
First we use efficient unbounded agreement to number the current participants11 
sequentially. We then use it to agree a consensus random number. This could be 
done, for example, by agreeing a commitment for each participant, and then 
revealing the value they committed to, adding them all together and taking the 
modulo of that total, which would randomly designate a participant.

Cheers,
Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Dec 16, 2013, at 5:00 PM, Ben Laurie  wrote:

> On 16 December 2013 21:31, Tao Effect  wrote:
>> Hey Ben,
>> 
>> On Dec 14, 2013, at 2:12 PM, Ben Laurie  wrote:
>> 
>> Decentralized: there is no central authority controlling all the names
>> 
>> 
>> If it is based on bitcoin, that is untrue. Or even if not. See
>> http://www.links.org/files/decentralised-currencies.pdf.
>> 
>> 
>> Thank you for the link to this paper.
>> 
>> I needed to find the time to actually read this and get back to you. I've
>> now done this.
>> 
>> You've posted this reply to a number of lists that we're both subscribed to,
>> so I'm going to send this reply to each one:
> 
> Fun though it is to debate the merits of bitcoin, the question at hand
> is whether we should form a WG.
> 
> If you want to propose a bitcoin based protocol, go right ahead.
> 
> My difficulties with bitcoin as a whole are on record. I may have more
> to say about a specific I-D.
> 
> P.S. I think you're criticising a different paper. For example, this
> one doesn't even mention IP addresses.
> ___
> therightkey mailing list
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Tao Effect]

Hey Ben,

On Dec 14, 2013, at 2:12 PM, Ben Laurie  wrote:

>> Decentralized: there is no central authority controlling all the names
> 
> If it is based on bitcoin, that is untrue. Or even if not. See
> http://www.links.org/files/decentralised-currencies.pdf.

Thank you for the link to this paper.

I needed to find the time to actually read this and get back to you. I've now 
done this.

You've posted this reply to a number of lists that we're both subscribed to, so 
I'm going to send this reply to each one:

My reply can be summarized (mostly) by Vladimir's response to your paper here:

https://bitcointalk.org/index.php?topic=25760.msg372591#msg372591

For the list's sake, here are the salient points Sir Vladimir makes:

Than, first of all, he is trying to solve a non-problem and fails to see that 
issue he is trying to solve is not a bug but a feature.

This is in reference to your criticism of proof-of-work. Here's the rest of his 
comment on that particular point:

There is no problem with energy consumption, it is a very low price to
pay for getting rid of all the middlemen leaching a few percent from
every money transfer. Moreover, energy spent by miners on securing the
bloc chain is rather negligible in comparison to energy spent on other
ways to do money, when you consider, for example energy, required to
haul all the cash and gold in armoured trucks, smelting gold bullions,
coining coins, smelting metal for the bank vaults and so on...

Second criticism of your paper is as follows (again, I'll just copy Vlad's 
comments here):

Second of all, his "efficient solution" is very weak. Essentially, he
is proposing to replace voting weighted by pure computational power
(surely not very energy efficient way) to voting weighted by a number
of clients plugged into the network, without proposing any viable way
(since it is impossible) to ensure that this number of clients is not
faked. Therefore, he is effectively shifting proof-of-work concept
from doing lots of sha-256 calculations to opening lots of ports on
lots of IP's simultaneously. This could solve a problem of quick
propagations and wide distribution of information, but surely not a
problem of "double spending". Total epic fail!

Somehow, you seem to have completely missed the point of Bitcoin's 
proof-of-work. It's right there in the original paper:

The proof-of-work also solves the problem of determining representation in 
majority decision making. If the majority were based on 
one-IP-address-one-vote, it could be subverted by anyone able to allocate many 
IPs. Proof-of-work is essentially one-CPU-one-vote.

Vladimir made one final comment (not too important though, but I'll include it 
anyway):

He also has completely missed economic part of the system where
initial bitcoin inflation serves the purpose of subsidy to enable
quick growth of the network and making it secure from 50% attacks.

However, all of these points made by Vladimir do not destroy the point your 
paper makes entirely. They just badly bruise it.

IMO, the only legitimate criticism of Bitcoin contained in your paper is the 
following:

If, for example, 1% of the total power available7 is used to produce Bitcoins 
at present (in fact, the amount is far less than that), then at any point 
someone could come along with a further 1.1% of the total power and use this to 
define their own consensus8 , thus invalidating all the work, and all the 
money, of the initial group, and instead take possession of the entire currency 
for themselves.

This is referring to (or at least should be referring to) the idea of an 
attacker making their own "fake fork" that they control through superior-CPU 
power.

The strength of your argument (IMO) rests on this one issue: Whether or not 
there exists an attacker with the computational power necessary to take over 
the network.

This is a legitimate question, and combined with the observations made by 
Vladimir, it implies two takeaway points:

1. Your suggestion for an "efficient alternative" to Bitcoin appears to be 
inferior to Bitcoin because it appears to be based on one-IP-one-vote (rejected 
in the original paper).

2. Bitcoin's legitimacy and trustworthiness depends on whether or not there 
exists (or can exist) an entity with more horsepower than all more than 50% of 
the nodes on the network. This is old news.

The Bitcoin community has been discussing the 51% attack for a while and 
appears to be working on addressing the issue:

https://en.bitcoin.it/wiki/Proof_of_blockchain_fair_sharing

In case it's of interest to someone, here are two sites about known attacks on 
Bitcoin:

http://codinginmysleep.com/bitcoin-attacks-in-plain-english/
https://en.bitcoin.it/wiki/Double-spending

Cheers,
Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
therightkey mailing list
therightk

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Tao Effect]

> Which kind of calls their credibility into question. HALF the 'CAs' in their 
> graph are from the DFN root. You can check that out for yourself, it is a 
> German CA that issues certs to higher education institutions. As has been 
> demonstrated (and agreed by the EFF people), DFN do not sign certs for key 
> signing keys they do not hold.
> 
> You can't calculate the number of CAs the way the EFF tried to. An 
> intermediate certificate does not equate to a CA. Pretending it does to 
> peddle an alternative PKI scheme calls into question their veracity.
> 
> I have tried to get members of the EFF board to look into this but they never 
> get back. Too much trouble to get it right.


OK, in order for me to correct this in the paper I need the following 
information:

1. A link to who "DFN" is.
2. A 'yes' or 'no' as to whether DFN is a root cert that browsers are shipped 
with (and details about this, like, do all 3 major browsers include DFN?)
3. A link to a paper, a blog post, or an article somewhere that describes in 
detail your side of the argument

Let me emphasize that none of this ultimately matters to the points that were 
made in the paper.

Whether the number is 600+ or 300+, it's still an insecure, broken mess.

> I was under the impression that Bitcoin was the preferred currency of 
> libertopia. It is the only one that gets mention in the mainstream press. It 
> is not clear to me how namecoin can be part of BitCoin and another currency.


I'll be happy to clear this up:

- Bitcoin is not the "market leader" of distributed DNS systems. Namecoin is.
- Namecoin and Bitcoin are designed with completely different goals in mind. 
They are not competitors.
- Namecoin is not intended to be a bitcoin replacement, nor the other way 
around. It is not like "litecoin" or any of the other bitcoin competitors, 
because it is not a competitor to bitcoin.

> Gold Age, eGold, Liberty Reserve. All the ones that were taken apart by the 
> Feds.


I'll be happy to clear this up too:

None of these are comparable to Bitcoin or Namecoin.

Neither "Gold Age", nor "eGold", nor "Liberty Reserve" were truly 
decentralized, distributed currencies.

- "Gold Age" was not a currency: https://en.wikipedia.org/wiki/Gold_Age
- eGold: Centralized currency with no "reliable user identification" (not a 
problem with Bitcoin or Namecoin)
- Liberty Reserve: Centralized currency 
https://en.wikipedia.org/wiki/Liberty_Reserve#Background

People who are standing back and scratching their heads, wondering why Bitcoin 
is still around after years of being used to purchase illegal drugs, 
murder-for-hire, and weapons (continuing to this day btw), simply don't 
understand what Bitcoin is.

> I might be a little more inclined to make an effort if you hadn't attacked me 
> as being 'fraudulent' in your opening.


Do you represent a company that sells SSL certs? It seems like you might:

During twelve years as Principal Scientist at VeriSign Inc.,

Perhaps the paper is a bit harsh (and I welcome suggestions to improve its 
language), but the critiques it levies against companies that sell SSL certs 
are completely valid:

Companies that sell SSL certificates usually claim that their certificates 
provide customers with “security.” Customers are led to believe that these 
certificates protect browser-server communication from eavesdropping and 
tampering. As elaborated in this paper, this simply isn’t true today.

I have to say, that among the cert companies websites that I looked at, 
VeriSign's homepage makes the fewest claims about the security protections it 
provides.

The words "usually claim" leaves room for exceptions. I could not find, on the 
customer-facing pages on VeriSign's site, any claims that VeriSign's SSL certs 
"protect browser-server communication from eavesdropping and tampering."

Some close calls are:

In short, when it comes to securing online transactions, safeguarding customer 
information, and protecting business reputation, you're only as safe as the 
Certificate Authority you choose.
https://www.symantec.com/ssl-certificates-advantages

Customers Gain Confidence with the Green Address Bar: Online shoppers recognize 
the green address bar as an easy and reliable way to verify the site identity 
and security.
https://www.symantec.com/verisign/ssl-certificates/secure-site-pro-ev?fid=ssl-certificates

VeriSign's SSL certificates do not provide websites with meaningful protection 
as defined in the DNSNMC paper because they cannot be securely authenticated in 
the face of a fraudulent certificate that's presented to customers by a MITM.

If your certs can simply be replaced by any of the other CAs out there, then 
*all* of the security they provide is thrown out the window.

Furthermore, because VeriSign is a random third-party, not the company that 
user's visit when they visit a site using VeriSign's certificate, the 
protection offered by that certificate is inherently inferior to a securely 
authenticated sel

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Rob Stradling]

On 16/12/13 14:31, Phillip Hallam-Baker wrote:


That does not excuse

1) Failing to examine the issue when the DFN root accounted for half of
the purported '600 CAs'

2) Continuing to count the DFN as 300 CAs when they know it is one.

Putting out sloppy research and then failing to correct it when a
mistake is committed is the problem. If someone publishes a flawed study
I expect them to withdraw it when the errors are pointed out. I don't
expect them to say that they are going to continue to publish a number
they know is out by a factor of at least 2 because getting a correct
number would be too much work.


FWIW, I suggested to Mozilla a few months ago that they could survey the 
CAs in order to find out the correct number (or, at least, a rather more 
accurate approximation!)


They seemed interested.

The conversation was somewhere in the middle of this thread...
http://mozilla.6506.n7.nabble.com/SSL-TLS-and-HTTPS-in-a-Post-Prism-Era-td294842.html

--
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] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Leif Johansson]

On 2013-12-16 15:31, Phillip Hallam-Baker wrote:
>
>
>
> On Mon, Dec 16, 2013 at 1:32 AM, Leif Johansson  > wrote:
>
>
>
> 16 dec 2013 kl. 03:21 skrev Phillip Hallam-Baker  >:
>
>>
>>
>>
>> On Sun, Dec 15, 2013 at 8:50 PM, Tao Effect
>> mailto:cont...@taoeffect.com>> wrote:
>>
>>> And for someone who is accusing others of being
>>> 'fraudulent', not a good move to start off repeating figures
>>> already exposed as bogus like the oft repeated but still
>>> untrue claim of 600 CAs.
>>
>> I thought the EFF was a reputable source.
>>
>> There has been no update or correction to their
>> post: https://www.eff.org/deeplinks/2011/10/how-secure-https-today
>>
>>
>> Which kind of calls their credibility into question. HALF the
>> 'CAs' in their graph are from the DFN root. You can check that
>> out for yourself, it is a German CA that issues certs to higher
>> education institutions. As has been demonstrated (and agreed by
>> the EFF people), DFN do not sign certs for key signing keys they
>> do not hold.
>>
>
> yep, DFN is a 'private' sub-CA under tight control but it could
> still be attacked the way diginotar was and though I believe their
> secuity is a lot better than their less fortunate Dutch cousins, a
> successful attack would be just as bad.
>
>
>
> That does not excuse 
>
> 1) Failing to examine the issue when the DFN root accounted for half
> of the purported '600 CAs'
>
> 2) Continuing to count the DFN as 300 CAs when they know it is one.
>

agree

>
> Putting out sloppy research and then failing to correct it when a
> mistake is committed is the problem. If someone publishes a flawed
> study I expect them to withdraw it when the errors are pointed out. I
> don't expect them to say that they are going to continue to publish a
> number they know is out by a factor of at least 2 because getting a
> correct number would be too much work.
>
> If people are going to make pointed accusations about the
> trustworthiness of others then they had better not continue to
> knowingly publish false data.
>
>
> As with the 'Al Gore claimed to invent the internet' lie, this has
> become a zombie lie that is repeated to make a political point by
> people who don't really care if what they are saying is true or not.
>
> I think that is a problem. And I am going to continue to point out
> that the EFF is peddling a lie until they withdraw it.
>
> -- 
> Website: http://hallambaker.com/

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

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Phillip Hallam-Baker]

On Mon, Dec 16, 2013 at 1:32 AM, Leif Johansson  wrote:

>
>
> 16 dec 2013 kl. 03:21 skrev Phillip Hallam-Baker :
>
>
>
>
> On Sun, Dec 15, 2013 at 8:50 PM, Tao Effect  wrote:
>
>> And for someone who is accusing others of being 'fraudulent', not a good
>> move to start off repeating figures already exposed as bogus like the oft
>> repeated but still untrue claim of 600 CAs.
>>
>>
>> I thought the EFF was a reputable source.
>>
>> There has been no update or correction to their post:
>> https://www.eff.org/deeplinks/2011/10/how-secure-https-today
>>
>
> Which kind of calls their credibility into question. HALF the 'CAs' in
> their graph are from the DFN root. You can check that out for yourself, it
> is a German CA that issues certs to higher education institutions. As has
> been demonstrated (and agreed by the EFF people), DFN do not sign certs for
> key signing keys they do not hold.
>
>
> yep, DFN is a 'private' sub-CA under tight control but it could still be
> attacked the way diginotar was and though I believe their secuity is a lot
> better than their less fortunate Dutch cousins, a successful attack would
> be just as bad.
>


That does not excuse

1) Failing to examine the issue when the DFN root accounted for half of the
purported '600 CAs'

2) Continuing to count the DFN as 300 CAs when they know it is one.


Putting out sloppy research and then failing to correct it when a mistake
is committed is the problem. If someone publishes a flawed study I expect
them to withdraw it when the errors are pointed out. I don't expect them to
say that they are going to continue to publish a number they know is out by
a factor of at least 2 because getting a correct number would be too much
work.

If people are going to make pointed accusations about the trustworthiness
of others then they had better not continue to knowingly publish false data.


As with the 'Al Gore claimed to invent the internet' lie, this has become a
zombie lie that is repeated to make a political point by people who don't
really care if what they are saying is true or not.

I think that is a problem. And I am going to continue to point out that the
EFF is peddling a lie until they withdraw it.

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

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Leif Johansson]

> 16 dec 2013 kl. 03:21 skrev Phillip Hallam-Baker :
> 
> 
> 
> 
> On Sun, Dec 15, 2013 at 8:50 PM, Tao Effect  wrote:
>>> And for someone who is accusing others of being 'fraudulent', not a good 
>>> move to start off repeating figures already exposed as bogus like the oft 
>>> repeated but still untrue claim of 600 CAs.
>> 
>> 
>> I thought the EFF was a reputable source.
>> 
>> There has been no update or correction to their post: 
>> https://www.eff.org/deeplinks/2011/10/how-secure-https-today
> 
> Which kind of calls their credibility into question. HALF the 'CAs' in their 
> graph are from the DFN root. You can check that out for yourself, it is a 
> German CA that issues certs to higher education institutions. As has been 
> demonstrated (and agreed by the EFF people), DFN do not sign certs for key 
> signing keys they do not hold.
> 

yep, DFN is a 'private' sub-CA under tight control but it could still be 
attacked the way diginotar was and though I believe their secuity is a lot 
better than their less fortunate Dutch cousins, a successful attack would be 
just as bad.

> You can't calculate the number of CAs the way the EFF tried to. An 
> intermediate certificate does not equate to a CA. Pretending it does to 
> peddle an alternative PKI scheme calls into question their veracity.
> 
> I have tried to get members of the EFF board to look into this but they never 
> get back. Too much trouble to get it right.
> 
> 
>>> Tying the notary log to namecoin seems to be completely pointless to me, 
>>> unless the real objective is to promote namecoin. Why hook into namecoin 
>>> rather than the market leader? 
>> 
>> 
>> What market leader?
> 
> I was under the impression that Bitcoin was the preferred currency of 
> libertopia. It is the only one that gets mention in the mainstream press. It 
> is not clear to me how namecoin can be part of BitCoin and another currency.
> 
>  
>>> Given the success of the US government in shutting down eGold type schemes 
>>> I am very skeptical about the stability of 'namecoin'. If we accept the 
>>> purported scenarios that motivate the scheme then namecoin won't last very 
>>> long.
>> 
>> What eGold scheme are you comparing Namecoin to?
> 
> Gold Age, eGold, Liberty Reserve. All the ones that were taken apart by the 
> Feds.
> 
>  
>> Are you sure you know what you're talking about here...? ;-)
> 
> I must admit that I find the scheme completely confused and assumes that I 
> know a lot that I do not.
> 
> I might be a little more inclined to make an effort if you hadn't attacked me 
> as being 'fraudulent' in your opening.
>  
> 
> -- 
> Website: http://hallambaker.com/
> ___
> 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] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Phillip Hallam-Baker]

On Sun, Dec 15, 2013 at 8:50 PM, Tao Effect  wrote:

> And for someone who is accusing others of being 'fraudulent', not a good
> move to start off repeating figures already exposed as bogus like the oft
> repeated but still untrue claim of 600 CAs.
>
>
> I thought the EFF was a reputable source.
>
> There has been no update or correction to their post:
> https://www.eff.org/deeplinks/2011/10/how-secure-https-today
>

Which kind of calls their credibility into question. HALF the 'CAs' in
their graph are from the DFN root. You can check that out for yourself, it
is a German CA that issues certs to higher education institutions. As has
been demonstrated (and agreed by the EFF people), DFN do not sign certs for
key signing keys they do not hold.

You can't calculate the number of CAs the way the EFF tried to. An
intermediate certificate does not equate to a CA. Pretending it does to
peddle an alternative PKI scheme calls into question their veracity.

I have tried to get members of the EFF board to look into this but they
never get back. Too much trouble to get it right.


Tying the notary log to namecoin seems to be completely pointless to me,
> unless the real objective is to promote namecoin. Why hook into namecoin
> rather than the market leader?
>
>
> What market leader?
>

I was under the impression that Bitcoin was the preferred currency of
libertopia. It is the only one that gets mention in the mainstream press.
It is not clear to me how namecoin can be part of BitCoin and another
currency.



> Given the success of the US government in shutting down eGold type schemes
> I am very skeptical about the stability of 'namecoin'. If we accept the
> purported scenarios that motivate the scheme then namecoin won't last very
> long.
>
>
> What eGold scheme are you comparing Namecoin to?
>

Gold Age, eGold, Liberty Reserve. All the ones that were taken apart by the
Feds.



> Are you sure you know what you're talking about here...? ;-)
>

I must admit that I find the scheme completely confused and assumes that I
know a lot that I do not.

I might be a little more inclined to make an effort if you hadn't attacked
me as being 'fraudulent' in your opening.


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

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Tao Effect]

> And for someone who is accusing others of being 'fraudulent', not a good move 
> to start off repeating figures already exposed as bogus like the oft repeated 
> but still untrue claim of 600 CAs.

I thought the EFF was a reputable source.

There has been no update or correction to their post: 
https://www.eff.org/deeplinks/2011/10/how-secure-https-today

If this information is incorrect please provide a link with more details. If 
the EFF is wrong about this, then I'll make sure to update the paper.

> Tying the notary log to namecoin seems to be completely pointless to me, 
> unless the real objective is to promote namecoin. Why hook into namecoin 
> rather than the market leader? 


What market leader?

> Given the success of the US government in shutting down eGold type schemes I 
> am very skeptical about the stability of 'namecoin'. If we accept the 
> purported scenarios that motivate the scheme then namecoin won't last very 
> long.

What eGold scheme are you comparing Namecoin to?

Are you sure you know what you're talking about here...? ;-)

Cheers,
Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Dec 14, 2013, at 12:51 PM, Phillip Hallam-Baker  wrote:

> "The first project, DNSNMC, deprecates today's insecure and fraudulent1 
> public key infrastructure (PKI) by gracefully transitioning DNS from its 
> hierarchical design, to one that is based on a globally distributed, 
> peer-to-peer network that successfully "squares Zooko's triangle""
> 
> I think you have lost me already. If you want to get anywhere with a proposal 
> probably not a good idea to accuse the people who might implement it as being 
> 'fraudulent'.
> 
> 
> "We use the term “meaningful security” to refer to the security provided by 
> protocols that employ all of these features for communication between 
> individuals."
> 
> Have you paused to consider the reasons why the market has not adopted the 
> security mechanisms then embody those principles to date? Designing a spec 
> that provides more security if used is trivial. The hard part is proposing 
> something that is secure and usable.
> 
> 
> And for someone who is accusing others of being 'fraudulent', not a good move 
> to start off repeating figures already exposed as bogus like the oft repeated 
> but still untrue claim of 600 CAs.
> 
> Tying the notary log to namecoin seems to be completely pointless to me, 
> unless the real objective is to promote namecoin. Why hook into namecoin 
> rather than the market leader? 
> 
> 
> Given the success of the US government in shutting down eGold type schemes I 
> am very skeptical about the stability of 'namecoin'. If we accept the 
> purported scenarios that motivate the scheme then namecoin won't last very 
> long.
> 
> The fact that BitCoin has survived this long is rather surprising. We have 
> already seen a huge robbery of over $200 million in bitcoin (from a drug 
> dealer). And now we have people trying to de-anonymize the system to stop the 
> coins being spent (!)
> 
> When the feds moved on the e-Gold crowd they started off by rolling up the 
> small guys and created a crisis of confidence in the big ones. What would be 
> the effect on the price of Bitcoin if the feds shut down namecoin using the 
> same tactics they used against mega-upload? I don't think it would take much 
> to start a run. 
> 
> 
> ___
> therightkey mailing list
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Leif Johansson]

On 2013-12-14 20:25, Ali-Reza Anghaie wrote:
> On Sat, Dec 14, 2013 at 12:51 PM, Phillip Hallam-Baker  
> wrote:
>> Given the success of the US government in shutting down eGold type schemes I
>> am very skeptical about the stability of 'namecoin'. If we accept the
>> purported scenarios that motivate the scheme then namecoin won't last very
>> long.
> Aside from the tactful / lack thereof issues in the delivery - this is
> a key point not addressed in the proposal. Adoption requires not only
> a State unwilling to quash it but ISPs and other providers willing to
> support it. This isn't just a US issue, it's quite prevalent an issue
> in every moderately to well connected State.
>
>
Its still interesting to consider distributed proof-of-work systems
_like_ bitcoin as a basis for public ledger systems. I realize that this
isn't exactly what this proposal is about.

I also see quite a few challenges with this proposal. For instance I
don't see how running and trusting your own DNSNMC server is
significantly different (or easier) than running and trusting your own CA.

However, distributed systems like this should not be dismissed offhand
as inherently un-deployable by using, what are essentially
guilt-by-association arguments.

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

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Ali-Reza Anghaie]

On Sat, Dec 14, 2013 at 12:51 PM, Phillip Hallam-Baker  wrote:
> Given the success of the US government in shutting down eGold type schemes I
> am very skeptical about the stability of 'namecoin'. If we accept the
> purported scenarios that motivate the scheme then namecoin won't last very
> long.

Aside from the tactful / lack thereof issues in the delivery - this is
a key point not addressed in the proposal. Adoption requires not only
a State unwilling to quash it but ISPs and other providers willing to
support it. This isn't just a US issue, it's quite prevalent an issue
in every moderately to well connected State.

I see nothing in this proposal as of now that I could see any major
provider getting behind in a major way.

> The fact that BitCoin has survived this long is rather surprising. We have
> already seen a huge robbery of over $200 million in bitcoin (from a drug
> dealer). And now we have people trying to de-anonymize the system to stop
> the coins being spent (!)

I'm not sure I agree here - I think it has a lot of believers but also
as importantly it has a lot of power brokers perfectly happy to let it
thrive in the niche area where it can be corralled into easily
identified groups. This tactic will fail the State with other Bitcoin
derivatives but the initial runup (which we're still in) somewhat
reflects a normal permissive environment with the hopes of
criminalization benefits to the State.

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

Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

[Phillip Hallam-Baker]

"The first project, DNSNMC, deprecates today's insecure and fraudulent1 public
key infrastructure (PKI) by gracefully transitioning DNS from its
hierarchical design, to one that is based on a globally distributed,
peer-to-peer network that successfully "squares Zooko's triangle""

I think you have lost me already. If you want to get anywhere with a
proposal probably not a good idea to accuse the people who might implement
it as being 'fraudulent'.


"We use the term “meaningful security” to refer to the security provided by
protocols that employ all of these features for communication between
individuals."

Have you paused to consider the reasons why the market has not adopted the
security mechanisms then embody those principles to date? Designing a spec
that provides more security if used is trivial. The hard part is proposing
something that is secure and usable.


And for someone who is accusing others of being 'fraudulent', not a good
move to start off repeating figures already exposed as bogus like the oft
repeated but still untrue claim of 600 CAs.

Tying the notary log to namecoin seems to be completely pointless to me,
unless the real objective is to promote namecoin. Why hook into namecoin
rather than the market leader?


Given the success of the US government in shutting down eGold type schemes
I am very skeptical about the stability of 'namecoin'. If we accept the
purported scenarios that motivate the scheme then namecoin won't last very
long.

The fact that BitCoin has survived this long is rather surprising. We have
already seen a huge robbery of over $200 million in bitcoin (from a drug
dealer). And now we have people trying to de-anonymize the system to stop
the coins being spent (!)

When the feds moved on the e-Gold crowd they started off by rolling up the
small guys and created a crisis of confidence in the big ones. What would
be the effect on the price of Bitcoin if the feds shut down namecoin using
the same tactics they used against mega-upload? I don't think it would take
much to start a run.
___
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey