Subject: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs

From: Ralph Droms <[email-masked]>
Date: Thu, 02 Feb 2006 16:38:27 -0500

Included below is a summary list of the open issues in this package of
documents:

draft-ietf-dnsext-dhcid-rr-10.txt
draft-ietf-dhc-ddns-resolution-10.txt
draft-ietf-dhc-dhcpv6-fqdn-03.txt
draft-ietf-dhc-fqdn-option-11.txt

1.  Which DHCID RR encoding does an IPv4 client/server use (Brian
    Carpenter; Bernie has submitted text to resolve the issue)
2.  Editorial comment on resolution doc section 6.3.2 and AAAA records
    (Ted Hardie)
3.  s/byte/octet/g  (Scott Hollenbeck)
4.  Use example. or example.com. in examples (Scott Hollenbeck)
5.  s/signature/hash value/g (Russ Housley)
6.  In the resolution doc "security considerations" s/where or/whether
    or/ (Jon Peterson)
7.  Add an 8-bit algorithm identifier to the DHCID RR to
    support algorithm agility (Allison Mankin)
8.  Use of MD5 as opposed to a stronger hash function (Sam Hartman,
    Russ Housley)
9.  Hash agility (Sam Hartman, Allison Mankin)
10. Russ's comment that an attacker that has some knowledge of MAC
    addresses does not need to do lot of work. I think this can be
    addressed in security considerations by saying this is not privacy
    but just obfuscation (Russ Housley)
11. UTF-8 character set usage (Harald Alvestrand, gen-art)

Issues 1-6 are strictly editorial and the document editors will revise the
documents to resolve those issues in the next revision.

Issues 7-10 are all related to the hash algorithm specified in the documents
and the requirements for algorithm agility.  We will resolve those issues
through an e-mail discussion to follow.

Issue 11 needs some clarification; Harald, I hope you'll kick off a separate
thread to discuss how to resolve this issue.

- Ralph, for Olafur, Stig and Olaf

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 02 Feb 2006 15:13:16 -0800

--On 2. februar 2006 16:38 -0500 Ralph Droms <[email-masked]> wrote:

> Issue 11 needs some clarification; Harald, I hope you'll kick off a
> separate thread to discuss how to resolve this issue.
>

I'll try....
back in the days (November - how time flies), my comments on 
draft-ietf-dhc-fqdn-option-11.txt said:

>A smaller piece of missing material is this, from section 3.3.1 of the v4
>document:
>
>   Clients and servers SHOULD follow the character-set recommendations
>   of RFC 1034 [2] and RFC 1035 [3].  However, implementers SHOULD also
>   be aware that some client software could be using UTF-8 [10]
>   character encoding.  This specification does not require any support
>   for UTF-8.
>
>Given DNS experts' insistence that the DNS protocol does not place any
>limits on character sets, it would be good to have a clearer pointer to
>what recommendations are intended here.
>Given that it's in section 3.3.1 (Deprecated ASCII encoding), one can
>assume that this refers to a character set recommendation for characters 
in
>the ASCII encoding; a DNS encoded name should probably be used "as is", no
>matter what it contains (although it would be good if the doc said so).
>
>
>It's also unclear from the text whether or not there's a trailing dot on
>the name in the deprecated ASCII encoding (there's no need for one, since 
a
>non-FQDN name can only be one component, but other fields of use have done
>this in the past, so it's best to be clear that this field does not do so).

On the point of character set recommendations, I think what you should be 
pointing at is not 1034 and 1035 in general, but say that they SHOULD 
follow the recommendation of RFC 1035 section 2.3.1.
Since the rule was actually relaxed in RFC 1123 section 2.1, I think the 
sentence should say "SHOULD follow the character set recommendation of RFC 
1035 section 2.3.1, as modified by RFC 1123 section 2.1".

That's not an UTF-8 issue, but is a charset issue. The UTF-8 text is a 
cop-out (I think), but it's appropriate to cop-out here; you're basically 
saying "don't be surprised if people don't do what this spec recommends".

Does this make sense now?

                         Harald

---

From: Mark Andrews <[email-masked]>
Date: Fri, 03 Feb 2006 10:58:20 +1100

> back in the days (November - how time flies), my comments on=20
> >assume that this refers to a character set recommendation for characters=20
> in
> >the name in the deprecated ASCII encoding (there's no need for one, since=20
> a
> >this in the past, so it's best to be clear that this field does not do =
> so).
> 
> On the point of character set recommendations, I think what you should be=20
> pointing at is not 1034 and 1035 in general, but say that they SHOULD=20
> Since the rule was actually relaxed in RFC 1123 section 2.1, I think the=20
> sentence should say "SHOULD follow the character set recommendation of RFC=20

	RFC 1123 relaxed RFC 952 (and RFC 822 by implication) not
	RFC 1035.  It relaxed to *hostnames* not domain names.
	Domain names were already general enough to support mapping
	the expanded hostnames to domainnames using the null mapping.

	The rest follows from that relaxation.  RFC 1035 section
	2.3.1 is advisary based on the state of RFC 952 and RFC
	822 when it was written.

> That's not an UTF-8 issue, but is a charset issue. The UTF-8 text is a=20
> cop-out (I think), but it's appropriate to cop-out here; you're basically=20

	For IDN's I would recommend using the output of ToASCII.
 
> --==========26E6B02998774739D698==========
> Content-Type: application/pgp-signature
> Content-Transfer-Encoding: 7bit
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (MingW32)
> 
> iD8DBQFD4pIMOMj+2+WY0F4RAvZIAJ0X6mjMkoIMa7z8MyFxFx1RwWB0uACg6DyN
> s8bXurZt6s6CWcvE9ELeS/A=
> =I6Vk
> -----END PGP SIGNATURE-----
> 
> --==========26E6B02998774739D698==========--
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 03 Feb 2006 11:10:37 +0900

> 	2.3.1 is advisary based on the state of RFC 952 and RFC

DHCP should not try to define or give improper descriptions on
anything about domainnames nor hostnames.

DHCP should just refer relevant STDs and RFCs without referring
to UTF-8, ASCII nor character sets.

That's how we can keep standards orthogonal.

Extra infromation is useless to those who knows them and harmful
to those who don't already have enough knowledge on them.

						Masataka Ohta

---

From: Pekka Savola <[email-masked]>
Date: Wed, 8 Feb 2006 14:57:43 +0200 (EET)

On Thu, 2 Feb 2006, Ralph Droms wrote:
> Included below is a summary list of the open issues in this package 
> of documents:
>

Just checking, did you also check the following mails:

http://www1.ietf.org/mail-archive/web/ietf/current/msg38995.html
http://www1.ietf.org/mail-archive/web/ietf/current/msg38994.html
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05678.html

?

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Feb 2006 11:41:51 -0700

> http://www1.ietf.org/mail-archive/web/ietf/current/msg38994.html

It's because of this one that I'm arguing that we should just not do the hash 
at all.   Algorithm-switching is expensive.