RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
On Thursday, December 01, 2005 08:48:10 AM -0500 Bernie Volz (volz) [EMAIL PROTECTED] wrote: How about we address issue 1 by expanding the DHCID RR type code. We have 16-bits and we're just using 4 values presently. There's plenty of room for future expansion *SHOULD* someone come along and demand a new algorithm in the future. I can't see why this would EVER occur since this really isn't about strong cryptographic protection (we're just trying to make it non-trivial to find a client's identity by not storing it in clear text). I think that's a good start; in fact, I was going to propose something very similar. This solves half the problem; particularly, it makes it possible to indicate that some other hash is in use. It does bind the hash to the type, rather than allowing them to be specified orthogonally, but I don't think that's a major problem. If it ever becomes an issue, there should be no problem defining a type where the next 16 bits indicate a subtype and the 16 bits after that indicate a hash. However, it doesn't solve the other half of the problem, which is present even without considering changing hash algorithms. The problem is that for any given fqdn and DHCP client, there are multiple possible DHCID RR's; in particular, one for each type. In order the update mechanism to work without requiring either an advance query or multiple update attempts, all possible updaters must agree in advance on the type in use. This lack of negotiation seems problematic to me, even in the absence of multiple hash algorithms. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
On Sunday, December 04, 2005 11:58:25 PM -0500 Bernie Volz (volz) [EMAIL PROTECTED] wrote: If you're going to have multiple DHCP servers, such as failover pairs, doing the DNS updates, you need to have those servers agree on how they will identify the clients. This is not JUST for DNS updates. Failover partners need to use the same identifiers for clients. The document I read identifies several possible situations in which DHCID records are used to coordinate between updaters which are not DHCP failover partners. It discusses a scenario in which multiple clients may attempt to issue updates for the same name (and, presumably, in which more than one client is authorized to issue such an update; otherwise, there would be no problem), and one in which a client moves between subnets served by different DHCP servers, both of which are authorized issue updates for the client's FQDN. You can plausibly argue that the two DHCP servers in the second scenario, while not failover partners, are nonetheless part of the same administrative domain and require coordination. Such an argument seems a little weak to me, but if that were the only issue, I could live with it. I suppose you can also argue that two clients configured to use the same name will (by design) not produce the same DHCID RR's even if they use the same type, and therefore there's not a problem if they use different types. That I'll definitely buy. However, what about a scenario where both a client and the DHCP server on its home network are authorized to do the updates. When the client is at home, it lets the server do the update. When it is off-site at an IETF meeting, the IETF DHCP server has no authorization to update the client's fqdn, so the client must do so itself. Now, if the client and its home DHCP server disagree on which type to use, then the update may fail. The rules are pretty clearly described in the RFC: For DHCPv4: 1. Use the DUID if the client identifier option is provided by the client and it is a DUID and the server supports it. This is a new RFC that is in the RFC-editor queue so no clients and servers yet support this. 2. Otherwise, use the client identifier option if provided by the client, 3. Otherwise, use htype and chaddr. The rules are clear, but require that all possible updaters have the same view of the world. Consider the client I described above, which identifies itself with a DUID. So, as far as the client knows, it should follow rule 1 and use the DUID to form a DHCID record. Unfortunately, the client's home DHCP server doesn't support DUID's, so it skips rule 1 and follows rule 2, using the client identifier. It gets worse when you start adding new types after DHCID support is widely deployed. In fact, you arguably have that problem already, since a client supporting this option doesn't know whether its home server even supports the DHCID RR, as opposed to using the TXT record method. If you think my example involving both a client and a server is contrived, consider a client which always does its own updates. When such a client is updated, it may begin supporting new DHCID record types. It may begin supporting DUID's, or even be required to switch from non-DUID client identifiers to DUID's because it now supports IPv6. In each of these cases, the client will fail to perform an update because its new DHCID value is different from the old one. You can require the client to give up its lease and remove the record prior to shutting down, but such a requirement is fragile because a client may shut down unexpectedly, with no chance to send a DDNS update first. In short, as long as the only authorized updaters are a set of carefully coordinated DHCP servers which never receive configuration changes or software upgrades, everything works. Once you introduce clients (which by their nature are unpredictable) or support for new DHCID types, the negotiation problem becomes an issue. It's possible to work around by performing an extra query to determine what DHCID type is in use, but you seem to want to avoid that. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
If you're going to have multiple DHCP servers, such as failover pairs, doing the DNS updates, you need to have those servers agree on how they will identify the clients. This is not JUST for DNS updates. Failover partners need to use the same identifiers for clients. So, this is really not an issue. The rules are pretty clearly described in the RFC: For DHCPv4: 1. Use the DUID if the client identifier option is provided by the client and it is a DUID and the server supports it. This is a new RFC that is in the RFC-editor queue so no clients and servers yet support this. 2. Otherwise, use the client identifier option if provided by the client, 3. Otherwise, use htype and chaddr. For DHCPv6: 1. Use the DUID of the client. There really is no mystery here. - Bernie -Original Message- From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED] Sent: Sunday, December 04, 2005 11:43 PM To: Bernie Volz (volz); Sam Hartman; Mark Stapp (mjs) Cc: namedroppers@ops.ietf.org; ietf@ietf.org; Pekka Savola; Ted Lemon; iesg@ietf.org; dhcwg@ietf.org; Steven M. Bellovin; Jeffrey Hutzelman Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] On Thursday, December 01, 2005 08:48:10 AM -0500 Bernie Volz (volz) [EMAIL PROTECTED] wrote: How about we address issue 1 by expanding the DHCID RR type code. We have 16-bits and we're just using 4 values presently. There's plenty of room for future expansion *SHOULD* someone come along and demand a new algorithm in the future. I can't see why this would EVER occur since this really isn't about strong cryptographic protection (we're just trying to make it non-trivial to find a client's identity by not storing it in clear text). I think that's a good start; in fact, I was going to propose something very similar. This solves half the problem; particularly, it makes it possible to indicate that some other hash is in use. It does bind the hash to the type, rather than allowing them to be specified orthogonally, but I don't think that's a major problem. If it ever becomes an issue, there should be no problem defining a type where the next 16 bits indicate a subtype and the 16 bits after that indicate a hash. However, it doesn't solve the other half of the problem, which is present even without considering changing hash algorithms. The problem is that for any given fqdn and DHCP client, there are multiple possible DHCID RR's; in particular, one for each type. In order the update mechanism to work without requiring either an advance query or multiple update attempts, all possible updaters must agree in advance on the type in use. This lack of negotiation seems problematic to me, even in the absence of multiple hash algorithms. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
-Original Message- From: Ted Lemon [mailto:[EMAIL PROTECTED] Sent: Thursday, December 01, 2005 3:58 PM To: Hallam-Baker, Phillip Cc: Sam Hartman; namedroppers@ops.ietf.org; Bernie Volz (volz); ietf@ietf.org; iesg@ietf.org; dhcwg@ietf.org; Steven M. Bellovin; Pekka Savola Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard] On Thursday 01 December 2005 12:31, Hallam-Baker, Phillip wrote: My criteria here are that the DNS should support an extension mechanism that allows the definition of new records at will without the need to deploy ANY new code at either the client or the server. Right, we have that. It's called the RRtype. Many, many type codes are NO YOU DO NOT The majority of the deployed DNS infrastructure does not have the ability to service new RRs. Actually the majority of DNS servers are capable of handling unknown RRs as are the majority of client resolver libraries. If you ignore Windows this is almost 100% of client resolver libraries are capable of handling unkown RRs. The applications generally decode them. The opposite claim has been advanced on several occasions but it is untrue. There is NO version of the Windows DNS server capable of PRODUCTION publication of new DNS RRs. A registry hack that does not survive a reboot does not count. Microsoft has shown the actual DNS code for saving a zone file, new RRs are simply not handled. The world is not Windows. Not deploying a new RR type because Windows patentently got it wrong is STUPID. Its not just the dns servers, it's the firewalls and a whole intermediate layer of RPC services that are used to implement DNS calls in a large number of real environments. Firewalls that block unknown RRs are broken by design. If you choose to deploy such a broken firewall you get what you deserve. As for client libraries that don't support unknown types. They to are broken by design. Anyone who has dealt with the DNS should be aware that new RRs are being deployed pretty regularly. Failure to allow retrieval of the raw records was stupid. available. Requiring the use of additional labels and not taking advantage of the very nice DNS update prerequisite support because someone doesn't want to support transparent addition of RRtypes is pathetic. The DNSEXT group has yet to explain how a production quality DNS server can add support for a new RR without the need for new code. The ability to add in blobs of raw hex data does not cut it. Well for this particular application I don't expect humans to ever enter the RR's by hand. All additions and removals are expected to be done via UPDATE. If it wasn't that it is prettier to display the records in master file format there really is no need to add any code to nameservers for this record. As for the general case. The hex encoding is a stopgap measure until you can upgrade / teach the nameserver to know about the type. You complaint also makes a assumption that the IETF should be involed in defining how implemtations add support for new RRs. In my opinion this should be left to the implementation. BIND 9 is designed to make adding a new RR easy. There have been plenty of examples where this has been done to test out new RRs. We've had the capacity to extend option codes in every DHCP server (as well as most clients) in existence practically since day one, and that's a much more complicated problem than handling new RRtypes. DHCP should stick to reporting the IP address. The idea that configuration services should be configured at the network connection level is ridiculous. The fact I am on an ethernet segment does not mean that I trust it or want anything to do with it. If I am on public WiFi the idea is nonsense on stilts. This is all horses for courses. I would like to discontinue the practice of assigning the domain name prefix and the DNS servers from DHCP by default. The domain name prefix should be defined during the MACHINE network configuration alone. The use of DHCP discovered DNS servers is a major security hazzard. All DNS transactions should be TSIG signed. I will accept the use of DHCP to assist initial machine configuration and local network configuration. Use of an unauthenticated broadcast protocol for application configuration is nonsense. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
On Thursday 01 December 2005 12:31, Hallam-Baker, Phillip wrote: My criteria here are that the DNS should support an extension mechanism that allows the definition of new records at will without the need to deploy ANY new code at either the client or the server. Right, we have that. It's called the RRtype. Many, many type codes are available. Requiring the use of additional labels and not taking advantage of the very nice DNS update prerequisite support because someone doesn't want to support transparent addition of RRtypes is pathetic. We've had the capacity to extend option codes in every DHCP server (as well as most clients) in existence practically since day one, and that's a much more complicated problem than handling new RRtypes. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
How about we address issue 1 by expanding the DHCID RR type code. We have 16-bits and we're just using 4 values presently. There's plenty of room for future expansion *SHOULD* someone come along and demand a new algorithm in the future. I can't see why this would EVER occur since this really isn't about strong cryptographic protection (we're just trying to make it non-trivial to find a client's identity by not storing it in clear text). In the -10 draft, Section 3.3 is: 3.3. The DHCID RR Type Codes The DHCID RR Type Code specifies what data from the DHCP client's request was used as input into the hash function. The type codes are defined in a registry maintained by IANA, as specified in Section 7. The initial list of assigned values for the type code is: 0x = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7]. 0x0001 = The data portion from a DHCPv4 client's Client Identifier option [9]. 0x0002 = The client's DUID (i.e., the data portion of a DHCPv6 client's Client Identifier option [10] or the DUID field from a DHCPv4 client's Client Identifier option [12]). 0x0003 - 0xfffe = Available to be assigned by IANA. 0x = RESERVED --- Replace with: 3.3. The DHCID RR Type Codes The DHCID RR Type Code specifies what data from the DHCP client's request was used as input into the hash function and the hash function used. The type codes are defined in a registry maintained by IANA, as specified in Section 7. The initial list of assigned values for the type code is: 0x = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7] and MD5 hash. 0x0001 = The data portion from a DHCPv4 client's Client Identifier option [9] and MD5 hash. 0x0002 = The client's DUID (i.e., the data portion of a DHCPv6 client's Client Identifier option [10] or the DUID field from a DHCPv4 client's Client Identifier option [12]) and MD5 hash. 0x0003 - 0xfffe = Available to be assigned by IANA. 0x = RESERVED --- Note: I used MD5 since that is what the drafts presently specify. This does mean that using the existing update mechanisms as described in the conflict resolution draft will only work if all servers (and clients doing updates) use the same hash algorithm as specified today. But I don't see that being an issue as again, I suspect we'll never change the algorithm. And, if we do, we can revise the update procedure when the draft specifying the new DHCID RR types / algorithm is written. I think this provide Sam his desired ability to rev the algorithm without having to use a new DHCID RR type. And, it avoids complicating the current update producure unnecessarily. - Bernie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Hartman Sent: Tuesday, November 29, 2005 2:48 PM To: Mark Stapp (mjs) Cc: namedroppers@ops.ietf.org; ietf@ietf.org; iesg@ietf.org; Steven M. Bellovin; dhcwg@ietf.org; Pekka Savola; Ted Lemon Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] Mark == Mark Stapp [EMAIL PROTECTED] writes: Mark would such a clarification be enough to resolve your Mark DISCUSS, Sam Hartman? that is, if it were clearer that we're Mark only aiming for more difficult than not difficult at all - Mark would that be sufficiently clear guidance to admins about Mark what they should expect from this mechanism? So, as I described in my response to Russ, I'm asking for three things: 1) algorithm agility 2) Remove the paragraph explaining why md5 is OK or provide a theoretical model under which we can reason about how good a hash is at keeping stuff private. 3) Use sha-1 or sha-256 instead of md5. I feel very strongly about point 1. Unfortunately I think this is the point the working group most objects to. I understand the concerns about the complexity of the update process. However I also know that security primitives are things that you need to replace from time to time. If you were using md5 because it had a relatively even distribution of outputs you could probably convince me that you don't need a way to update it. However even if weakly you're using md5 for its cryptographic properties. Those can change over time so you need a mechanism to react to those changes. I suspect we can all agree that we need to either reword claims about security of cryptographic primitives so they are clearly true or remove those claims. So I don't think that we're going to have much of an issue with point 2. I think there is room for discussion on point 3. I think sha-1 or sha-256 would be a better choice. I think that there is an argument that md5 is not so bad that it cannot be used. If the working group ends up responding that it would really like to use md5, I can go to the security community
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
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. HankinsIf 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
From: Sam Hartman [mailto:[EMAIL PROTECTED]
Ted == Ted Lemon [EMAIL PROTECTED] 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 .
My criteria here are that the DNS should support an extension mechanism
that allows the definition of new records at will without the need to
deploy ANY new code at either the client or the server.
Unless wildcards are required the prefix mechanism described in the SRV
rfc allows the existing deployed DNS to be extended without the need for
new code deployment.
In the cases where wildcards are required for administrative convenience
the semantics of the DNS wildcard mechanism do not meet the use cases
that were described in MARID in any case.
What I suggest is a scheme where we regard the RR type as a means of
defining the syntax of a DNS record and apply a prefix to define the
precise semantics.
Wildcards are a problem whether or not you cut a new RR. In MARID people
wanted to define an email policy record for *.example.com where *
has the semantics 'all the nodes in the domain'. The semantics of DNS
wildcards are 'all the undefined nodes in the domain'.
Despite this flaw a DNS admin running a legacy DNS server can if
necessary enter the 'missing' node records by hand. Alternatively the
records could be generated using a perl script that expands an
expression such as #.example.com to indicate 'wildcards that behave
the way that you would expect them to'.
There is one problem with this approach, it does not work on prefixed
records. DNS does not support a wildcard of the form
_prefix.*.example.com. This is why specs like DKIM and so on describe
stack walking techniques so that a client can find a record with the
desired scope.
A much better way to solve this problem is to introduce a pointer RR
that obeys the semantics of *.example.com or #.example.com the same as
any other non-prefixed pointer. The resolution process for a prefixed
record then becomes :
1) record = resolve (_prefix.example.com, {TXT, SRV, ...})
if record != null return 'found'
2) pointer = resolve (example.com, PTR)
if record == null return 'not found'
3) record = resolve (_prefix. + pointer, {TXT, SRV, ...})
if record != null return 'found' else return 'not found'
This scheme also provides an additional management advantage, instead of
configuring policy for each machine individually I can define different
policy classes as needed and assign that policy to a particular machine
by specifying the corresponding pointer, eg:
_dkim.servers.example.com TXT DKIM policy for servers
_yaddis.servers.example.com TXT Policy for YADDIS
_dkim.desktop.example.com TXT DKIM policy for desktops
The open question in this scheme is what record to use for the pointer
record. I will accept a situation where we have to do ONE new code
deployment to get the DNS into a state where it can be extended at will
without further code deployments if that is absolutely necessary.
My much prefered solution would be to re-use an existing record. Either
a record that is widely implemented but whose original use has been
deprecated or a record that can be reused without conflict.
A _possible_ candidate for the latter that I have yet to hear a
reasonabe argument against is the PTR record where the use is currently
defined for reverse DNS domains only.
By 'reasoned argument against' I mean 'this will break this existing
deployed code' or 'the XYZ dns server is widely used (5%) and only
allows PTR records to be defined in the reverse DNS'. I do not accept
'that is not the way we do it' as a reasoned argument.
People are already using prefix records, there is even an unofficial
registry of prefixes. There are also people who spend a lot of time and
effort re-inventing the DNS in order to graft on a very small amount of
policy distribution functionality.
Today people are told to get in line and grovel for an RR assignment.
You then have to grovel to the maintainers of the four or five major DNS
server distributions to implement your record and then wait a few years
for them to take their own sweet time to get around to it. And after all
that is done you have to persuade registrars to provide support.
The minimum time in which that type of change can be achieved in the
Internet as it exists today is a decade. Three years to get your spec to
the point where IANA deigns to give you a RR assignment, another three
years while the DNS implementations get round to adding it onto their
roadmaps, another four or five years for a
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
-Original Message- From: Ted Lemon [mailto:[EMAIL PROTECTED] Sent: Thursday, December 01, 2005 3:58 PM To: Hallam-Baker, Phillip Cc: Sam Hartman; namedroppers@ops.ietf.org; Bernie Volz (volz); ietf@ietf.org; iesg@ietf.org; dhcwg@ietf.org; Steven M. Bellovin; Pekka Savola Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard] On Thursday 01 December 2005 12:31, Hallam-Baker, Phillip wrote: My criteria here are that the DNS should support an extension mechanism that allows the definition of new records at will without the need to deploy ANY new code at either the client or the server. Right, we have that. It's called the RRtype. Many, many type codes are NO YOU DO NOT The majority of the deployed DNS infrastructure does not have the ability to service new RRs. The opposite claim has been advanced on several occasions but it is untrue. There is NO version of the Windows DNS server capable of PRODUCTION publication of new DNS RRs. A registry hack that does not survive a reboot does not count. Microsoft has shown the actual DNS code for saving a zone file, new RRs are simply not handled. Its not just the dns servers, it's the firewalls and a whole intermediate layer of RPC services that are used to implement DNS calls in a large number of real environments. available. Requiring the use of additional labels and not taking advantage of the very nice DNS update prerequisite support because someone doesn't want to support transparent addition of RRtypes is pathetic. The DNSEXT group has yet to explain how a production quality DNS server can add support for a new RR without the need for new code. The ability to add in blobs of raw hex data does not cut it. We've had the capacity to extend option codes in every DHCP server (as well as most clients) in existence practically since day one, and that's a much more complicated problem than handling new RRtypes. DHCP should stick to reporting the IP address. The idea that configuration services should be configured at the network connection level is ridiculous. The fact I am on an ethernet segment does not mean that I trust it or want anything to do with it. If I am on public WiFi the idea is nonsense on stilts. I would like to discontinue the practice of assigning the domain name prefix and the DNS servers from DHCP by default. The domain name prefix should be defined during the MACHINE network configuration alone. The use of DHCP discovered DNS servers is a major security hazzard. All DNS transactions should be TSIG signed. I will accept the use of DHCP to assist initial machine configuration and local network configuration. Use of an unauthenticated broadcast protocol for application configuration is nonsense. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
On Dec 1, 2005, at 11:31 AM, Hallam-Baker, Phillip wrote:
A much better way to solve this problem is to introduce a pointer RR
that obeys the semantics of *.example.com or #.example.com the same as
any other non-prefixed pointer. The resolution process for a prefixed
record then becomes :
1) record = resolve (_prefix.example.com, {TXT, SRV, ...})
if record != null return 'found'
2) pointer = resolve (example.com, PTR)
if record == null return 'not found'
3) record = resolve (_prefix. + pointer, {TXT, SRV, ...})
if record != null return 'found' else return 'not found'
This scheme also provides an additional management advantage,
instead of
configuring policy for each machine individually I can define
different
policy classes as needed and assign that policy to a particular
machine
by specifying the corresponding pointer, eg:
_dkim.servers.example.com TXT DKIM policy for servers
_yaddis.servers.example.com TXT Policy for YADDIS
_dkim.desktop.example.com TXT DKIM policy for desktops
This approach would create several challenges. With respect to
DNSsec, additional lookups will be required to investigate above the
set of PTR RRs, in addition to obtaining the PTR RRs. Even with
normal DNS, extra sequential DNS lookups amplify the effects of an
embedded reference. When a domain is publishing a large DNS wildcard
record, even when not directly involved in a DDoS, the impact may
still result in filtering by name at the referencing protocol. This
method would be difficult to defend from being abused.
-Doug
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
On Mon, Nov 28, 2005 at 05:20:09PM -0500, Bernie Volz (volz) wrote: Yes, I can. The ISC's DHCP server (www.isc.org) does this (I'm not sure whether it uses MD5 to encode the client identity or not). Ted might know for sure. It does, though it only encodes the client identity (client identifier option or chaddr), it does not include the FQDN like the current DHCID draft does. There are a few niggling bits that are different, and obviously incompatible (not just because it's encoded as hexadecimal in a TXT record), but on all points that are topical to this discussion it's the same. -- David W. HankinsIf 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
On Monday 28 November 2005 10:49, Steven M. Bellovin wrote: I confess that I don't see the problem. The problem is that in order to do what Pekka is proposing, we have to make a substantial change to the protocol. This creates two problems: first, it means that this protocol, which is in wide use, has been in wide use for more than five years, the standard for which has been under development for ten years, will probably take another year to make standard, for this change alone. As it has many times before. This is a major language tweak, and will require substantial review. Second, it renders implementations substantially more complicated, and creates a knob that administrators need to understand whether and how to turn, where no knob is needed. Additional knobs that aren't needed have a net negative impact on overall system security - the overall impact of the proposed change will be to reduce, not enhance security. I support the changes suggested by Havard that simply reduce the security claims being made here. I do not support making any substantive changes to the protocol at this point - to do so will simply delay it longer, and will not add any value. The only reason I can think of for not using MD5 is that at some point people might want to be able to avoid having an MD5 implementation on their device because MD5 is generally deprecated. I don't think this is a practical concern - MD5 implementations are with us for the long haul, deprecated or not. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
On Monday 28 November 2005 23:40, Harald Tveit Alvestrand wrote: This means that we will not have a backwards compatibility issue with the installed base if we change the format of the record, but *will* have a procedural compatibility issue if we don't keep the property of you can know the expected content of the record without fetching it. Yup. My only objection to changing the hash algorithm is that it means a rev of the document that could cause us to go through another wglc or ietf last call (as opposed to editorial changes, which presumably would not). Otherwise, while I don't think it makes any difference, it's otherwise fine to use SHA-256 instead of MD5. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
On Sunday 27 November 2005 15:21, Sam Hartman wrote: Actually, no, it's worse than that. A preimage attack is sufficient to break this. However you cannot reduce a break of this system to a preimage attack. It's always inspiring to meet someone who knows a lot about a complex topic like hash algorithms. I am not happy with a protocol whose security depends on treating md5 as a random oracle. Again, very inspiring to meet someone who knows about md5, random oracles, et cetera. However, this protocol's security does not rely in any way on md5 or any other hash. The hash is present as a privacy mask. It has limited value since the thing being protected is broadcast over the wire on a regular basis, but we put it in because we were asked to. The security of the protocol rests on the security of the DNS update mechanism; if you are concerned about DNS update security with your DHCP server, I suggest using some kind of cryptographic authentication. I use TSIG, and am reasonably happy with it. In order for the DHCID hash to be a security issue, it has to be the case that you have more than one DHCP server that is permitted to update the same zone in the DNS, and yet have no trust relationship between these DHCP servers. This is a contradiction in terms - if you don't have a trust relationship between two updaters of the same zone, you don't have any update security at all for that zone. I would really encourage people who are commenting on this to please, please read the drafts for detailed comprehension, not just for keywords. I get the impression that a lot of keyword triggering is going off here, and it's really not constructive. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
The Nominum DHCP server (DCS) supports the exact mechanism described in the collection of documents, except that the data is stored in a TXT record rather than a DHCID record, because we are waiting on the DHCID record. We also implement the older version of the protocol that the ISC server supports, which as David says is only slightly different than the current spec. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
On Saturday 26 November 2005 09:56, Steven M. Bellovin wrote: In fact, the Security Considerations section should analyze the (non-trivial) probability of a brute-force attack. It doesn't matter. The point of the DHCID is to allow two servers to avoid accidentally stepping on each other. If you break the DHCID, what you get is the ability to pretend that you are another DHCP client. If you succeed in doing this, you can take over that DHCP client's name, but you don't get to keep it, because you are using the same identification as the other client, and so it's going to take it back. The information that you would use to pretend to be the other client is routinely being sent over the network in the clear, so you don't need to break the DHCID to get it - you just need to listen on the wire for a packet from that client. You can't do the attack I've described unless you are on a network managed by a DHCP server that manages the same namespace as the server that put in the legitimate DHCID. It's true that we could exhaustively go over all possible exploits, no matter how trivial, no matter how useless, in the security considerations section. Do you honestly believe that this is necessary? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCID and the use of MD5
Sam: I have been hoping to stay out of this discussion. I was hoping that it would naturally come to closure, but I do not see it doing so. As you know, I am really pushing for algorithm agility, and I fully support your efforts to get it in this case. Here is my understanding of the Random Oracle Model formulated by Bellare and Rogaway. First, one designs an ideal system in which all parties have oracle access to a truly random function, and then one proves the security of this ideal system. Next, one replaces the random oracle by a the hash function that is being studied (MD5 in this case), and all parties know the hash function that is being used. Then one sees the impact (if any) of replacing the random function with the hash function. Why is this theoretical stuff important in this context? The hash function security requirements in this application appear pretty weak to me. It is certainly no where near the requirements imposed in the digital signature context, which is where I am really worried about a transition away from MD5 and SHA-1. I am unclear what else you want the authors to do. Can you help me understand you objective? Russ At 12:00 AM 11/29/2005, Ted Lemon wrote: I am not happy with a protocol whose security depends on treating md5 as a random oracle. Again, very inspiring to meet someone who knows about md5, random oracles, et cetera. However, this protocol's security does not rely in any way on md5 or any other hash. The hash is present as a privacy mask. It has limited value since the thing being protected is broadcast over the wire on a regular basis, but we put it in because we were asked to. The security of the protocol rests on the security of the DNS update mechanism; if you are concerned about DNS update security with your DHCP server, I suggest using some kind of cryptographic authentication. I use TSIG, and am reasonably happy with it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCID and the use of MD5
Sam: Maybe I should have stayed quiet a bit longer. I fully support Steve's approach, and maybe that is what you wanted too. Steve asked the authors to describe 1. which attacks are out of scope (and why!) 2. which attacks are in-scope 2.1 and the protocol is susceptible to 2.2 and the protocol protects against This is better than us each making our own assessment of the hash function security requirements. Russ Date: Tue, 29 Nov 2005 10:26:27 -0500 To: Sam Hartman [EMAIL PROTECTED] From: Russ Housley [EMAIL PROTECTED] Subject: Re: DHCID and the use of MD5 Cc: [EMAIL PROTECTED], ietf@ietf.org Sam: I have been hoping to stay out of this discussion. I was hoping that it would naturally come to closure, but I do not see it doing so. As you know, I am really pushing for algorithm agility, and I fully support your efforts to get it in this case. Here is my understanding of the Random Oracle Model formulated by Bellare and Rogaway. First, one designs an ideal system in which all parties have oracle access to a truly random function, and then one proves the security of this ideal system. Next, one replaces the random oracle by a the hash function that is being studied (MD5 in this case), and all parties know the hash function that is being used. Then one sees the impact (if any) of replacing the random function with the hash function. Why is this theoretical stuff important in this context? The hash function security requirements in this application appear pretty weak to me. It is certainly no where near the requirements imposed in the digital signature context, which is where I am really worried about a transition away from MD5 and SHA-1. I am unclear what else you want the authors to do. Can you help me understand you objective? Russ At 12:00 AM 11/29/2005, Ted Lemon wrote: I am not happy with a protocol whose security depends on treating md5 as a random oracle. Again, very inspiring to meet someone who knows about md5, random oracles, et cetera. However, this protocol's security does not rely in any way on md5 or any other hash. The hash is present as a privacy mask. It has limited value since the thing being protected is broadcast over the wire on a regular basis, but we put it in because we were asked to. The security of the protocol rests on the security of the DNS update mechanism; if you are concerned about DNS update security with your DHCP server, I suggest using some kind of cryptographic authentication. I use TSIG, and am reasonably happy with it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCID and the use of MD5
Russ == Russ Housley [EMAIL PROTECTED] writes: - Russ Why is this theoretical stuff important in this context? Russ The hash function security requirements in this application Russ appear pretty weak to me. It is certainly no where near the Russ requirements imposed in the digital signature context, which Russ is where I am really worried about a transition away from Russ MD5 and SHA-1. First, I brought up random oracle in an aside to Steve Bellovin. I'm not sure it particularly matters to this case. Actually, their use of a hash appears to require a lot more out of the hash than a digital signature. A digital signature only requires that there be no collisions. It would be OK for example in most digital signature models if you leaked all the information about the signed document in the hash. The attack against digital signatures is that we could produce some other document that has the same hash as the signed document. Here, though, we're trying to use a hash to hide information. The first preimage assumption says something close to if the hash is good we won't be able to find all the information in the input to the hash function. There's a big difference between all the input, and some of the input or some function of the input. Knowing the hash is one-way sets an upper bound on how much information it can leak. So, I know of nothing that asks little of a hash and can be used for privacy. The only model I know that can be used for privacy is random oracle and that asks a lot of a hash. There may be some other theoretical model weaker than random oracle that describes how a hash can be used to hide data. If so, I don't know it. Absent such a model, the claim that they aren't asking much from md5 in the document is incorrect. Russ I am unclear what else you want the authors to do. Can you 1) algorithm agility. 2) Remove paragraph about existing md5 attacks not being an issue or come up with theoretical justification for that paragraph. 3) Use sha-1 or sha-256 instead of md5. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCID and the use of MD5
Sam: I am happy with the three things that you want. I am not sure we got to them in the same way. I think we disagree about the requirements on the hash, mostly because the consequences of a collision are very different. However, I think that the paragraphs that Steve has requested will make that clear for everyone. Thanks for the timely response. Russ At 11:15 AM 11/29/2005, Sam Hartman wrote: Russ == Russ Housley [EMAIL PROTECTED] writes: - Russ Why is this theoretical stuff important in this context? Russ The hash function security requirements in this application Russ appear pretty weak to me. It is certainly no where near the Russ requirements imposed in the digital signature context, which Russ is where I am really worried about a transition away from Russ MD5 and SHA-1. First, I brought up random oracle in an aside to Steve Bellovin. I'm not sure it particularly matters to this case. Actually, their use of a hash appears to require a lot more out of the hash than a digital signature. A digital signature only requires that there be no collisions. It would be OK for example in most digital signature models if you leaked all the information about the signed document in the hash. The attack against digital signatures is that we could produce some other document that has the same hash as the signed document. Here, though, we're trying to use a hash to hide information. The first preimage assumption says something close to if the hash is good we won't be able to find all the information in the input to the hash function. There's a big difference between all the input, and some of the input or some function of the input. Knowing the hash is one-way sets an upper bound on how much information it can leak. So, I know of nothing that asks little of a hash and can be used for privacy. The only model I know that can be used for privacy is random oracle and that asks a lot of a hash. There may be some other theoretical model weaker than random oracle that describes how a hash can be used to hide data. If so, I don't know it. Absent such a model, the claim that they aren't asking much from md5 in the document is incorrect. Russ I am unclear what else you want the authors to do. Can you 1) algorithm agility. 2) Remove paragraph about existing md5 attacks not being an issue or come up with theoretical justification for that paragraph. 3) Use sha-1 or sha-256 instead of md5. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCID and the use of MD5
Russ == Russ Housley [EMAIL PROTECTED] writes: Russ Sam: Maybe I should have stayed quiet a bit longer. I fully Russ support Steve's approach, and maybe that is what you wanted Russ too. Russ Steve asked the authors to describe Russ1. which attacks are out of scope (and why!) 2. Russ which attacks are in-scope 2.1 and the protocol is Russ susceptible to 2.2 and the protocol protects against Russ This is better than us each making our own assessment of the Russ hash function security requirements. I didn't see that request but I think it is a fine direction. Honestly though the authors seem more upset about agility than about md5. I think we're certain we want agility. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCID and the use of MD5
At 11:15 AM -0500 11/29/05, Sam Hartman wrote: First, I brought up random oracle in an aside to Steve Bellovin. I'm not sure it particularly matters to this case. It doesn't seem like an aside, it seems central to the objection to the use of MD5. So, I know of nothing that asks little of a hash and can be used for privacy. The only model I know that can be used for privacy is random oracle and that asks a lot of a hash. Every protocol that uses a hash for privacy does so knowing that using the hash instead of the cleartext cause the attacker to have to do some number of hash attempts in order to detect the contents. From the cryptographic literature I have seen, random oracle strength of a hash is close to the length of the hash. I certainly could have missed something, and there may be new thinking based on the collision-resistance weakening of MD5 and SHA-1. If so, there should be a clear explanation from the Security Area of how protocols can and cannot use hashes for privacy. It seems absurd to be having this discussion the the general IETF list instead of on the CFRG. 1) algorithm agility. There are two kinds of algorithm agility: - build it into the protocol - rev the protocol each time you want to use a new algorithm Everyone always has the second. The protocol developer already made a strong argument against the first, namely that the protocol as described is already in wide deployment. Thus, the two kinds have pretty much the same effect on implementers of DHCID. 2) Remove paragraph about existing md5 attacks not being an issue or come up with theoretical justification for that paragraph. A better solution would be to follow Steve Bellovin's suggestion to beef up the Security Considerations to detail what is being protected. The fact that the material being obscured is already being moved around the network in the clear is quite relevant to the attack scenarios. 3) Use sha-1 or sha-256 instead of md5. This seems completely arbitrary, given that we do not know how much strength of privacy is needed. It is also arbitrary until someone can say how much strength each algorithm gives the protocol, and that has yet to be stated. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
there is one thing buried in here that's worth answering: Hallam-Baker, Phillip wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
I don't object to Steve's proposal to clarify the goal and limitations of the use of md5 in the security considerations section. what we're trying to achieve in the DHCID rrs is certainly no stronger than the 'privacy' offered by stateless v6 addresses or rfc3041 addresses. we aren't really making a 'privacy' claim; there's plenty of other un-obscured information available in the DNS along with the DHCIDs. we're only trying to make it difficult to track a DHCP client as it moves from address to address. md5 makes it more difficult than the plain-text version of an ethernet MAC address; that's enough for our purpose. would such a clarification be enough to resolve your DISCUSS, Sam Hartman? that is, if it were clearer that we're only aiming for more difficult than not difficult at all - would that be sufficiently clear guidance to admins about what they should expect from this mechanism? -- Mark Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Ted Lemon writes: On Saturday 26 November 2005 09:56, Steven M. Bellovin wrote: In fact, the Security Considerations section should analyze the (non-trivial) probability of a brute-force attack. It doesn't matter. The point of the DHCID is to allow two servers to avoid accidentally stepping on each other. If you break the DHCID, what you get is the ability to pretend that you are another DHCP client. If you succeed in doing this, you can take over that DHCP client's name, but you don't get to keep it, because you are using the same identification as the other client, and so it's going to take it back. The information that you would use to pretend to be the other client is routinely being sent over the network in the clear, so you don't need to break the DHCID to get it - you just need to listen on the wire for a packet from that client. You can't do the attack I've described unless you are on a network managed by a DHCP server that manages the same namespace as the server that put in the legitimate DHCID. It's true that we could exhaustively go over all possible exploits, no matter how trivial, no matter how useless, in the security considerations section. Do you honestly believe that this is necessary? It's the privacy aspect I'm concerned about. The protocol has a mechanism -- the hash -- intended to protect privacy. There are limitations to how well it works. These may be unavoidable; that said, they should be documented. See Section 5 of RFC 3552, a BCP: Authors MUST describe 1. which attacks are out of scope (and why!) 2. which attacks are in-scope 2.1 and the protocol is susceptible to 2.2 and the protocol protects against ... There should be a clear description of the residual risk to the user or operator of that protocol after threat mitigation has been deployed. Put another way, against a certain grade of attacker the mechanism doesn't do its job. That needs to be documented, so that people who are concerned about the issue know to avoid this option. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCID and the use of MD5
At 11:44 AM 11/29/2005, Sam Hartman wrote: Honestly though the authors seem more upset about agility than about md5. I think we're certain we want agility. There are two kinds of algorithm agility: - build it into the protocol - update the protocol each time you want to use a new algorithm Everyone always has the second. The author already made an argument against the first, but other seem to be supporting the other form. I do not understand the impact on the current deployment. Do you? Given deployed code, either path forces the existing code to change. Russ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCID and the use of MD5
Russ == Russ Housley [EMAIL PROTECTED] writes: Russ At 11:44 AM 11/29/2005, Sam Hartman wrote: Honestly though the authors seem more upset about agility than about md5. I think we're certain we want agility. Russ There are two kinds of algorithm agility: - build it into Russ the protocol - update the protocol each time you want to use Russ a new algorithm I disagree that you always have the second. In particular you may not have behavior that allows you to change the protocol. For example the SMIME verifier behavior of requiring all (instead of one) signature to validate makes the change the protocol approach harder. I think this is an example of a case where you don't have the second kind of agility without changing the protocol. In particular you need clients and hcp servers to expect there to be more than one record available. Russ Everyone always has the second. The author already made an Russ argument against the first, but other seem to be supporting Russ the other form. I do not understand the impact on the Russ current deployment. Do you? so, the deployed code will have to change somewhat already. They are currently using txt records; they will need to transition to this new RR. However the update behavior if you add agility is more complicated. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCID and the use of MD5
On 11/29/05, Sam Hartman [EMAIL PROTECTED] wrote: However the update behavior if you add agility is more complicated. I think this is the key to the objections, and deserves a lot of consideration. Adding agility would presumably require either a) Requiring that all consumers of DHCID records are configured to use the same hash algorithm, or b) Requiring that the DHCID record encodes the hash and possibly permitting multiple hashes for the same data. The problem with b) is that it changes the UPDATE process - right now, or with a), the DHCP server sends an UPDATE to the DNS server saying If this name exists, and if the DHCID record matches this string, then delete the existing records (and add the new record(s) (draft-ietf-dhc-ddns-resolution section 6.3.2). This is an atomic operation - the query, match and update. If the DHCP server doing the UPDATE doesn't know what hash to use a priori, it has to query the existing record to find out what hash to use, changing this to a multi-step process with possible associated race conditions (I think you can eliminate them, but you have to be careful). This is almost certainly what is getting the pushback. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
Mark == Mark Stapp [EMAIL PROTECTED] writes: Mark would such a clarification be enough to resolve your Mark DISCUSS, Sam Hartman? that is, if it were clearer that we're Mark only aiming for more difficult than not difficult at all - Mark would that be sufficiently clear guidance to admins about Mark what they should expect from this mechanism? So, as I described in my response to Russ, I'm asking for three things: 1) algorithm agility 2) Remove the paragraph explaining why md5 is OK or provide a theoretical model under which we can reason about how good a hash is at keeping stuff private. 3) Use sha-1 or sha-256 instead of md5. I feel very strongly about point 1. Unfortunately I think this is the point the working group most objects to. I understand the concerns about the complexity of the update process. However I also know that security primitives are things that you need to replace from time to time. If you were using md5 because it had a relatively even distribution of outputs you could probably convince me that you don't need a way to update it. However even if weakly you're using md5 for its cryptographic properties. Those can change over time so you need a mechanism to react to those changes. I suspect we can all agree that we need to either reword claims about security of cryptographic primitives so they are clearly true or remove those claims. So I don't think that we're going to have much of an issue with point 2. I think there is room for discussion on point 3. I think sha-1 or sha-256 would be a better choice. I think that there is an argument that md5 is not so bad that it cannot be used. If the working group ends up responding that it would really like to use md5, I can go to the security community and see what people think there. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCID and the use of MD5
Sam: Perhaps I was being too terse. I think we are in agreement about the most important parts. I was trying to say that once you are forced to deploy new code, protocol changes and algorithm changes are both avaioable options. Russ At 12:51 PM 11/29/2005, Sam Hartman wrote: Russ == Russ Housley [EMAIL PROTECTED] writes: Russ At 11:44 AM 11/29/2005, Sam Hartman wrote: Honestly though the authors seem more upset about agility than about md5. I think we're certain we want agility. Russ There are two kinds of algorithm agility: - build it into Russ the protocol - update the protocol each time you want to use Russ a new algorithm I disagree that you always have the second. In particular you may not have behavior that allows you to change the protocol. For example the SMIME verifier behavior of requiring all (instead of one) signature to validate makes the change the protocol approach harder. I think this is an example of a case where you don't have the second kind of agility without changing the protocol. In particular you need clients and hcp servers to expect there to be more than one record available. Russ Everyone always has the second. The author already made an Russ argument against the first, but other seem to be supporting Russ the other form. I do not understand the impact on the Russ current deployment. Do you? so, the deployed code will have to change somewhat already. They are currently using txt records; they will need to transition to this new RR. However the update behavior if you add agility is more complicated. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: DHCID and the use of MD5
Russ, Sorry, but what kind of options? Looking at my key board, I can't tell whether you meant to type available or avoidable... -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Russ Housley -- Sent: Tuesday, November 29, 2005 5:08 PM -- To: Sam Hartman -- Cc: ietf@ietf.org; [EMAIL PROTECTED] -- Subject: Re: DHCID and the use of MD5 -- -- Sam: -- -- Perhaps I was being too terse. I think we are in agreement -- about the -- most important parts. I was trying to say that once you are forced -- to deploy new code, protocol changes and algorithm changes are both -- avaioable options. -- -- Russ -- -- -- At 12:51 PM 11/29/2005, Sam Hartman wrote: -- Russ == Russ Housley [EMAIL PROTECTED] writes: -- -- Russ At 11:44 AM 11/29/2005, Sam Hartman wrote: -- Honestly though the authors seem more upset about -- agility than -- about md5. I think we're certain we want agility. -- -- Russ There are two kinds of algorithm agility: - -- build it into -- Russ the protocol - update the protocol each time -- you want to use -- Russ a new algorithm -- -- I disagree that you always have the second. In particular -- you may not -- have behavior that allows you to change the protocol. For -- example the -- SMIME verifier behavior of requiring all (instead of one) -- signature to -- validate makes the change the protocol approach harder. -- -- I think this is an example of a case where you don't have -- the second -- kind of agility without changing the protocol. In -- particular you need -- clients and hcp servers to expect there to be more than one record -- available. -- -- Russ Everyone always has the second. The author -- already made an -- Russ argument against the first, but other seem to -- be supporting -- Russ the other form. I do not understand the impact on the -- Russ current deployment. Do you? -- -- so, the deployed code will have to change somewhat -- already. They are -- currently using txt records; they will need to transition -- to this new -- RR. -- -- -- However the update behavior if you add agility is more complicated. -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
Making a hash function interchangeable in DHCID makes the conflict detection algorithm hugely more complicated, and possibly not workable at all. Think about how that would work. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
In message [EMAIL PROTECTED], Ted Lemon writes: Making a hash function interchangeable in DHCID makes the conflict detection algorithm hugely more complicated, and possibly not workable at all. Think about how that would work. I confess that I don't see the problem. The updater would do a DNS query for DHCID RRs; it would be given all of the stored records. The updater would then use local policy -- that is, an ordered list of preferred hash functions -- until it found one that was in the response. That one would be used. If no locally-known hash functions are in the list, it should behave as if there were no DHCID records present for that name. DNSSEC could protect against downgrade attacks. (Speaking of which -- were I still AD, I'd ding this document for an inadequate Security Considerations section -- apart from the lack of discussion of brute force attacks, you should cite 3833 for DNS attacks and explain what the risks are if someone can crack the hash function by any means, including brute force or eavesdropping on the wire or (perhaps) a misbehaving updater.) If you don't agree, I'd strongly suggest using SHA-256 instead of MD5. Yes, it's more expensive, but I doubt that that's a major hit on overall system performance here. It would also be useful to include in the document some discussion of upgrade strategy -- how would we ever switch to a new hash function? That's non-trivial even for protocols designed for agility, as Eric Rescorla and I have shown. No matter how it's done, this one is among the very hardest, since DNS servers would have to supply DHCID records for several hashes for a number of years. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
I confess that I don't see the problem. The updater would do a DNS query for DHCID RRs; it would be given all of the stored records. That's not how the current update algorithm works. Sure, we could do almost anything but we'll be debating this for the next 100 years. It has already gone on for almost 10 years!!! Can we get serious about this and really ask what are we trying to protect. And where were you folks when IPv6 was designed to use the mac address as the interface identifier. Come on. We're trying to make it NON-TRIVIAL, not impossible. This technique has been in use for years by implementations using TXT records because we've been unable to get the DHCID RR approved. - Bernie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven M. Bellovin Sent: Monday, November 28, 2005 11:49 AM To: Ted Lemon Cc: iesg@ietf.org; dhcwg@ietf.org; namedroppers@ops.ietf.org; Pekka Savola; ietf@ietf.org Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] In message [EMAIL PROTECTED], Ted Lemon writes: Making a hash function interchangeable in DHCID makes the conflict detection algorithm hugely more complicated, and possibly not workable at all. Think about how that would work. I confess that I don't see the problem. The updater would do a DNS query for DHCID RRs; it would be given all of the stored records. The updater would then use local policy -- that is, an ordered list of preferred hash functions -- until it found one that was in the response. That one would be used. If no locally-known hash functions are in the list, it should behave as if there were no DHCID records present for that name. DNSSEC could protect against downgrade attacks. (Speaking of which -- were I still AD, I'd ding this document for an inadequate Security Considerations section -- apart from the lack of discussion of brute force attacks, you should cite 3833 for DNS attacks and explain what the risks are if someone can crack the hash function by any means, including brute force or eavesdropping on the wire or (perhaps) a misbehaving updater.) If you don't agree, I'd strongly suggest using SHA-256 instead of MD5. Yes, it's more expensive, but I doubt that that's a major hit on overall system performance here. It would also be useful to include in the document some discussion of upgrade strategy -- how would we ever switch to a new hash function? That's non-trivial even for protocols designed for agility, as Eric Rescorla and I have shown. No matter how it's done, this one is among the very hardest, since DNS servers would have to supply DHCID records for several hashes for a number of years. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
BTW, whatever algorithm you use (SHA-256 or even something much more complex) is not going to help -- it may make the work someone has to do a bit more involved, but it really doesn't make it impossible. 1. You always have a brute force attack. As you indicate, calculating the hash based on the mac address is always going to be a possible attack. And, 8000 is not 8-bits, but more like 13. But agreed that many of the Ethernet OIDs are unlikely to be of much interest. 2. If the attacker is on the same network as the client at some point, they can learn the identifier of the client (snoop DHCP and/or ARP traffic). Once they have that, it is possible to query DNS for DHCID RRs (query for the PTR, query for a DHCID RR for the name). Once you have that, you use the name and client's identity and run it through the algorithm and check for a match. If you looked up all 2^32 PTRs, you'd be able to locate the client at other sites that use DHCP and export the DHCID RR information. The number of PTRs you'd likely have to query is much smaller than 2^32s. You could target just some domains (network addresses) that you were most interested in or where you suspect the client connects to the network. Far reducing the number of queries needed. - Bernie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven M. Bellovin Sent: Monday, November 28, 2005 11:49 AM To: Ted Lemon Cc: iesg@ietf.org; dhcwg@ietf.org; namedroppers@ops.ietf.org; Pekka Savola; ietf@ietf.org Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] In message [EMAIL PROTECTED], Ted Lemon writes: Making a hash function interchangeable in DHCID makes the conflict detection algorithm hugely more complicated, and possibly not workable at all. Think about how that would work. I confess that I don't see the problem. The updater would do a DNS query for DHCID RRs; it would be given all of the stored records. The updater would then use local policy -- that is, an ordered list of preferred hash functions -- until it found one that was in the response. That one would be used. If no locally-known hash functions are in the list, it should behave as if there were no DHCID records present for that name. DNSSEC could protect against downgrade attacks. (Speaking of which -- were I still AD, I'd ding this document for an inadequate Security Considerations section -- apart from the lack of discussion of brute force attacks, you should cite 3833 for DNS attacks and explain what the risks are if someone can crack the hash function by any means, including brute force or eavesdropping on the wire or (perhaps) a misbehaving updater.) If you don't agree, I'd strongly suggest using SHA-256 instead of MD5. Yes, it's more expensive, but I doubt that that's a major hit on overall system performance here. It would also be useful to include in the document some discussion of upgrade strategy -- how would we ever switch to a new hash function? That's non-trivial even for protocols designed for agility, as Eric Rescorla and I have shown. No matter how it's done, this one is among the very hardest, since DNS servers would have to supply DHCID records for several hashes for a number of years. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
--On mandag, november 28, 2005 17:00:39 -0500 Bernie Volz (volz) [EMAIL PROTECTED] wrote: I confess that I don't see the problem. The updater would do a DNS query for DHCID RRs; it would be given all of the stored records. That's not how the current update algorithm works. Sure, we could do almost anything but we'll be debating this for the next 100 years. It has already gone on for almost 10 years!!! Can we get serious about this and really ask what are we trying to protect. And where were you folks when IPv6 was designed to use the mac address as the interface identifier. Come on. We're trying to make it NON-TRIVIAL, not impossible. This technique has been in use for years by implementations using TXT records because we've been unable to get the DHCID RR approved. Bernie, just checking this puzzle seems to have several distinct pieces: - the DHCP options to talk about DNS names. Nobody seems to have any large problem with that. - the mechanism for detecting conflicts. Nobody seems to have any large problem with that. - the exact mechanism by which one stores a value identifying the client in the DNS without giving out useful information about the client. That's where all the shouting is. Can you verify for me that all three parts are being done today in production, in just the way (apart from RR type) specified in the I-Ds? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
Harald: Yes, I can. The ISC's DHCP server (www.isc.org) does this (I'm not sure whether it uses MD5 to encode the client identity or not). Ted might know for sure. As does Cisco's Network Registrar (though it presently doesn't encode the data using MD5). And, I'm pretty sure several other DHCP vendors do this -- though whether they're using MD5 or not I can't be sure. These servers are in production all over and have been doing this for many years. - Bernie -Original Message- From: Harald Tveit Alvestrand [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 5:14 PM To: Bernie Volz (volz); Steven M. Bellovin; Ted Lemon Cc: dhcwg@ietf.org; Pekka Savola; ietf@ietf.org; namedroppers@ops.ietf.org Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] --On mandag, november 28, 2005 17:00:39 -0500 Bernie Volz (volz) [EMAIL PROTECTED] wrote: I confess that I don't see the problem. The updater would do a DNS query for DHCID RRs; it would be given all of the stored records. That's not how the current update algorithm works. Sure, we could do almost anything but we'll be debating this for the next 100 years. It has already gone on for almost 10 years!!! Can we get serious about this and really ask what are we trying to protect. And where were you folks when IPv6 was designed to use the mac address as the interface identifier. Come on. We're trying to make it NON-TRIVIAL, not impossible. This technique has been in use for years by implementations using TXT records because we've been unable to get the DHCID RR approved. Bernie, just checking this puzzle seems to have several distinct pieces: - the DHCP options to talk about DNS names. Nobody seems to have any large problem with that. - the mechanism for detecting conflicts. Nobody seems to have any large problem with that. - the exact mechanism by which one stores a value identifying the client in the DNS without giving out useful information about the client. That's where all the shouting is. Can you verify for me that all three parts are being done today in production, in just the way (apart from RR type) specified in the I-Ds? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
BTW: Just to be clear, the MD5 hash is calculated using both the client identifier AND the domain name. But the domain name is known (it is the entry under which the DHCID RR lives). However, this means that the DHCID data for a client changes with its name. The RDATA for all type codes other than 0x, which is reserved for future expansion, is formed by concatenating the two type bytes and a 16-byte MD5 hash value. The input to the hash function is defined to be: data = MD5( identifier FQDN ) The FQDN is represented in the buffer in unambiguous canonical form as described in RFC 2535 [8], section 8.1. The type code and the identifier are related as specified in Section 3.3: the type code describes the source of the identifier. - Bernie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven M. Bellovin Sent: Saturday, November 26, 2005 11:57 AM To: Pekka Savola Cc: dhcwg@ietf.org; namedroppers@ops.ietf.org; iesg@ietf.org; ietf@ietf.org Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] In message [EMAIL PROTECTED], Pekka Savola writes: Hi, I'll break out the most substantial comments in separate messages.. On Mon, 14 Nov 2005, The IESG wrote: The IESG has received a request from the Dynamic Host Configuration WG to consider the following documents: - 'A DNS RR for Encoding DHCP Information (DHCID RR) ' draft-ietf-dnsext-dhcid-rr-10.txt as a Proposed Standard - 'Resolution of FQDN Conflicts among DHCP Clients ' draft-ietf-dhc-ddns-resolution-10.txt as a Proposed Standard - 'The DHCP Client FQDN Option ' draft-ietf-dhc-fqdn-option-11.txt as a Proposed Standard - 'The DHCPv6 Client FQDN Option ' draft-ietf-dhc-dhcpv6-fqdn-03.txt as a Proposed Standard I have only one major comment on DHCID on its use of MD5 as a glued-in hash-function. The rest of the comments are rather straightforward. substantial -- In order to avoid exposing potentially sensitive identifying information, the data stored is the result of a one-way MD5 [5] hash computation. The hash includes information from the DHCP client's REQUEST message as well as the domain name itself, so that the data stored in the DHCID RR will be dependent on both the client identification used in the DHCP protocol interaction and the domain name. This means that the DHCID RDATA will vary if a single client is associated over time with more than one name. This makes it difficult to 'track' a client as it is associated with various domain names. The MD5 hash algorithm has been shown to be weaker than the SHA-1 algorithm; it could therefore be argued that SHA-1 is a better choice. However, SHA-1 is significantly slower than MD5. A successful attack of MD5's weakness does not reveal the original data that was used to generate the signature, but rather provides a new set of input data that will produce the same signature. Because we are using the MD5 hash to conceal the original data, the fact that an attacker could produce a different plaintext resulting in the same MD5 output is not significant concern. == while the informatione exposure of someone cracking the MD5 hash is not too huge, I believe it is unacceptable to design new protocols without the capability to switch the hash function as need be. This could be achieved for example by reserving one additional byte from the start of the DHCID record to designate the hash function used. If you don't bother to define your own registry (for all of me, you could include MD5 there as well, but at least include SHA1 and preferably also SHA-256), you could possibly re-use http://www.iana.org/assignments/ds-rr-types or something like that. That way, we can introduce new hash functions in a backward compatible manner later on, with no need to revamp the protocol. If we don't do this, we'll need to define DHCID2, DHCID3, .. etc. records further down in the future (w/ different hash functions) and make DHCP co-exist with all of them. That's bound to cause a lot of protocol complexity, and I don't think we want to go there. I agree with this comment. The draft is wrong -- it asserts that a successful attack of MD5's weakness does not reveal the original data. That's an overassumption -- we have no idea what such an attack would yield, since no such attack currently exists. More generally... The currently-known attacks on MD5 are collision attacks: it's possible to generate two inputs that produce the same hash value. This scenario requires a preimage attack; none are known. It would not surprise me if someone were to develop one, but until that happens we can't speculate on its properties
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
In message [EMAIL PROTECTED], Ted Lemon writes: On Saturday 26 November 2005 09:56, Steven M. Bellovin wrote: In fact, the Security Considerations section should analyze the (non-trivial) probability of a brute-force attack. It doesn't matter. The point of the DHCID is to allow two servers to avoid accidentally stepping on each other. If you break the DHCID, what you get is the ability to pretend that you are another DHCP client. If you succeed in doing this, you can take over that DHCP client's name, but you don't get to keep it, because you are using the same identification as the other client, and so it's going to take it back. The information that you would use to pretend to be the other client is routinely being sent over the network in the clear, so you don't need to break the DHCID to get it - you just need to listen on the wire for a packet from that client. You can't do the attack I've described unless you are on a network managed by a DHCP server that manages the same namespace as the server that put in the legitimate DHCID. It's true that we could exhaustively go over all possible exploits, no matter how trivial, no matter how useless, in the security considerations section. Do you honestly believe that this is necessary? It's the privacy aspect I'm concerned about. The protocol has a mechanism -- the hash -- intended to protect privacy. There are limitations to how well it works. These may be unavoidable; that said, they should be documented. See Section 5 of RFC 3552, a BCP: Authors MUST describe 1. which attacks are out of scope (and why!) 2. which attacks are in-scope 2.1 and the protocol is susceptible to 2.2 and the protocol protects against ... There should be a clear description of the residual risk to the user or operator of that protocol after threat mitigation has been deployed. Put another way, against a certain grade of attacker the mechanism doesn't do its job. That needs to be documented, so that people who are concerned about the issue know to avoid this option. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
Thanks - these responses point out very clearly that the mechanism is being used as described, *except* for the bit that's contentious (use of MD5 for information hiding). This means that we will not have a backwards compatibility issue with the installed base if we change the format of the record, but *will* have a procedural compatibility issue if we don't keep the property of you can know the expected content of the record without fetching it. Harald --On mandag, november 28, 2005 17:20:09 -0500 Bernie Volz (volz) [EMAIL PROTECTED] wrote: Harald: Yes, I can. The ISC's DHCP server (www.isc.org) does this (I'm not sure whether it uses MD5 to encode the client identity or not). Ted might know for sure. As does Cisco's Network Registrar (though it presently doesn't encode the data using MD5). And, I'm pretty sure several other DHCP vendors do this -- though whether they're using MD5 or not I can't be sure. These servers are in production all over and have been doing this for many years. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
--On tirsdag, november 29, 2005 00:03:03 -0700 Ted Lemon [EMAIL PROTECTED] wrote: On Monday 28 November 2005 23:40, Harald Tveit Alvestrand wrote: This means that we will not have a backwards compatibility issue with the installed base if we change the format of the record, but *will* have a procedural compatibility issue if we don't keep the property of you can know the expected content of the record without fetching it. Yup. My only objection to changing the hash algorithm is that it means a rev of the document that could cause us to go through another wglc or ietf last call (as opposed to editorial changes, which presumably would not).Otherwise, while I don't think it makes any difference, it's otherwise fine to use SHA-256 instead of MD5. After reading the docs, I don't think it makes any difference either. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
Steven == Steven M Bellovin [EMAIL PROTECTED] writes: I'm currently writing a discuss on the md5 issue. At a minimum you will need to specify the complexity in order to deal with changing hash algorithms. Steven More generally... The currently-known attacks on MD5 are Steven collision attacks: it's possible to generate two inputs Steven that produce the same hash value. This scenario requires Steven a preimage attack; none are known. It would not surprise Steven me if someone were to develop one, but until that happens Steven we can't speculate on its properties. There are, however, Actually, no, it's worse than that. A preimage attack is sufficient to break this. However you cannot reduce a break of this system to a preimage attack. We actually know very little about how much information hash functions leak. We can prove an uppor bound on this given the assumption that they are one-way. If they leak too much information then they are not one-way and we can find preimages. However I don't think we can say much more than that. we can treat a hash function as a random oracle and under that assumption it does not leak information. The random oracle assumption is much stronger than collision resistance. Collision resistance can certainly be reduced to random oracle. So, saying that you can find collisions actually is a very strong strike against the use of a particular hash function as a random oracle. I am not happy with a protocol whose security depends on treating md5 as a random oracle. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
This would, as Ted indicates, greatly complicate the entire update sequence. The current update sequence (see draft-ietf-dhc-ddns-resolution-10.txt), never does a query of the RRs in the server. Therefore, either we'd have to do a query first to obtain the DHCID RR and extract the algorithm so we can do the comparison, or we'd have to try each of the algorithms in a DNS update operation. Neither of these is particularily pleasant (especially considering that things can change between DNS operations). And, if not all implementations support all algorithms, you'd have real interop problems. And, what's the benefit? It isn't like this information is hyper sensitive (come on, IPv6 uses the mac address in the link identifier -- yes, I know about RFC 3041). While MD5 could be compromised, you can't necessarily get back the mac address that was used to generate the value. Yet, we also have to remember that we're dealing with a 48-bit *INPUT* in many cases for the DHCID -- the mac address. A brute force attack is not out of the question if you really wanted to get the data (and given the well known 24-bit OID values, you could probably cut down the bruce force attack to make it very reasonable whatever scheme we used). If a client identifier or DUID is used, this does likely mean more bits but most client identifiers and DUIDs are based on mac addresses. So, let's be realistic here and not unnecessarily complicate matters for no real benefit. If there is a strong argument to improve the security of this information, we can debate whether SHA1 or SHA-256 be used for the start. But, I for one don't see the need. - Bernie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pekka Savola Sent: Saturday, November 26, 2005 2:10 PM To: Ted Lemon Cc: dhcwg@ietf.org; ietf@ietf.org; iesg@ietf.org; namedroppers@ops.ietf.org Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard] On Sat, 26 Nov 2005, Ted Lemon wrote: Making a hash function interchangeable in DHCID makes the conflict detection algorithm hugely more complicated, and possibly not workable at all. Think about how that would work. AFAICS, it shouldn't be all that complicated as long as the implementations [checking for conflicts] support all the algorithms used at the site, right? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
In message [EMAIL PROTECTED], Pekka Savola writes: Hi, I'll break out the most substantial comments in separate messages.. On Mon, 14 Nov 2005, The IESG wrote: The IESG has received a request from the Dynamic Host Configuration WG to consider the following documents: - 'A DNS RR for Encoding DHCP Information (DHCID RR) ' draft-ietf-dnsext-dhcid-rr-10.txt as a Proposed Standard - 'Resolution of FQDN Conflicts among DHCP Clients ' draft-ietf-dhc-ddns-resolution-10.txt as a Proposed Standard - 'The DHCP Client FQDN Option ' draft-ietf-dhc-fqdn-option-11.txt as a Proposed Standard - 'The DHCPv6 Client FQDN Option ' draft-ietf-dhc-dhcpv6-fqdn-03.txt as a Proposed Standard I have only one major comment on DHCID on its use of MD5 as a glued-in hash-function. The rest of the comments are rather straightforward. substantial -- In order to avoid exposing potentially sensitive identifying information, the data stored is the result of a one-way MD5 [5] hash computation. The hash includes information from the DHCP client's REQUEST message as well as the domain name itself, so that the data stored in the DHCID RR will be dependent on both the client identification used in the DHCP protocol interaction and the domain name. This means that the DHCID RDATA will vary if a single client is associated over time with more than one name. This makes it difficult to 'track' a client as it is associated with various domain names. The MD5 hash algorithm has been shown to be weaker than the SHA-1 algorithm; it could therefore be argued that SHA-1 is a better choice. However, SHA-1 is significantly slower than MD5. A successful attack of MD5's weakness does not reveal the original data that was used to generate the signature, but rather provides a new set of input data that will produce the same signature. Because we are using the MD5 hash to conceal the original data, the fact that an attacker could produce a different plaintext resulting in the same MD5 output is not significant concern. == while the informatione exposure of someone cracking the MD5 hash is not too huge, I believe it is unacceptable to design new protocols without the capability to switch the hash function as need be. This could be achieved for example by reserving one additional byte from the start of the DHCID record to designate the hash function used. If you don't bother to define your own registry (for all of me, you could include MD5 there as well, but at least include SHA1 and preferably also SHA-256), you could possibly re-use http://www.iana.org/assignments/ds-rr-types or something like that. That way, we can introduce new hash functions in a backward compatible manner later on, with no need to revamp the protocol. If we don't do this, we'll need to define DHCID2, DHCID3, .. etc. records further down in the future (w/ different hash functions) and make DHCP co-exist with all of them. That's bound to cause a lot of protocol complexity, and I don't think we want to go there. I agree with this comment. The draft is wrong -- it asserts that a successful attack of MD5's weakness does not reveal the original data. That's an overassumption -- we have no idea what such an attack would yield, since no such attack currently exists. More generally... The currently-known attacks on MD5 are collision attacks: it's possible to generate two inputs that produce the same hash value. This scenario requires a preimage attack; none are known. It would not surprise me if someone were to develop one, but until that happens we can't speculate on its properties. There are, however, some reasons for concern. One of the options defined, the DHCPv4 Client Identifier, probably doesn't have much entropy. For example, a suggestion in RFC 2132 says to use the ARP hardware type code and MAC address. There's exactly one interesting hardware type code for most users, and the high-order 3 bytes of the MAC address are the manufacturer's ID, not many of which are actually used. Given that this is an 8-byte input string and that MD5 has an 8-byte output, it is plausible that comparatively few input strings hash to any given output. If several of the input bytes are fixed, or at least constrained, there may be only one. For that matter, that assumption alone may lead to a successful attack on MD5. In fact, the Security Considerations section should analyze the (non-trivial) probability of a brute-force attack. Again, consider the Client Identifier, which is likely 8 bytes long. 2 are fixed, and hence irrelevant. According to today's copy of http://standards.ieee.org/regauth/oui/oui.txt there are 8786 manufacturer IDs, or slightly more than 8 bits. Effectively, though, it's less, since the usage is very non-uniform. Even if is uniform, though, that field plus the unit identifier only total slightly over 32 bits -- well
