gnutls_server_name_set and IDN

[Daniel Black-5]

Should gnutls_server_name_set convert the domain name to ACE as per
RFC4366 3.1 where it talks about IDNA (RFC 3490)?

Using libidn function call can make this occur using idna_to_ascii_8z can
make this happen though this is adding dependency.



_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

Daniel Black <daniel@...> writes:

> Should gnutls_server_name_set convert the domain name to ACE as per
> RFC4366 3.1 where it talks about IDNA (RFC 3490)?
>
> Using libidn function call can make this occur using idna_to_ascii_8z can
> make this happen though this is adding dependency.

That text has been dropped from RFC 4366bis:

http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-05#section-3

I think the text in RFC 4366 is confusing and difficult to implement
interoperably.

What the new text means is that GnuTLS applications are responsible for
converting any internationalized domain name into ACE before passing the
string on to GnuTLS.

Let me know what you think of this, there is still time to bring this up
in the IETF.

/Simon


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Daniel Black-5]

On Wednesday 23 September 2009 18:57:28 Simon Josefsson wrote:

> Daniel Black <daniel@...> writes:
> > Should gnutls_server_name_set convert the domain name to ACE as per
> > RFC4366 3.1 where it talks about IDNA (RFC 3490)?
> >
> > Using libidn function call can make this occur using idna_to_ascii_8z can
> > make this happen though this is adding dependency.
>
> That text has been dropped from RFC 4366bis:
>
> http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-05#section-3
>
> I think the text in RFC 4366 is confusing and difficult to implement
> interoperably.

definitely. Its rewrite is clearer. It did take me a bit to realise that ASCII
was only 0-7F and not the same as UTF-8.

> What the new text means is that GnuTLS applications are responsible for
> converting any internationalized domain name into ACE before passing the
> string on to GnuTLS.

Ok. Some really clear text in the documentation about this would be good. As
the UTF-8/ ASCII error may be common is it beneficial to validate this input to
check for >7F characters?

Attached patch clarifies the gnutls_server_name_set function input. I'm not
sure a UTF-8 -> ASCII replacement on gnutls_server_name_get is entirely true
however some additional clarification here would be good.

> Let me know what you think of this, there is still time to bring this up
> in the IETF.

Its clarify also simplifies it to the point that their is no mention of IDNA as
an appropriate mechanism to convert encodings to ASCII. Was this intentional?
I'm of the opinion, until abused otherwise, that appending "UTF-8 and other
character sets can be converted to ASCII using the ToASCII function defined in
RFC3490 section 4." (or similar) to the "HostName" definition paragraph.

also maybe 6.1. could say, in response to the last bit of 3.1, + "Server
applications SHOULD validate server_name against any application layer
equivalent field."

Thanks Simon

[gnutls_server_name_set-docfix.patch]

---

diff --git a/lib/ext_server_name.c b/lib/ext_server_name.c
index f9ca429..610aaf5 100644
--- a/lib/ext_server_name.c
+++ b/lib/ext_server_name.c
@@ -290,7 +290,7 @@ gnutls_server_name_get (gnutls_session_t session, void *data,
   * to servers that do virtual hosting.
   *
   * The value of @name depends on the @ind type. In case of GNUTLS_NAME_DNS,
-  * an ASCII or UTF-8 null terminated string, without the trailing dot, is expected.
+  * an ASCII null terminated string, without the trailing dot, is expected.
   * IPv4 or IPv6 addresses are not permitted.
   *
   **/

---

_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

Daniel Black <daniel@...> writes:

>> What the new text means is that GnuTLS applications are responsible for
>> converting any internationalized domain name into ACE before passing the
>> string on to GnuTLS.
>
> Ok. Some really clear text in the documentation about this would be
> good.

Improved now, thanks, see:

http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=17edc60deccccfd93a1290e27f8643b68a6c2dda

> As the UTF-8/ ASCII error may be common is it beneficial to validate
> this input to check for >7F characters?

Hm, yes, maybe -- although it would prevents usage against some server
that for some reason used a non-ASCII string there.  RFC 4366 can be
read to say that non-ASCII strings are OK, and not being able to interop
against such a server just because of a input sanitation code seems
overkill.  But it is a tradeoff and I don't feel strongly about it.

>> Let me know what you think of this, there is still time to bring this up
>> in the IETF.
>
> Its clarify also simplifies it to the point that their is no mention
> of IDNA as an appropriate mechanism to convert encodings to ASCII. Was
> this intentional?

Yes I think/hope so -- not mentioning IDNA specifically avoids
inheriting the problems associated with it: support of non-ASCII
hostnames then becomes entirely the IDNA specifications' problem.

> I'm of the opinion, until abused otherwise, that appending "UTF-8 and
> other character sets can be converted to ASCII using the ToASCII
> function defined in RFC3490 section 4." (or similar) to the "HostName"
> definition paragraph.

IDNAbis is in WGLC now, so any such reference would be obsolete soon.
Given that IDNAbis is completely different (both in design and
implementation) compared to RFC 3490 I think a specific reference would
only confuse more than it would help.  Then implementers will ask
whether the intention is that TLS SNI is only to be used with IDNA and
not IDNAbis.

> also maybe 6.1. could say, in response to the last bit of 3.1, + "Server
> applications SHOULD validate server_name against any application layer
> equivalent field."

That makes sense to me.  I'll forward that to the TLS list.

/Simon


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Daniel Black-5]

On Thursday 24 September 2009 01:59:05 you wrote:
> Improved now, thanks, see:
>
> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=17edc60deccccfd93a12
> 90e27f8643b68a6c2dda

thank you. I'm assuming no mention of ACE because of reasons below.

>
> > As the UTF-8/ ASCII error may be common is it beneficial to validate
> > this input to check for >7F characters?
>
> ....not being able to interop
> against such a server just because of a input sanitation code seems
> overkill.
ack.

I assume people are passing UTF-8 to the socket connect method and then
passing the same string to gnutls_server_name_set (IP or not). Which reminds
me I need to find and IP address or not method out of socket structures.

> > Its clarify also simplifies it to the point that their is no mention
> > of IDNA as an appropriate mechanism to convert encodings to ASCII. Was
> > this intentional?
>
> Yes I think/hope so -- not mentioning IDNA specifically avoids
> inheriting the problems associated with it: support of non-ASCII
> hostnames then becomes entirely the IDNA specifications' problem.

it totally leaves the implementer in the dark find that spec though. I guess
once its approved, provide documentation on gnutls and see what happens.

> IDNAbis is in WGLC now, so any such reference would be obsolete soon....Then
implementers will ask whether the intention is that TLS SNI is only to be used
with IDNA and not IDNAbis.
yep agree.

> "Server applications SHOULD validate server_name against any ...
>
> That makes sense to me.  I'll forward that to the TLS list.
Thanks


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel

[Simon Josefsson-2]

Daniel Black <daniel@...> writes:

> On Thursday 24 September 2009 01:59:05 you wrote:
>> Improved now, thanks, see:
>>
>> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=17edc60deccccfd93a12
>> 90e27f8643b68a6c2dda
>
> thank you. I'm assuming no mention of ACE because of reasons below.

Right.

>> > As the UTF-8/ ASCII error may be common is it beneficial to validate
>> > this input to check for >7F characters?
>>
>> ....not being able to interop
>> against such a server just because of a input sanitation code seems
>> overkill.
> ack.
>
> I assume people are passing UTF-8 to the socket connect method and then
> passing the same string to gnutls_server_name_set (IP or not). Which reminds
> me I need to find and IP address or not method out of socket structures.

Yes.

>> > Its clarify also simplifies it to the point that their is no mention
>> > of IDNA as an appropriate mechanism to convert encodings to ASCII. Was
>> > this intentional?
>>
>> Yes I think/hope so -- not mentioning IDNA specifically avoids
>> inheriting the problems associated with it: support of non-ASCII
>> hostnames then becomes entirely the IDNA specifications' problem.
>
> it totally leaves the implementer in the dark find that spec though. I guess
> once its approved, provide documentation on gnutls and see what happens.

Yes I think that is better.  IDNA has implications for all protocols
that use domain names, and referencing IDNA from everywhere does not
necessarily improve anything.

/Simon


_______________________________________________
Gnutls-devel mailing list
Gnutls-devel@...
http://lists.gnu.org/mailman/listinfo/gnutls-devel