No subject
Tue Nov 18 23:43:20 CET 2008
In the presence of DNSSEC, no form of a zone file or query response that co=
ntains a U-label may be signed or the signature validated.
[a U-label indicates a name form containing non-ASCII characters not proper=
ly encoded with IDN].
I would expect that DNSSEC would operate at the layer below IDN, and could =
therefore sign and validate any data that DNS could validly return. There m=
ay be subtle reason for this restriction that I don't understand, but the j=
ustification in the document didn't seem right.
--Charlie
--_000_D80EDFF2AD83E648BD1164257B9B091208282265TK5EX14MBXC115r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.5pt;
font-family:Consolas;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
span.EmailStyle19
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri","sans-serif";}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DSection1><p class=3DMsoPlainText><span style=3D'fo=
nt-family:"Calibri","sans-serif"'>I am reviewing this document as part of t=
he security directorate's ongoing effort to review all IETF documents being=
processed by the IESG. These comments were written primarily for the=
benefit of the security area directors. Document editors and WG chai=
rs should treat these comments just like any other last call comments. Feel=
free to forward to any appropriate forum.<o:p></o:p></span></p><p class=3D=
MsoNormal><o:p> </o:p></p><p class=3DMsoNormal>This I-D is part of a s=
et of I-D’s that update the RFCs on Internationalized Domain Names. T=
his document is intended to become an Informational RFC and provides a rati=
onale for the proposed changes (as well as for the initial design of IDNA).=
Its Security Considerations section defers to draft-ietf-idnabis-defs-11.t=
xt, which has a good Security Considerations section.<o:p></o:p></p><p clas=
s=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>In my opinion, the =
change to IDNs that warrants the most concern is the fact that for some IDN=
s the new set of RFCs will specify a different representation than the old =
one did. This could in theory cause security problems, though that seems in=
tuitively unlikely (to me, at least).<o:p></o:p></p><p class=3DMsoNormal><o=
:p> </o:p></p><p class=3DMsoNormal>I would question one statement in t=
he document.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p cla=
ss=3DMsoNormal>From Section 8.2:<o:p></o:p></p><p class=3DMsoNormal><o:p>&n=
bsp;</o:p></p><p class=3DMsoNormal>In the presence of DNSSEC, no form of a =
zone file or query response that contains a U-label may be signed or the si=
gnature validated.<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p>=
<p class=3DMsoNormal>[a U-label indicates a name form containing non-ASCII =
characters not properly encoded with IDN].<o:p></o:p></p><p class=3DMsoNorm=
al><o:p> </o:p></p><p class=3DMsoNormal>I would expect that DNSSEC wou=
ld operate at the layer below IDN, and could therefore sign and validate an=
y data that DNS could validly return. There may be subtle reason for this r=
estriction that I don’t understand, but the justification in the docu=
ment didn’t seem right.<o:p></o:p></p><p class=3DMsoNormal><o:p> =
;</o:p></p><p class=3DMsoNormal> &=
nbsp; --Charlie<o:p></o:p></p></d=
iv></body></html>=
--_000_D80EDFF2AD83E648BD1164257B9B091208282265TK5EX14MBXC115r_--
More information about the Idna-update
mailing list