Subject: [DNSOP] NTA... the new NAT?

From: Shane Kerr <[email-masked]>
Date: Tue, 17 Apr 2012 11:51:25 +0200

All,

Is it just me, or does the NTA discussion remind anyone else of NAT
discussions? And not just because they have the same letters. ;)

Operators say, "wow, here is a useful tool that can solve real-world
problems, maybe it would be helpful to recognize these problems and
perhaps standardize the solution?"

Protocol zealots answer, "but this is bad for this long list of very
valid reasons, so sorry about your problems but really we know better."

If we  insist on DNS Purity, I predict a similar end state with NTA as
with NAT: they will be almost universally deployed, and completely
non-standard, and result in a lot of potential breakage due to
inconsistencies and semi-broken implementations. Yay.

--
Shane

---

From: paul vixie <[email-masked]>
Date: Wed, 18 Apr 2012 18:08:33 +0000

> inconsistencies and semi-broken implementations. Yay.

what potential breakage or semi-broken implementations are you thinking
of? in NAT, it's all rather broken. the fix for NAT, had the IETF been
willing to recognize this technology in spite NAT's non-purity, would
have been in the form of what we now call firewall traversal or perhaps
PnP. neither of which the world was ready for at the time, and neither
of which was something that could have been standardized soon enough to
stop "bad NAT" from getting out, nor standardized at a high enough
quality and relevance level at that time since in the early days noone
knew yet how many things NAT would break.

but let's continue the analogy anyway. what would have saved the world
from "bad NAT" was a change to the underlying connection model of the
internet -- not just an RFC that says "here's how you can use 192.168"
but rather one that said "here's how you can preserve some aspects of
end-to-end, not break FTP, not have to reframe your TCP sessions at the
gateway layer if they might contain embedded IP addresses." in that
sense, i agree with your comparison: a fundamental change to the nature
of DNSSEC to allow for secure signalling of errors and secure signalling
of middle-man policy would definitely help us head off a generation of
"bad NTA". but that's not what's on offer here.

DNSSEC currently presumes reliable end-to-end failure, and offers no way
to signal other conditions. so if somebody breaks into your primary name
server and alters your zone and either doesn't sign their changes or
signs the whole zone with some key that's not matched by your delegating
DS RRset, right now it will cause the modified content to be marked as
bad and ignored or dropped by any validating server. NTA will change
that, by adding middlemen who can decide as a matter of their own policy
to just ignore these bad or missing signatures and pass your data to
their stub clients as though DNSSEC had not been in use. that's
horrible. that's worse for deployment confidence in DNSSEC than anything
the social security administration or NASA could otherwise do by failing
to re-sign or using the wrong keys.

so i'm all for changing DNSSEC itself to accomodate these other use
cases. but i'm not on-board at all for a standardized way for middlemen
to block unwanted (by them) DNSSEC signalling. this means i'm in favour
of the thing you're suggesting ("do better with DNSSEC than we did with
NAT") but i'm also opposed to the thing you're supporting ("make
end-to-end DNSSEC failures less reliable"). i think this means you're
offering me a false dichotomy above. let me know if i'm misreading you.

paul

---

From: David Conrad <[email-masked]>
Date: Wed, 18 Apr 2012 11:28:36 -0700

Paul,

On Apr 18, 2012, at 11:08 AM, paul vixie wrote:
> to signal other conditions.

True, in the sense that either a name (and the entire chain leading to that name) validates or it doesn't.

> NTA will change
> their stub clients as though DNSSEC had not been in use.

No. NTA is not adding middlemen. The way the vast majority of the DNS is implemented, namely stub communicating with a remote validator, there already exists middlemen. They're called the validator operators. NTA is allowing those middlemen to implement policies that meet their business requirements. Their validator, their rules.

If you don't like the policy of your validator operator, change to a validator operator whose policy you agree with (or, better yet, run your own validator -- it is the only way to be sure).  If you are not permitted to do this, you have other issues.

Regards,
-drc

---

From: paul vixie <[email-masked]>
Date: Wed, 18 Apr 2012 18:52:06 +0000

On 4/18/2012 6:28 PM, David Conrad wrote:
> ... Their validator, their rules. ...

that would be a fundamental change to the architecture of dnssec.

see again:
<http://www.circleid.com/posts/20121012_dns_policy_is_hop_by_hop_dns_security_is_end_to_end/>

---

From: Jim Reid <[email-masked]>
Date: Wed, 18 Apr 2012 19:52:14 +0100

On 18 Apr 2012, at 19:28, David Conrad wrote:

> If you don't like the policy of your validator operator, change to a  
> validator operator whose policy you agree with (or, better yet, run  
> your own validator -- it is the only way to be sure).  If you are  
> not permitted to do this, you have other issues.

+1

Though you've not explained how someone would be able to find out what  
was the flavour-of-the-month policy of the validator operator they  
were using that day. Assuming the current network's validation policy  
was broken (for some definition of broken) would of course be a wise  
approach. That probably means everyone runs their own validator to  
avoid sucky hotel nets and the like. Which just moves where NTAs get  
(mis)configured.

---

From: Joe Abley <[email-masked]>
Date: Wed, 18 Apr 2012 12:32:09 -0700

On 2012-04-18, at 14:53, "Jim Reid" <[email-masked]> wrote:

> were using that day.

In a cryptographic sense, if you outsource your validation to a third party you can never be sure of the integrity of the answers you receive. If you want certainty, validate in the client. (I continue to think this is the advice the IETF should be giving. Certainty is required in some applications. I think it should be the default expectation of other protocols and applications.)

In a more practical sense, if you're making use of a third-party supplier for something, presumably you have a way to find out details of the service they're providing. In principle, wanting a validation supplier who is sane is no different to wanting a bank who doesn't store or process your personal data in a jurisdiction with over-reaching data mining by government. If you care, chances are you can find something that meets your needs.

Joe