Masataka Ohta | 1 Mar 2010 22:13
Picon

Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)

Phillip Hallam-Baker wrote:

> Moving to DNSSEC, regardless of the technical model does not eliminate
> the need for certificates or CAs. The purpose of EV certificates is to
> re-establish the principle of accountability.

I don't know what EV means, but anything human, including CA, is not
infallible, which is why PKI is insecure.

Is EV divine?

						Masataka Ohta
Wassim Haddad | 1 Mar 2010 22:21
Picon

Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)

On Mon, Mar 1, 2010 at 2:13 PM, Masataka Ohta <mohta <at> necom830.hpcl.titech.ac.jp> wrote:

Phillip Hallam-Baker wrote:

> Moving to DNSSEC, regardless of the technical model does not eliminate
> the need for certificates or CAs. The purpose of EV certificates is to
> re-establish the principle of accountability.

I don't know what EV means, but anything human, including CA, is not
infallible, which is why PKI is insecure.

=> Can you please explain in few lines what would be your preference(s) for a solution to enable
DNSsec?
I apologize if you have already submitted a proposal about it which I must have missed... in which case,
I would appreciate a pointer.


Regards,

Wassim H.
 

_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Masataka Ohta | 1 Mar 2010 23:02
Picon

Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)

Wassim Haddad wrote:

>>I don't know what EV means, but anything human, including CA, is not
>>infallible, which is why PKI is insecure.

> => Can you please explain in few lines what would be your preference(s) for
> a solution to enable DNSsec?
> I apologize if you have already submitted a proposal about it which I must
> have missed... in which case, I would appreciate a pointer.

If you are talking about a technical mechanism not to cause message
size overflow beyond 512B even with 2048bit keys, the solution is
to use different RR types for different kind of keys, which I
proposed more than 15 yeas ago in draft-ohta-simple-dns-00:

   In general, data size for authentication is often as large as of 100
   bytes or more.  So, it is a bad idea to share a single RR type value
   between different authentication mechanisms, because querying them
   all will often break 512 byte limit of UDP query.  So, authentication
   algorithms are distinguished by RR type values, not by something like
   an algorithm type field.

It's crazy to share an RR type between ZSK and KSK.

For key roll over, different RR types should be used for even and
odd generations. You may also use elliptic curve cryptography,
though I don't prefer it.

But, later, I noticed fundamental fraud in PKI, against which no
technical solution exists. Note that separation of ZSK and KSK
was an impossible attempt make inherently insecure PKI less
insecure.

						Masataka Ohta
Shumon Huque | 2 Mar 2010 18:26

Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)

On Tue, Mar 02, 2010 at 06:13:28AM +0900, Masataka Ohta wrote:
> Phillip Hallam-Baker wrote:
> 
> > Moving to DNSSEC, regardless of the technical model does not eliminate
> > the need for certificates or CAs. The purpose of EV certificates is to
> > re-establish the principle of accountability.
> 
> I don't know what EV means, but anything human, including CA, is not
> infallible, which is why PKI is insecure.

"EV" = Extended Validation certificates.

Re-establishing (Establishing?) the concept of accountability, I think, 
requires more than introduction of EV certificates. Assuming that there 
is even agreement that they have a more accountable CPS, it also requires
removal of the allegedly non-accountable CAs from trust anchor lists.
This hasn't happened.

There is also the question of the actual effectiveness of EV
certificates. Do they really work? Can their indicators be spoofed?
And can normal users use their visual cues to actually make informed 
security decisions? There appears to be a growing body of empirical
work that shows that the typical user is unable to make effective 
security decisions based on certificates and their complex set of 
indicators (whether they are EV branded or not).

Here are a few pointers, which I'm sure many folks on this list are
well aware of ..

* An Evaluation of Extended Validation and Picture-in-Picture Phishing Attacks
  ISSN    0302-9743 (Print) 1611-3349 (Online)
  Financial Cryptography and Data Security, 2007
  http://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf

* Why Phishing Works
  http://people.seas.harvard.edu/~rachna/papers/why_phishing_works.pdf
  2006

* The Emperor's New Security Indicators: An evaluation of website
  authentication and the effect of role playing on usability studies.
  http://www.usablesecurity.org/emperor/
  May 2007

* Crying Wolf: An Empirical Study of SSL Warning Effectiveness
  http://www.usenix.org/events/sec09/tech/full_papers/sunshine.pdf
  July 2009

And the paper I know of that supports the effectiveness of EV:

* Extended Validation SSL: Green Address Bar Consumer Research
  Verisign/Thawte/Tec-Ed study:
  http://www.verisign.com.sg/guide/ssl-ev/EV-SSL-GreenBarResearch.pdf

There have been extensive discussions on this topic on various other
lists (cryptography, w3c, etc), and I'm not sure I look forward to
seeing all of it rehashed on the IETF list. But I would be interested
in pointers to other credible studies on this topic.

--Shumon.
Masataka Ohta | 2 Mar 2010 21:29
Picon

Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)

Shumon Huque wrote:

> "EV" = Extended Validation certificates.

Extending human validation is still human.

> Re-establishing (Establishing?) the concept of accountability, 

No, thanks.

For accountability with regard to full compensation for losses, that
is, *M*O*N*E*Y*, CAs are not accountable at all.

That's all.

							Masataka Ohta

Gmane