Subject: Re: [keyassure] Thanks for starting this - my wishlist :)

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 18 Aug 2010 16:35:53 -0500 (GMT-05:00)

Phillip and all,

-----Original Message-----
>From: Phillip Hallam-Baker <[email-masked]>
>Sent: Aug 18, 2010 2:08 PM
>To: [email-masked]
>Subject: Re: [keyassure] Thanks for starting this - my wishlist :)
>
>I agree with what Andrew is saying here. But this is a discussion that
>is in-charter for DNSEXT.
>
>Basically I am seeing people looking at DNSCURVE for last hop and
>there are certainly many people doing IPSEC. As a security specialist,
>I know that there are security capabilities I can provide in that
>model that are not possible through endpoint security alone.
>
>My view is that where the validation takes place is for applications
>and users to decide. It may even make sense to have no validation at
>all. I have argued for years that Web Browsers should not provide a
>warning when a site offers a self-signed cert, the browser should
>simply turn on the crypto and not tell the user about it at all. If
>the web browser will take the user to a site without any crypto
>without a warning it should accept imperfect crypto on the same basis.

In part I agree here.  However not telling the user of the use of a
cert, self-signed or not is not a good thing.  Indeed though there
is not such thing as 'perfict' crypto so accepting any of same is
or should be a user choice.
>
>In the medium term, neither IPSEC or DNSCURVE (or SSL) are ideal for
>this purpose. We can do better, but I won't elaborate the reasons why
>here.

Agreed strongly here as well...
>
>
>On Wed, Aug 18, 2010 at 2:06 PM, Andrew Sullivan <[email-masked]> wrote:
>> On Wed, Aug 18, 2010 at 10:34:08AM -0700, Nicholas Weaver wrote:
>>
>>> NOTHING I said implied that the application does the validating,
>>
>> Well, there were two ways I found to interpret your argument, and the
>> other one seemed to me to be the well-worn arguments about why
>> offloading to an upstream validator was a Bad Idea.  I didn't figure
>> you'd be hauling that argument to this list from another one, but I
>> guess I was wrong.  In the enterprise situation, we _have_ an
>> implementer who is using the AD bit and IPSEC for the last hop.  You
>> keep insisting that's a dangerous model, but in the enterprise
>> environment it isn't necessarily (and arguing from home-user-to-ISP
>> analogies is simply irrelevant).
>>
>> The trouble in the case of the AD bit is that it's too little
>> information.  But we don't get to dismiss that use case just because
>> we're currently not sure how to answer the query.  And we might have
>> an opportunity here to address such issues (I kinda doubt it, but
>> maybe).
>>
>>> to do the validating: the application NEEDS to tell the host to
>>> validate and how to treat validation failures (because the default
>>> will be wrong, no matter what the default is, unless the default is
>>
>> I think this is right.  It sounds to me like an API issue.  The
>> present one is likely the wrong list for that, though.  I wish I knew
>> what to suggest apart from dnssec-deployment.
>>
>>> And that using such an API for validating A records is useless,
>>> since any application thats smart enough to bother asking "is this A
>>> record validated" is smart enough to realize that the A record
>>> validation is meaningless [1]: a corrupted A record is just simply
>>> one of many possible MitM attacks, so focus on blocking MitM
>>> attacks, not A records: from an application viewpoint, there is no
>>> difference between a poisoned DNS entry, a poisoned ARP cache, BGP
>>> games, or a WiFi packet injector: a MitM is a MitM.
>>
>> So your argument is that if the DNSSEC validation comes back correct,
>> we still aren't sure routing hasn't been compromised, so this is all
>> useless?  Surely that's wrong.  Another way to do this would be to
>> offload the validation to a trusted DNS server and offload similar
>> validation for BGP &c. to something else, no?  I don't really want my
>> phone doing hundreds of DNSSEC validation calculations for every
>> cnn.com page view, do I?
>>
>>> And, frankly speaking, the "benefits" from DNSSEC only come when the
>>> application is aware of DNSSEC
>>
>> I happen to think it is an advantage if I push validation to some
>> layer (or system) I don't have to worry too much about, and then
>> simply get a failure when someone is spoofing the DNS answer.  I
>> cheerfully concede it's not a complete solution to every possible
>> problem; but if I were interested in solving world peace and hunger,
>> I'd be a diplomat or a missionary rather than a geek.  You appear to
>> be arguing that because DNSSEC validation successes do not prevent
>> attacks on the routing infrastructur, therefore DNSSEC validation does
>> no good.  That strikes me as a hard position to maintain.
>>
>>
>> --
>> Andrew Sullivan
>> [email-masked]
>> Shinkuro, Inc.
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>>
>
>
>
>-- 
>Website: http://hallambaker.com/
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827