RE: Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]

Hallam-Baker, Phillip

> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Bernie Volz (volz)

> This technique has been in use for years by implementations
> using TXT records because we've been unable to get the DHCID
> RR approved.

OK so why are you proposing a new protocol rather than writing a
description of the protocols that are already in use?

Correctly prefixed TXT records work just as well as new RRs and are
completely compatible with the deployed infrastructure. If you attempt
to cut new DNS RRs you will hit the problem that your proposal is now
dependent on deployment of a new infrastructure which has no deployment
strategy.

Lets get back to the idea that a standard is a description of running
code. The DNS group has become a bottleneck for deployment of a lot of
technology. This should not be acceptable. There is a fundamental
extensibility flaw in DNS, new RRs must be understood by the sender,
receiver and intermediate infrastructure.

The DNSEXT group appears to believe that their objectives should be to
create as much of an incentive to upgrade to DNSSEC capable
infrastructure as possible and that the way to do this is to gate all
proposed uses of the DNS on cutting a new RR.

This is not a good strategy, DNSSEC is a double ended adoption problem,
the problem is not that the promise of DNSSEC is insufficient incentive
for deployment, the problem is that early adopter deployment of DNSSEC
has negligible incentive.


The Pareto optimal solution here is for the IAB to specify a method of
introducing new features that use the DNS that is entirely compatible
with deployed DNS infrastructure. These in turn create new dependencies
on the DNS that create a near term demand for DNSSEC and an early
adopter incentive. The DNSSEC people get an early adopter market for
their proposal, people looking to extend the DNS can do so without
committing error 33.

For example one of the discussions in DKIM is on what to do with the
ESTG vehicle set up for early development. The idea that most people
seem to think is a good one is to turn it into a branding vehicle
similar to WiFi. So that just as people advertise that their product is
WiFi compatible to mean 'yes it really works' there would be an ESTG
brand that a registrar could use to say 'yes I do provide the services
necessary to support DKIM signed email'. This then leads naturally to
the question of levels of support, a level 1 registrar might do the bare
minimum necessary to support DKIM (allow the relevant records to be
defined), the requirements for level 2 might well include support for
DNSSEC (at least I would argue that they should require DNSSEC support).




_______________________________________________
Ietf mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf
Reply | Threaded
Open this post in threaded view
|

Re: Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]

Mark Andrews

> > This technique has been in use for years by implementations
> > using TXT records because we've been unable to get the DHCID
> > RR approved.
>
> OK so why are you proposing a new protocol rather than writing a
> description of the protocols that are already in use?
>
> Correctly prefixed TXT records work just as well as new RRs and are
> completely compatible with the deployed infrastructure.  If you attempt
> to cut new DNS RRs you will hit the problem that your proposal is now
> dependent on deployment of a new infrastructure which has no deployment
> strategy.

        Not this old chestnut again.

> Lets get back to the idea that a standard is a description of running
> code. The DNS group has become a bottleneck for deployment of a lot of
> technology. This should not be acceptable. There is a fundamental
> extensibility flaw in DNS, new RRs must be understood by the sender,
> receiver and intermediate infrastructure.

        Incorrect.  Only the DHCP elements need to understand this.
        For everything else it should be treated as a opaque blob.

        The intent of RFC 1034/1035 was for new RRs to be treated
        as opaque blobs.  You don't need RDLEN if you don't expect
        to treat unknown as opaque blobs.

        This was clear to me when I first read those RFC's back in
        the early 90's.

        RFC2535 (March 1999) made it absolutely clear that unknown
        RR's were to be treated as opaque blobs.  It is now 6 years
        later and you are saying we should be worrying about
        implementations that were clearly broken on the first day
        they deployed.

> The DNSEXT group appears to believe that their objectives should be to
> create as much of an incentive to upgrade to DNSSEC capable
> infrastructure as possible and that the way to do this is to gate all
> proposed uses of the DNS on cutting a new RR.

        Hogwash.
 
> This is not a good strategy, DNSSEC is a double ended adoption problem,
> the problem is not that the promise of DNSSEC is insufficient incentive
> for deployment, the problem is that early adopter deployment of DNSSEC
> has negligible incentive.

        This has absolutely nothing to do with the deployment of
        DNSSEC.
 
> The Pareto optimal solution here is for the IAB to specify a method of
> introducing new features that use the DNS that is entirely compatible
> with deployed DNS infrastructure. These in turn create new dependencies
> on the DNS that create a near term demand for DNSSEC and an early
> adopter incentive. The DNSSEC people get an early adopter market for
> their proposal, people looking to extend the DNS can do so without
> committing error 33.

 

> For example one of the discussions in DKIM is on what to do with the
> ESTG vehicle set up for early development. The idea that most people
> seem to think is a good one is to turn it into a branding vehicle
> similar to WiFi. So that just as people advertise that their product is
> WiFi compatible to mean 'yes it really works' there would be an ESTG
> brand that a registrar could use to say 'yes I do provide the services
> necessary to support DKIM signed email'. This then leads naturally to
> the question of levels of support, a level 1 registrar might do the bare
> minimum necessary to support DKIM (allow the relevant records to be
> defined), the requirements for level 2 might well include support for
> DNSSEC (at least I would argue that they should require DNSSEC support).
>
>
>
>
> _______________________________________________
> Ietf mailing list
> [hidden email]
> https://www1.ietf.org/mailman/listinfo/ietf
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [hidden email]

_______________________________________________
Ietf mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf
Reply | Threaded
Open this post in threaded view
|

Re: Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]

Ted Lemon-2
In reply to this post by Hallam-Baker, Phillip
On Monday 28 November 2005 20:00, Hallam-Baker, Phillip wrote:
> OK so why are you proposing a new protocol rather than writing a
> description of the protocols that are already in use?

It's inconvenient to use TXT records, because they are not specific to the
purpose.   If the user wants TXT records on the name for some *other* purpose
than marking the name with a DHCID, it doesn't work.

We aren't defining a new protocol - just a new RRtype.   The DNSEXT working
group passed this through last call.   The only reason we're not yet using it
is that, well, it's been very slow getting the entire package through last
call, as witness this current conversation.

I appreciate that you like an opportunity to pontificate about DNSSEC, and am
duly amused that you saw one here and leapt upon it.   However, those of us
who have been working on standardizing a method by which DHCP servers may
interoperate while maintaining DNS records for DHCP clients, for the past
decade, would appreciate it if you would leave off it in this case.   This
protocol has absolutely nothing to do with DNSSEC, other than that, like
DNSSEC, it is related to the DNS.

Thanks.



_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]

Mark Stapp
In reply to this post by Hallam-Baker, Phillip
there is one thing buried in here that's worth answering:

Hallam-Baker, Phillip wrote:

>>From: [hidden email] [mailto:[hidden email]] On
>>Behalf Of Bernie Volz (volz)
>>    
>>
>>This technique has been in use for years by implementations
>>using TXT records because we've been unable to get the DHCID
>>RR approved.
>>    
>>
>
>OK so why are you proposing a new protocol rather than writing a
>description of the protocols that are already in use?
>
>Correctly prefixed TXT records work just as well as new RRs and are
>completely compatible with the deployed infrastructure. If you attempt
>to cut new DNS RRs you will hit the problem that your proposal is now
>dependent on deployment of a new infrastructure which has no deployment
>strategy.
>  
>
what we are trying to do is to produce something that allows
interoperability. that's different from documenting existing
similar-but-not-quite implementations. there is no "compatible" at this
time - but we would like to get there.

-- Mark

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]

Sam Hartman-5
In reply to this post by Ted Lemon-2
>>>>> "Ted" == Ted Lemon <[hidden email]> writes:

    Ted> On Monday 28 November 2005 20:00, Hallam-Baker, Phillip
    Ted> wrote:
    >> OK so why are you proposing a new protocol rather than writing
    >> a description of the protocols that are already in use?

    Ted> It's inconvenient to use TXT records, because they are not
    Ted> specific to the purpose.  If the user wants TXT records on
    Ted> the name for some *other* purpose than marking the name with
    Ted> a DHCID, it doesn't work.

Phil is suggesting something like _dhcid.domain .

--Sam

_______________________________________________
Ietf mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf
Reply | Threaded
Open this post in threaded view
|

Re: Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]

David W. Hankins
On Wed, Nov 30, 2005 at 03:51:13AM -0500, Sam Hartman wrote:
> Phil is suggesting something like _dhcid.domain .

Except the difference between NXDOMAIN and NXRRSET is important for the
DHCID.

--
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]

Ted Lemon-2
In reply to this post by Sam Hartman-5
On Wednesday 30 November 2005 01:51, Sam Hartman wrote:
> Phil is suggesting something like _dhcid.domain .

This is why it's so important to read the drafts carefully, and in detail, to
the point where you understand how the protocol works, and only then consider
proposing changes to it.   Because of the way the protocol uses DNS update
prerequisites, that can't work.   And the way the protocol uses DNS update
prerequisites is required to get the functionality that we want.

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg