<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_ym19_1_1535587971069_9251" dir="ltr"><br><span id="yui_3_16_0_ym19_1_1535587971069_9470">> I find it very unlikely that an entity would
even apply for approval for a top-level label that is visually confusable of another.</span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1535587971069_9300"><span id="yui_3_16_0_ym19_1_1535587971069_9471"><br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1535587971069_10166"><span id="yui_3_16_0_ym19_1_1535587971069_9471">In which case, why would it be a problem if we identify something as a variant? <br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1535587971069_14739"><span id="yui_3_16_0_ym19_1_1535587971069_9471">The downside would appear to be all on the side of failing to identify something that presents a problem, not on the side of "over-producing". As several of us noted last week, the conservative approach is to identify MORE variants -- because it is far, <i id="yui_3_16_0_ym19_1_1535587971069_14810">far</i> easier to go back later and remove one than it is to go back later and add one. <br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1535587971069_9961"><span id="yui_3_16_0_ym19_1_1535587971069_9471"><br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1535587971069_13371"><span id="yui_3_16_0_ym19_1_1535587971069_13373">> </span><span id="yui_3_16_0_ym19_1_1535587971069_9471">Security risk analysis deserves a place in our work, but should first focus on real issues and not hypothetical ones.</span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1535587971069_14262"><span id="yui_3_16_0_ym19_1_1535587971069_9471"><br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1535587971069_14263"><span id="yui_3_16_0_ym19_1_1535587971069_9471">I'm not entirely clear what you think those "real issues" are. We are entirely in the business, in identifying variants, in looking at hypothetical cases. (Or are there actual submissions for new TLDs using new codepoints which are on hold pending the completion of our work? I haven't seen such examples raised here....) <br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1535587971069_14274"><span id="yui_3_16_0_ym19_1_1535587971069_9471"><br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1535587971069_9962"><span id="yui_3_16_0_ym19_1_1535587971069_10078">> </span><span id="yui_3_16_0_ym19_1_1535587971069_9471">I appreciate that any additional
work will delay our submission to IP before our workshop in early
October. But I think it is better that we take the time to deliver a
quality work.</span></div><div id="yui_3_16_0_ym19_1_1535587971069_9299"><span><br></span></div><div id="yui_3_16_0_ym19_1_1535587971069_10167" dir="ltr"><span id="yui_3_16_0_ym19_1_1535587971069_12222">I completely agree on the need to take as long as necessary to do the job right. But we can still give the IP a draft now to show them where we think we are, here at the end of August, to help guide us going forward. Even if we must note that some of the lists are still works in progress.<br></span></div><div id="yui_3_16_0_ym19_1_1535587971069_10274"><span><br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1535587971069_10565"><span id="yui_3_16_0_ym19_1_1535587971069_14558">I think it would be useful, in order to get the most comprehensive feedback from the IP, to include</span><span id="yui_3_16_0_ym19_1_1535587971069_10578"><span id="yui_3_16_0_ym19_1_1535587971069_14559"> in our forthcoming draft</span> several varieties of what you characterize as "corner cases". That way, the IP has the opportunity to tell us if they think we are going overboard. They are far more likely, after all, to give us feedback like "We don't think this case is sufficiently similar to be a variant" than they are to give us feedback like "We think you should have included this case, because we think it <i id="yui_3_16_0_ym19_1_1535587971069_15027">is</i> sufficiently similar." So let's give them the opportunity to do that.<br></span></div><div id="yui_3_16_0_ym19_1_1535587971069_9581"><span></span></div><div id="yui_3_16_0_ym19_1_1535587971069_9252"> </div><div class="signature" id="yui_3_16_0_ym19_1_1535587971069_9253">Bill Jouris<br>Inside Products<br>bill.jouris@insidethestack.com<br>831-659-8360<br>925-855-9512 (direct)</div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1535587971069_9254"><br><br></div><div class="yahoo_quoted" id="yui_3_16_0_ym19_1_1535587971069_9258" style="display: block;"> <div style="font-family: Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1535587971069_9257"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1535587971069_9256"> <div dir="ltr" id="yui_3_16_0_ym19_1_1535587971069_9255"> <font id="yui_3_16_0_ym19_1_1535587971069_9298" size="2" face="Arial"> <hr size="1"> <b><span style="font-weight:bold;">From:</span></b> "Tan Tanaka, Dennis via Latingp" <latingp@icann.org><br> <b><span style="font-weight: bold;">To:</span></b> Sarmad Hussain <sarmad.hussain@icann.org>; "latingp@icann.org" <latingp@icann.org> <br> <b><span style="font-weight: bold;">Sent:</span></b> Thursday, August 30, 2018 7:17 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [Latingp] From IP: Diacritics below a security risk?<br> </font> </div> <div class="y_msg_container" id="yui_3_16_0_ym19_1_1535587971069_9259"><br><div id="yiv9447630462">
<style><!--
#yiv9447630462
_filtered #yiv9447630462 {font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
_filtered #yiv9447630462 {font-family:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}
_filtered #yiv9447630462 {font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
_filtered #yiv9447630462 {
panose-1:2 1 6 0 3 1 1 1 1 1;}
#yiv9447630462
#yiv9447630462 p.yiv9447630462MsoNormal, #yiv9447630462 li.yiv9447630462MsoNormal, #yiv9447630462 div.yiv9447630462MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri", sans-serif;}
#yiv9447630462 a:link, #yiv9447630462 span.yiv9447630462MsoHyperlink
{
color:#0563C1;
text-decoration:underline;}
#yiv9447630462 a:visited, #yiv9447630462 span.yiv9447630462MsoHyperlinkFollowed
{
color:#954F72;
text-decoration:underline;}
#yiv9447630462 p.yiv9447630462MsoListParagraph, #yiv9447630462 li.yiv9447630462MsoListParagraph, #yiv9447630462 div.yiv9447630462MsoListParagraph
{
margin-right:0in;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri", sans-serif;}
#yiv9447630462 p.yiv9447630462msonormal0, #yiv9447630462 li.yiv9447630462msonormal0, #yiv9447630462 div.yiv9447630462msonormal0
{
margin-right:0in;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri", sans-serif;}
#yiv9447630462 span.yiv9447630462EmailStyle19
{
font-family:"Calibri", sans-serif;
color:windowtext;}
#yiv9447630462 span.yiv9447630462apple-converted-space
{}
#yiv9447630462 .yiv9447630462MsoChpDefault
{
font-size:10.0pt;}
_filtered #yiv9447630462 {
margin:1.0in 1.0in 1.0in 1.0in;}
#yiv9447630462 div.yiv9447630462WordSection1
{}
#yiv9447630462
_filtered #yiv9447630462 {
}
_filtered #yiv9447630462 {
font-family:Symbol;}
_filtered #yiv9447630462 {
font-family:Symbol;}
_filtered #yiv9447630462 {
font-family:Symbol;}
_filtered #yiv9447630462 {
font-family:Symbol;}
_filtered #yiv9447630462 {
font-family:Symbol;}
_filtered #yiv9447630462 {
font-family:Symbol;}
_filtered #yiv9447630462 {
font-family:Symbol;}
_filtered #yiv9447630462 {
font-family:Symbol;}
_filtered #yiv9447630462 {
font-family:Symbol;}
#yiv9447630462 ol
{margin-bottom:0in;}
#yiv9447630462 ul
{margin-bottom:0in;}
--></style>
<div id="yui_3_16_0_ym19_1_1535587971069_9263">
<div class="yiv9447630462WordSection1" id="yui_3_16_0_ym19_1_1535587971069_9262">
<div class="yiv9447630462MsoNormal" id="yui_3_16_0_ym19_1_1535587971069_9261"><span style="font-size:12.0pt;color:black;" id="yui_3_16_0_ym19_1_1535587971069_9260">Interesting input that we should not take lightly and ought to put serious thought on it. A few things to consider:</span></div>
<ul style="margin-top:0in;" id="yui_3_16_0_ym19_1_1535587971069_9265" type="disc">
<li class="yiv9447630462MsoNormal" style="color:black;" id="yui_3_16_0_ym19_1_1535587971069_9264">Let’s be cautious to not over-produce variants due to corner cases. The example below is a second-level domain name and our work is relevant for the top-level. Unlike second-level, the top level
has an extraordinarily high bar for existence (i.e. there needs to be application round in process, there are substantial application fees, technical and financial requirements to run a registry, etc.). Therefore, I find it very unlikely that an entity would
even apply for approval for a top-level label that is visually confusable of another. Even in that event, ICANN has other mechanisms (e.g. String Similarity Review, DNS Stability Review) to stop similar applied-for TLDs from progressing in the application
process. </li><li class="yiv9447630462MsoNormal" style="color:black;" id="yui_3_16_0_ym19_1_1535587971069_9967">Security risk analysis deserves a place in our work, but should first focus on real issues and not hypothetical ones. Do we have examples of this being observed in practice? </li><li class="yiv9447630462MsoNormal" style="color:black;" id="yui_3_16_0_ym19_1_1535587971069_9968">This input deviates from past guidance, so we need to assess the ramifications to our principles of inclusion for in-script and cross-script variants. On this note, I appreciate that any additional
work will delay our submission to IP before our workshop in early October. But I think it is better that we take the time to deliver a quality work.</li></ul>
<div class="yiv9447630462MsoNormal" id="yui_3_16_0_ym19_1_1535587971069_9969"> </div>
<div class="yiv9447630462MsoNormal" id="yui_3_16_0_ym19_1_1535587971069_10065">-Dennis</div>
<div class="yiv9447630462MsoNormal" id="yui_3_16_0_ym19_1_1535587971069_10066"> </div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in;" id="yui_3_16_0_ym19_1_1535587971069_10070">
<div class="yiv9447630462MsoNormal" style="margin-left:.5in;"><b><span style="font-size:12.0pt;color:black;">From:
</span></b><span style="font-size:12.0pt;color:black;">Latingp <latingp-bounces@icann.org> on behalf of Sarmad Hussain <sarmad.hussain@icann.org><br>
<b>Date: </b>Wednesday, August 29, 2018 at 2:58 AM<br>
<b>To: </b>Latin GP <latingp@icann.org><br>
<b>Subject: </b>[EXTERNAL] [Latingp] From IP: Diacritics below a security risk?</span></div>
</div>
<div>
<div class="yiv9447630462MsoNormal" style="margin-left:.5in;"> </div>
</div>
<div class="yiv9447630462MsoNormal" style="margin-left:.5in;">Dear Latin GP members </div>
<div>
<div class="yiv9447630462MsoNormal" style="margin-left:.5in;"> </div>
</div>
<div>
<div class="yiv9447630462MsoNormal" style="margin-left:.5in;">Kindly find below some feedback from IP for your consideration.</div>
</div>
<div>
<div class="yiv9447630462MsoNormal" style="margin-left:.5in;"> </div>
</div>
<div>
<div class="yiv9447630462MsoNormal" style="margin-left:.5in;">Regards </div>
</div>
<div>
<div class="yiv9447630462MsoNormal" style="margin-left:.5in;">Sarmad </div>
<div>
<div class="yiv9447630462MsoNormal" style="margin-left:.5in;"><br>
<br>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt;">
<div>
<div class="yiv9447630462MsoNormal" style="margin-bottom:12.0pt;margin-left:.5in;">
<br>
TO: LatinGP<br>
FROM: IP<br>
<br>
There are recent and widely published examples of phishing attacks using Latin IDNs in which the key features involved were diacritics below the letter. Here is an example:</div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;"><img style="width:4.5625in;min-height:2.9791in;" id="yiv9447630462_x0000_i1028" src="cid:t2iF6VL77HdQs3th5QQ0" yahoo_partid="1.2" alt="cid:part1.E6E9F88C.32B00687@ix.netcom.com" data-id="1e53145f-e126-7cee-fc42-70e7fcc48a0a" width="438" height="286"></span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">Of all diacritics, diacritics below can be difficult to distinguish or be prone to clipping -- there is less space below the baseline than between the typical lowercase glyph and the top
of the line.</span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">The example given above shows a further interaction with URL underlining - and not all display engines actually do as nice a job interrupting the underline as in the screen shot above.
For example, here is how one system will render this (using a designated UI font - Segoe UI):</span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;"><img style="width:1.927in;min-height:.3333in;" id="yiv9447630462_x0000_i1027" src="cid:EYpxLyLUIhFKmqm7JKlI" alt="cid:part2.59964F92.16B1BC0B@ix.netcom.com" data-id="58a17799-f305-9b1d-307e-48dd1f255f49" width="185" height="32"></span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">Note, this code point (U+1E33) is in the MSR as is (U+1E35 LATIN SMALL K WITH LINE BELOW).</span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;"><img style="width:2.052in;min-height:.4895in;" id="yiv9447630462_x0000_i1026" src="cid:uO80ZC4Bkxp04nHQHJet" alt="cid:part3.99B9649E.C3C335FC@ix.netcom.com" data-id="60fc56ee-15fb-c83d-dc7a-09b043b31238" width="197" height="47"></span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">The second example contains U+1E35 -- while the effect does not show equally at all type sizes, from 12pt and below the LINE BELOW is reliably hidden. Here are the two examples at 10pt</span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;"><img style="width:1.052in;min-height:.5833in;" id="yiv9447630462_x0000_i1025" src="cid:HK5o5jTEbD2fRjy43R3L" alt="cid:part4.B43CE3FD.8C84EACF@ix.netcom.com" data-id="361ea8a6-63f4-7bff-fd07-11dc5b20f191" width="101" height="56"></span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">The issue is not limited to "K". We see "B", "D", "L" and "N" with both DOT and LINE BELOW and "M" and "H" with DOT BELOW, all on the same page in the MSR.</span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">It can be argued users have no working understanding of typography and would not reliably interpret small gaps or bulges in the underline as being related to an unfamiliar code point.
This appears to make all diacritics below security-sensitive, however, the initial determination belongs to the relevant GPs.</span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">Note by the way that the Devanagari LGR treats sequences containing NUKTA (a dot below) as variants in at least some cases and recent community comments for that script are calling for
more variant sequences. However, while the feature is graphically analog (dot below), each script works differently and there is no single a-priori solution.</span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">The IP would like to encourage the LatinGP (and any other GP facing cases like this) to explicitly examine this example and other cases like it, where code points can become indistinguishable
in common usage scenarios for IDNs, and formally conclude whether and how to take these into account when designing their LGR.</span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">At this point, the IP would expect the GP to:</span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">* explicitly discuss this and other scenarios like it</span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">* evaluate whether they constitute a security risk to the Root Zone</span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">* come up with a reasoned decision as to whether and how to address them in the design of the Latin GP; and finally</span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">* document both the decision and its rationale.</span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">In coming to a decision, the GP may resolve:</span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">1) to make them variants</span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">2) to list them for attention as confusable</span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">3) to take no action, because the GP feels that they do not represent a special security risk.</span></div>
<div style="margin-left:.5in;"><span style="font-family:sans-serif;">As part of the review of the Latin LGR, the IP will look at the background and rationale offered by the Latin GP in coming to its conclusion; note that if the IP feels that the facts considered
and rationale documented do not support the conclusion reached by the GP it may raise objections at that time.</span></div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>_______________________________________________<br>Latingp mailing list<br><a ymailto="mailto:Latingp@icann.org" href="mailto:Latingp@icann.org">Latingp@icann.org</a><br><a href="https://mm.icann.org/mailman/listinfo/latingp" target="_blank">https://mm.icann.org/mailman/listinfo/latingp</a><br><br><br></div> </div> </div> </div></div></body></html>