Hi Antoin, On 2013-03-04, at 09:44, Antoin Verschuren <[email protected]> wrote:
> Op 04-03-13 14:22, Joe Abley schreef: > > > Contrarily, I don't think the goal should be for registry policy to > > dictate what DS records should be acceptable for a child. I think > > this should be the child's decision. > > That's for local policy to decide. No, I think whether or not local policy should be able to restrict the choices of the child is wider than that. > A domain might want to profile itself as only accepting tested and > secure algorithms so it's users know what to expect in that domain. Exactly, and "tested" and "secure" might well mean different things to the relying parties for the child zone's signatures than to the parent zone operator. > A single child stepping in with it's own unsupported algorithm to try > to break that expectation does not help us to a better place. "unsupported" also means different things to different people. How many TLD registries support the standardised ECC-GOST algorithms, for example? > > If as a child I want to use an experimental or newly-standardised > > algorithm, I should be able to do so. > > I expected that argument. > Experiments should be done in a lab. > On a network that we want to be reliable and secure, experiments from > children should not dictate parent policy. I fully support your right to make decisions about your own production infrastructure (cf "should be done in a lab"). I'm not sure why you would argue that the same courtesy should not be extended to registrants. > > The relying parties for my signatures in my zone might well not > > include the parent zone operator. Why should the choice of > > algorithms for those relying parties be restricted by what the > > parent zone operator thinks is acceptable? > > I want to experiment with MD5. Could the root please supply me with > MD5 signatures, as my relying party does not understand anything else.. I think that's valid, actually. But perhaps re-cast your example with GOST R 34.11-94 and see whether your argument is as persuasive. > If you want to use my domain, you should at least support the > algorithms I use for the hashes in my chain of trust to the root. > Anything else on top of that is fine, but you can't do without mine. I can, actually. I can use whatever algorithms my relying parties find acceptable. My expectation is that the operator of my parent zone is publishing data on my behalf (in return for money) to suit my requirements. I don't understand why the operational requirements of validators also operated by the operator of my parent zone need concern me. > > We're threatening the future development and use of new algorithms > > by institutionalising these restrictions. > > If you want to experiment with algorithms in your own zone, under your > own domain, with your own SEP as trust anchor, be my guest. Do that on > your own level in your own tree. But don't force your parent to > facilitate each and every experiment. Once an algorithm is tested and > considered deployed in the policy area the parent wants to serve, I'm > sure they will use it. Forget experiments; think "algorithms that have been standardised and for which code points have been issued". By encouraging the expectation that the registry gets to decide what is reasonable or not, and providing no reason for those decisions to ever be revisited, we've leaving no room for future algorithms (which might have substantial technical advantages over those commonly used today) to ever see deployment across a zone cut. I think TLD registry operators should remove themselves from the business of providing quality control over DS RRSets, just as (most) do with NS RRSets. Such behaviour unnecessarily constrains technical decisions made by the operators of child zones, acts to suppress the use of new algorithms and provides no tangible benefit to child nor parent. Joe
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
