Subject: [dhcwg] unsubscribe

From: "Victor Rojas" <[email-masked]>
Date: Mon, 28 Nov 2005 16:05:06 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Monday, November 28, 2005 04:03 PM
To: [email-masked]
Subject: dhcwg Digest, Vol 19, Issue 28

Send dhcwg mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/dhcwg
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcwg digest..."

Today's Topics:

   1. RE: DHCP and FQDN conflicts [Re: Last Call: 'Resolution of
      FQDN Conflicts among DHCP Clients' to Proposed Standard]
      (Bernie Volz (volz))
   2. Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of
      FQDN Conflicts among DHCP Clients' to Proposed Standard] (Ted Lemon)
   3. Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of
      FQDN Conflicts among DHCP Clients' to Proposed Standard] (Sam Hartman)
   4. Re: DHCP and FQDN conflicts [Re: Last Call: 'Resolution of
      FQDN Conflicts among DHCP Clients' to Proposed Standard] (Sam Hartman)
   5. Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of
      FQDN Conflicts among DHCP Clients' to Proposed Standard]
      (Steven M. Bellovin)
   6. Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of
      FQDN Conflicts among DHCP Clients' to Proposed Standard]
      (Steven M. Bellovin)
   7. RE: Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution
      ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
      (Bernie Volz (volz))

----------------------------------------------------------------------

Message: 1
Date: Mon, 28 Nov 2005 12:09:23 -0500
From: "Bernie Volz \(volz\)" <[email-masked]>
Subject: RE: [dhcwg] DHCP and FQDN conflicts [Re: Last Call:
	'Resolution of	FQDN Conflicts among DHCP Clients' to Proposed
	Standard]
To: "Pekka Savola" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Message-ID:
	<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

> This does not address the scenario where a host has multiple AAAA
> records and the DHCPv6 server is performing the updates -- and hence
> ends up deleting all except one record, right?
>
> In that case, the DHCP(v6) server should possibly refuse to do any
> forward DNS updates because it might end up deleting something it
> should not.

You can have DHCPv4 servers such as those likely in wide deployment
today that assume one address per client and thus remove anything that's
there already. This works well even when a host moves between networks
(as the DHCP client will interact with the server whenever it connects
to a network).

Ideally, when DHCPv6 (IPv6) is added, the DHCPv4 servers would ideally
not touch the AAAA records when updating A records -- they'd just remove
all A RRs and add the current.

For DHCPv6 servers, depending on policy (such as if it is the only
server or if there is a one address/client policy) it may delete
everything and add back those that are current or may just do
add/removes. It really all depends on what the updater's policy is and
whether it is the only updater or not. I suspect that the DHCPv6 is more
likley to do adds/removes of individual RRs.

Do we really need to get into this level of specificity around this?

- Bernie

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Monday, November 28, 2005 3:37 AM
> To: Bernie Volz (volz)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [dhcwg] DHCP and FQDN conflicts [Re: Last Call:
> 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed
> Standard]
>
> On Sun, 27 Nov 2005, Bernie Volz (volz) wrote:
> > Regarding your one major issue, the updater is NOT the
> entity that gets
> > to decide whether to allow any DNS update to occur or not.
> It is the DNS
> > server that restricts who can do updates and what they can update.
> >
> > We're assuming that the most likely entity to be given fairly open
> > access to a zone is the DHCP server and that is where the
> administrative
> > policy comes in.
>
> I'm sure the zone administrators would like to have policy
> controls of
> their own.  But as you say above, the assumption is that the DHCP
> server can be given "fairly open access" to the zone.  In most cases
> this might imply (taking BIND9 as an example) "allow-update"
> from DHCP
> servers and "update-policy self" from hosts themselves.
>
> Because DHCP server is assumed to be given fairly liberal access at
> least in some scenarios, I believe it's justified to be more open
> about the threats of having too open policy and discouraging against
> a particular update scenario.
>
> ...
> >> ==> how does the code know whether the updates only desires a
> >> single IP address on the FQDN or not?  AFAICS, there's no way to
> >> signal this from the DHCP client!
> >
> > Agreed. That is why the language is the way it is. As a
> DHCP server is
> > likely to be doing the updates, it would be the entity to
> implement the
> > policy. In most DHCPv4 environments today, it is just a
> single A record
> > that is allowed.
> >
> > If the client is doing the updates, it is aware of what it has and
> > therefore can do the correct thing.
>
> This does not address the scenario where a host has multiple AAAA
> records and the DHCPv6 server is performing the updates -- and hence
> ends up deleting all except one record, right?
>
> In that case, the DHCP(v6) server should possibly refuse to do any
> forward DNS updates because it might end up deleting something it
> should not.
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>

------------------------------

Message: 2
Date: Mon, 28 Nov 2005 11:59:20 -0600
From: Ted Lemon <[email-masked]>
Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:
	'Resolution of	FQDN Conflicts among DHCP Clients' to Proposed
	Standard]
To: "Steven M. Bellovin" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],	Pekka
	Savola <[email-masked]>, [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain;  charset="iso-8859-1"

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.

------------------------------

Message: 3
Date: Sun, 27 Nov 2005 17:21:31 -0500
From: Sam Hartman <[email-masked]>
Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:
	'Resolution of FQDN Conflicts among DHCP Clients' to Proposed
	Standard]
To: "Steven M. Bellovin" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],	Pekka Savola
	<[email-masked]>, [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

>>>>> "Steven" == Steven M Bellovin <[email-masked]> 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

------------------------------

Message: 4
Date: Mon, 28 Nov 2005 13:13:43 -0500
From: Sam Hartman <[email-masked]>
Subject: Re: [dhcwg] DHCP and FQDN conflicts [Re: Last Call:
	'Resolution of	FQDN Conflicts among DHCP Clients' to Proposed
	Standard]
To: "Bernie Volz (volz)" <[email-masked]>
Cc: [email-masked], [email-masked], Pekka Savola <[email-masked]>,
	[email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

>>>>> "Bernie" == Bernie Volz (volz) <[email-masked]> writes:

    Bernie> For DHCPv6 servers, depending on policy (such as if it is
    Bernie> the only server or if there is a one address/client
    Bernie> policy) it may delete everything and add back those that
    Bernie> are current or may just do add/removes. It really all
    Bernie> depends on what the updater's policy is and whether it is
    Bernie> the only updater or not. I suspect that the DHCPv6 is more
    Bernie> likley to do adds/removes of individual RRs.

    Bernie> Do we really need to get into this level of specificity
    Bernie> around this?

You need to get sufficiently specific that in practice, the
implementation of this option is not influencing addressing plans.
For example if servers tend to get this wrong in a way that makes it
difficult for me to have multiple addresses for client then you were
not specific enough.

--Sam

------------------------------

Message: 5
Date: Sat, 26 Nov 2005 11:56:35 -0500
From: "Steven M. Bellovin" <[email-masked]>
Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:
	'Resolution of	FQDN Conflicts among DHCP Clients' to Proposed
	Standard]
To: Pekka Savola <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

In message <[email-masked]>, 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 within anyone's capabilities.

Most of this analysis applies to the other two options as well.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

------------------------------

Message: 6
Date: Mon, 28 Nov 2005 11:49:25 -0500
From: "Steven M. Bellovin" <[email-masked]>
Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:
	'Resolution of	FQDN Conflicts among DHCP Clients' to Proposed
	Standard]
To: Ted Lemon <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],	Pekka
	Savola <[email-masked]>, [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

In message <[email-masked]>, 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

------------------------------

Message: 7
Date: Mon, 28 Nov 2005 17:00:39 -0500
From: "Bernie Volz \(volz\)" <[email-masked]>
Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:
	'Resolution	ofFQDN Conflicts among DHCP Clients' to Proposed Standard]

To: "Steven M. Bellovin" <[email-masked]>, "Ted Lemon"
	<[email-masked]>
Cc: [email-masked], Pekka Savola <[email-masked]>, [email-masked],
	[email-masked], [email-masked]
Message-ID:
	<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

> 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-masked] [mailto:[email-masked]]
> On Behalf Of Steven M. Bellovin
> Sent: Monday, November 28, 2005 11:49 AM
> To: Ted Lemon
> Cc: [email-masked]; [email-masked]; [email-masked];
> Pekka Savola; [email-masked]
> Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:
> 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed
> Standard]
>
> In message <[email-masked]>, 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

------------------------------

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

End of dhcwg Digest, Vol 19, Issue 28
*************************************

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