Subject: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

From: Pekka Savola <[email-masked]>
Date: Sat, 26 Nov 2005 16:22:35 +0200 (EET)

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.

...

                                  New DHCID RR type codes are
    tentatively assigned after the specification for the associated type
    code, published as an Internet Draft, has received expert review by a
    designated expert.  The final assignment of DHCID RR type codes is
    through Standards Action, as defined in RFC 2434 [6].

==> this new RR type code assignment procedure seems to be 
underspecified.  Is there actually harm in just doing this through 
expert review, and giving the expert guidance that at least an I-D 
must be published?  If so, you could reword this like:

    New DHCID RR type codes are assigned through Standards Action or
    Expert Review as defined in RFC2434 [6].  The expert should require
    sufficient public specification of the new type code.

.. in any case, please use existing RFC2434 mechanism unless you're 
absolutely sure those won't fit your needs.

semi-editorial
--------------

    Conflicts can arise if multiple DHCP clients wish to use the same DNS
    name.  To resolve such conflicts, "Resolution of DNS Name Conflicts"
    [1] proposes storing client identifiers in the DNS to unambiguously
    associate domain names with the DHCP clients using them.

==> conflicts also occur when multiple nodes use the same FQDN while only a
part of them uses DHCP.  So, the above applicability could be reworded,
e.g., like follows:

    Conflicts can arise if multiple nodes wish to use the same DNS
    name.  To resolve such conflicts when the nodes are using DHCP,
    "Resolution of DNS Name Conflicts"
    [1] proposes storing client identifiers in the DNS to unambiguously
    associate domain names with the DHCP clients using them.

3.5.  Examples

==> I'd also have liked to see an example of DHCPv6 DHCID generation.

editorial
---------
    A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
    Ethernet MAC address 01:02:03:04:05:06 using domain name
    "client.example.com" uses the client's link-layer address to identify
    the client.

==> you should probably use RFC3330 documentation prefix here instead of
10/8.

    To resolve such conflicts, "Resolution of DNS Name Conflicts" [1]
    proposes storing client identifiers in the DNS to unambiguously
    associate domain names with the DHCP clients to which they refer.

==> no refs in the abstract

    A set of procedures to allow DHCP [7] clients and servers to
    automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
    in "Resolution of DNS Name Conflicts" [1].

==> also refer DHCPv6 here, please

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: Pekka Savola <[email-masked]>
Date: Sat, 26 Nov 2005 16:27:27 +0200 (EET)

>   <draft-ietf-dhc-dhcpv6-fqdn-03.txt> as a Proposed Standard

I have one major issue with 'Resolution of FQDN Conflicts among DHCP 
Clients', the first issue below.  It fails to properly describe the 
threats caused by DHCP clients requesting updating non-DHCP FQDN's 
(like a random host from example.com requesting "www.example.com"). 
While this may not be a problem if DHCP clients belong to different 
zones from non-DHCP clients, this is not discussed at all in the 
document -- except ruled out of scope.

This discussion needs to be included.

.......

6.3.3.  FQDN in Use by another Client

    As the FQDN appears to be in use by another client or is not
    associated with any client, the updater can decide (based on some
    administrative configuration outside of the scope of this document)
    whether to let the existing owner of the FQDN keep that FQDN, and to
    (possibly) perform some FQDN disambiguation operation on behalf of
    the current client, or to replace the RRs on the FQDN with RRs that
    represent the current client.  [...]

==> this is the biggest short-coming in this specification.  The choice of
this "administrative configuration outside the scope of this document" has
enermous security implications which have not been discussed at all in
Security Considerations section or here.

Specifically, consider the scenario:

1) www.example.com is manually configured (no DHCP) to point to 1.1.1.1,
    hence has no DHCID records.
2) a node in example.com zone uses DHCP, and purports its name is
    "www.example.com".  The DHCP server may nor may not perform the update
    based on the "admin config outside the scope of this document".

When reading the specification, this specific danger should be very clearly
explained, and this should be reflected in the document.  I'd also suggest
that by default, the server MUST NOT (or SHOULD NOT) perform updates if
there is no DHCID RR.

...

6.3.2.  DNS UPDATE When FQDN in Use

    2.  A delete of the existing AAAA RRs on the FQDN if the updater does
        not desire AAAA records on the FQDN or this update is adding an
        AAAA and the updater only desires a single IP address on the
        FQDN.

==> 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!

5.  DNS RR TTLs

==> this section describes which TTLs to use in DNS RRs with DHCP.  This has
nothing to do with conflict resolution, though it's convenient to specify
this (which applies to both DHCPv4 and DHCPv6) here instead of duplicating
the same text in both DHCPv4/v6 specifications.  But should this still be
moved there?

semi-editorial
--------------

    There are two DNS update situations that require special
    consideration in DHCP environments: cases where more than one DHCP
    client has been configured with the same FQDN and cases where more
    than one DHCP server has been given authority to perform DNS updates
    in a zone.

==> the first point is actually more generic than that (though you cover it
as well in section 6.3.3), but rewording would be useful.  How about:

    There are two DNS update situations that require special
    consideration in DHCP environments: cases where more than one node is
    configured with the same FQDN and cases where more
    than one DHCP server has been given authority to perform DNS updates
    in a zone.

(and similar, "s/DHCP clients/nodes/" throughout -- it's sufficient that one
node uses DHCP, the others don't need to..)

editorial
---------

    FQDN, or Fully Qualified Domain Name, is the full name of a system,
    rather than just its hostname.  For example, "venera" is a hostname
    and "venera.isi.edu" is an FQDN.  See RFC 1983 [7].

==> use "example.com", please.

     Through the use of the client
    FQDN option, DHCP clients and servers can negotiate the client's FQDN
    and the allocation of responsibility for updating the DHCP client's A
    and/or AAAA RRs.

==> also PTR records, not just A/AAAA..

When either a client or server
    adds A, AAAA, or PTR RRs for a client, it also adds a DHCID RR that
    specifies a unique client identity, based on data from the client's
    DHCPREQUEST message.

==> seems to use DHCPv4-specific terminology, also add DHCPv6 wording?

    The most important consideration in removing DNS entries is be sure
    that an entity removing a DNS entry is only removing an entry that it
    added, or for which an administrator has explicitly assigned it
    responsibility.

==> s/be/being/ ?

9.2.  Informative References

    [5]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
          March 1997.

    [6]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
          Carney, "Dynamic Host Configuration Protocol for IPv6
          (DHCPv6)", RFC 3315, July 2003.

==> These should likely be normative references.

    Sites that wish to permit a single FQDN to contain both A and AAAA
    RRs MUST make use of DHCPv4 clients and servers that support using
    the DHCP Unique Identifier (DUID) for DHCPv4 client identifiers such
    that this DUID is used in computing the RDATA of the DHCID RR by both
    DHCPv4 and DHCPv6 for the client, see Node-Specific Client
    Identifiers for DHCPv4 [14].

==> [14] should likely be a normative reference.  The good news is that it's
already in RFC editor's queue! :)

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 26 Nov 2005 11:56:35 -0500

>glued-in hash-function.  The rest of the comments are rather 

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

---

From: Pekka Savola <[email-masked]>
Date: Sat, 26 Nov 2005 21:10:16 +0200 (EET)

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?

---

From: Sam Hartman <[email-masked]>
Date: Sun, 27 Nov 2005 17:21:31 -0500

>>>>> "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

---

From: Ted Lemon <[email-masked]>
Date: Sat, 26 Nov 2005 12:43:21 -0600

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 28 Nov 2005 11:49:25 -0500

>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.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 29 Nov 2005 00:02:02 -0500

In message <[email-masked]>, Ted Lemon writes:
>On Saturday 26 November 2005 09:56, Steven M. Bellovin wrote:
>> (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.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Nov 2005 11:59:20 -0600

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.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Nov 2005 21:50:00 -0700

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Nov 2005 22:00:18 -0700

> to break this.  However you cannot reduce a break of this system to a

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

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.

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 Nov 2005 10:26:27 -0500

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 29 Nov 2005 11:15:28 -0500

>>>>> "Russ" == Russ Housley <[email-masked]> 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

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 Nov 2005 11:25:00 -0500

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 29 Nov 2005 09:09:07 -0800

>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.

>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.

>    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

---

From: Mark Stapp <[email-masked]>
Date: Tue, 29 Nov 2005 09:22:41 -0500

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:

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 29 Nov 2005 14:47:49 -0500

>>>>> "Mark" == Mark Stapp <[email-masked]> 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.

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