Re: https at ietf.org

[Phillip Hallam-Baker <[e-mail]>]

On Tue, Dec 10, 2013 at 2:43 PM, Doug Barton <[e-mail]> wrote:

> On 12/10/2013 06:00 AM, John C Klensin wrote:
>
>>
>> As previously mentioned, these attacks are theoretically possible, but
> they are trivially detectable since all of the critical data is visible in
> the DNS. They may not be _immediately_ detectable, and in fact likely would
> not be detected immediately; where "immediate" is going to vary widely
> depending on the value/profile of the target. But we have plenty of
> experience with people noticing DNS problems for critical resources. Even
> in the DNSSEC case we have major players doing DNSSEC validation now
> (Comcast and Google leap to mind) so shenanigans involving DNSSEC are going
> to be noticed.
>

As we learned with the WebPKI, that is only the case if you have a deployed
monitoring infrastructure. It is not that difficult to do but you do have
to do it.


> The point I'm trying to get across here is that any sort of manipulation
> of the DNS by a 3rd party (such as a malicious hack, NSL, etc.) is valuable
> only to the extent that it can go unnoticed, and therefore cause innocent
> end users to depend on the 3rd party's resources instead of the valid ones
> _without their knowledge_.
>

Covert attacks are detectable. But that is only a defense if you have the
ability to switch to another root or override the trust assertions of the
root.


We don't need DNSSEC to see that this sort of thing only works for a
> limited time. We have had lots of events where high profile sites have had
> their registrar data changed, and there is a huge public hue and cry. Of
> course a skillful attacker could create a phishing page that looks enough
> like the real site to gather a non-trivial number of user passwords, but
> again, we don't need DNSSEC for that. In fact, if the sophisticated
> attacker manages to socially engineer the registrar credentials (the most
> popular form of this type of attack) then they can update the DS record in
> addition to the NS records, and have a fake site that validates perfectly.
>

But people do need to be careful about DANE and about Certificate pinning.



> But even that sort of attack would only work for a short period of time.
> More importantly, the ability to slide the malicious data into the DNS at
> all is going to be proportional to the location of the resource in the
> tree. We already know that individual zones are vulnerable to registrar
> attacks. However new TLD DS records in the root are greeted with fanfare
> (at least amongst a fairly substantial number of DNS wonks), so the ability
> to slip stuff in at that level is minimal at best. This is more true at the
> root itself.
>
> So to be concise (yeah, I know, too late) claiming that DNSSEC is
> vulnerable to external manipulation at the root or TLD level is almost
> certainly wrong. There are theoretical attacks that could be launched, but
> their practical value is nil. If someone has a valid attack that uses a
> method I haven't taken into account, they should find a trusted channel to
> make that known.


If we are comparing like with like, the practical value of the attacks
against the WebPKI have been limited, with the exception of DigiNotar


 (2) In a different version of some of the comments on the
>> thread, the "where to validate" question is important.  If one
>> tries to validate at the endpoints, endpoint systems, including
>> embedded ones, should have the code and resources needed to
>> validate certs and handle rollovers, even under hostile
>> conditions, and that isn't easy.  If one relies on intermediate,
>> especially third-party, servers to validate, than much of the
>> expected integrity protection is gone... and the number of times
>> such servers have been compromised would make this a
>> non-theoretical problem even without concerns about
>> governmental-type attacks (NSL and otherwise) on those servers.
>> No easy solutions here.
>>
>
> Again, spot on. I've been saying for many years now that the most
> interesting part of DNSSEC is going to be local on the end user side.
> Pushing validation all the way down is critical.


But if you do that you eliminate the wiggle room that your earlier argument
relied on.

You can solve any security problem if you have an intelligent party with
global knowledge making the decisions. But you can only deploy code at the
end point that is Turing complete and works on the information visible to
it there.

If we are proposing to only do verification in a resolver then the NSL etc.
issues are manageable because it is a service in the cloud and can be
reconfigured.

But the WebPKI works end to end and has the entire decision process
embedded in the end point code. If you want to use DNSSEC end to end you
have to meet the same requirement. In that scenario your proposal that we
deal with lock in issues by using common sense is now a deus ex machina
because machines don't have common sense.


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