[Gnso-ssr] Broken TMCH?

[Patrik Fältström]

On 2014-02-21 07:55, Kal Feher wrote:
> Comments in line.
>
> KF - point taken, but vague assertions to dire consequences in any
> stakeholder forum are of little use to the community and should be
> discouraged.

Once again, if comments are taken out of context, they will be out of
context. So that the assertions are vague I blame whoever did copy the
subset of the discussion (that also was via voice, not only text).

> KF - Frustration at a lack of progress should not automatically
> translate to advice not to adhere to your Registry Agreement. I think
> some perspective is required.

There have not been any such advice that I know of.

> Please see the SSAC report.
>
> KF - I reiterate that it is generic and lacking any actual detail,
> especially with regards to security or stability issues. There's a
> suggestion (recommendation 10) to clarify roles, which is certainly a
> good idea, but hardly catastrophic if not implemented and has little
> value in preventing homographic attacks.

A clarification of the roles now exists.

The Registry Agreement (RPM Requirements) says that registries must
check all names in a variant set during the TM Claims period.

This is _not_ updated in the scorecard.

> KF - I think the TMCH should certainly be improved, I have a list of
> gripes that would keep IBM busy for years, but we should be clear
> about risks and impact. I see plenty situations in which TMCH clients
> will not receive the result they expect. But there doesn't appear to
> be any security or stability risks that can be coherently described.
> Certainly none in the report.

SSAC has as a role do detect stability risks which include cases where
the functionality of a system is not according to the claims.

TMCH is well defined for the latin script, but not for non-latin
scripts. Specifically when you have cases where different LGR is used
for the same script in two different TLDs.

Now, whether we will get different LGR for different TLDs is something
only the integration panel can say anything about.

> The SSAC document point out that the matching rules used in the TMCH
> are not the same as the combination of matching rules plus variant
> rules, specifically for non-ascii scripts.
> 
> KF - Irrelevant. Homographic attacks require an actual registration.
> Either a registry's LGR's prevent it or they don't. for the TMCH it is
> more a failure of user expectations, which should not be conflated with
> an attack. It is important, but should be addressed separately.

SSAC disagree with this conclusion of yours. But it is perfectly ok of
course for you to draw the conclusion that you do not think the issues
with IDN and variants in TMCH is a problem. That is your choice.

SSAC do think it is a problem that the TMCH does not have any well
defined rules for non-latin script. YMMV.

> KF - What of the registries that should be EBERO'd? If true it is of
> serious concern, if not true we really need to tone down the hyperbole.

The EBERO is an issue separate from TMCH and the question was whether a
zone that is not signed correctly is according to the EBERO
specification "broken" in such a way that EBERO can be invoked.

That question is not answered and not clear in the EBERO specification
or elsewhere. It would be sad if it is the case it will only be resolved
in court or arbitration when a real case is on the table.

  Patrik



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 291 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/gnso-ssr/attachments/20140221/463317da/signature-0001.asc>