Re: [DNSOP] NTA... the new NAT?
On 4/17/2012 9:51 AM, Shane Kerr wrote: 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NTA... the new NAT?
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/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NTA... the new NAT?
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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NTA... the new NAT?
On 2012-04-18, at 14:53, Jim Reid j...@rfc1035.com wrote: 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] NTA... the new NAT?
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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
