Subject: [TLS] IDNs in draft-ietf-tls-rfc4366-bis

From: Paul Hoffman <[email-masked]>
Date: Thu, 13 Dec 2007 10:59:16 -0800

Greetings again. I agreed to review draft-ietf-tls-rfc4366-bis for 
the possibly-wrong discusion of IDNs in section 3.

Summary: the text is completely broken. It does not follow the way 
that internationalized domain names (IDNs) have been implemented in 
other IETF protocols. A proposed way forward is to vastly simplify it.

Old:
    "HostName" contains the fully qualified DNS hostname of the server,
    as understood by the client. The hostname is represented as a byte
    string using UTF-8 encoding [RFC3629], without a trailing dot.

    If the hostname labels contain only US-ASCII characters, then the
    client MUST ensure that labels are separated only by the byte 0x2E,
    representing the dot character U+002E (requirement 1 in Section 3.1
    of [RFC3490] notwithstanding). If the server needs to match the
    HostName against names that contain non-US-ASCII characters, it MUST
    perform the conversion operation described in Section 4 of [RFC3490],
    treating the HostName as a "query string" (i.e., the AllowUnassigned
    flag MUST be set). Note that IDNA allows labels to be separated by
    any of the Unicode characters U+002E, U+3002, U+FF0E, and U+FF61;
    therefore, servers MUST accept any of these characters as a label
    separator. If the server only needs to match the HostName against
    names containing exclusively ASCII characters, it MUST compare ASCII
    names case-insensitively.

New:
    "HostName" contains the fully qualified DNS hostname of the server,
    as understood by the client. The hostname is represented as a byte
    string using the US-ASCII encoding described as the result
    of the ToASCII function in [RFC3490], without a trailing dot.

Also, Section 11 should be removed; it makes no sense.

--Paul Hoffman, Director
--VPN Consortium

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 13 Dec 2007 22:19:13 +0100

Paul Hoffman <[email-masked]> writes:

> Greetings again. I agreed to review draft-ietf-tls-rfc4366-bis for the
> possibly-wrong discusion of IDNs in section 3.

Did you find out how MSIE/IIS implements this?

> other IETF protocols. A proposed way forward is to vastly simplify it.

Another solution is to transfer the UTF-8 string and do processing on
the receiving side.  This seems to be a more reliable and future proof
approach, given the changes that IDNAbis will bring.

Note that this approach would not necessarily conflict with the deployed
implementations that sends ACE encoded strings, such strings should be
permitted as well.

/Simon

---

From: Martin Rex <[email-masked]>
Date: Thu, 13 Dec 2007 22:11:00 +0100 (MET)

> Did you find out how MSIE/IIS implements this?

Yup, in case they have implemented and shipped this already, then
they might have created an installed base that would be difficult
to ignore.

> implementations that sends ACE encoded strings, such strings should be

I prefer the ACE-only approach suggest by Paul.
(less options, less complexity, less code, less bugs, less interop problems)

At the lower API levels, the IDNs (as provided by user or configuration)
may no longer be available anyway and for TLS.

Isn't the ACE encoding what the client will use to check the
server's endpoint identification (e.g. rfc2818) and what is often
contained in the server's certificate?

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 13 Dec 2007 14:01:52 -0800

>(less options, less complexity, less code, less bugs, less interop problems)

Those seem worthy of our attention.

>contained in the server's certificate?

Exactly right.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 13 Dec 2007 14:01:06 -0800

>Did you find out how MSIE/IIS implements this?

No. Is that relevant? The document is not self-consistent, and it 
would seem likely that interoperability is not possible with the 
current text.

>approach, given the changes that IDNAbis will bring.

Which changes are those? I don't see any that would affect TLS using 
ASCII-encoded DNS names.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 13 Dec 2007 14:01:52 -0800

Exactly right.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 13 Dec 2007 14:01:06 -0800

--Paul Hoffman, Director
--VPN Consortium

---

From: <[email-masked]>
Date: Fri, 14 Dec 2007 10:50:00 +0200

> Did you find out how MSIE/IIS implements this?

I just tested this with IE7 on Vista: it sends the ACE-encoded
string (xn--) in server_name extension (just like Firefox).

So Paul's proposed text seems to be OK in this regard, too.

Best regards,
Pasi