Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-03.txt

From: [email-masked] (Peter Gutmann)
Date: Sat, 27 Nov 2004 00:16:39 +1300

I've just been going through the -03 draft and I'm not sure whether the new
requirements for encoding the identity are such a good idea.  The older -02
had "UTF-8 everything" which admittedly was a bit ambiguous, but I think the
current requirement to convert things that aren't normally UTF-8 into UTF-8
will cause more interop problems than it solves, because some of the IDs that
could potentially be used have ambiguous encodings in text form.  The obvious
example is X.500 DNs, not only because (even in a perfect world) there are a
pile of sematically equivalent forms that can't be easily compared with a
strcmp(), but also because we're in an imperfect world where people put
latin-1 into T61Strings that can't be reliably turned into UTF-8 and have
multi-AVA RDNs for which some implementations will only see the first AVA and
not the others, and a pile of other things.  Having to implement X.500
en/decoding and string comparison rules in a TLS implementation is probably
asking a bit much.

IPv6 has somewhat similar problems, there are several ways to represent an
address, so you'd need to add complex en/decode/comparison logic to your code
to handle this.

To resolve this, I think it's necessary to at least provide information on a
couple of common ID types and their encodings, e.g:

  User names (where the user may be a human or a device, and which usually
  correspond to account names on the server being connected to) are encoded as
  a UTF-8 character string, without any terminating null character.

  IPv4 and IPv6 addresses are encoded as 32-bit and 128-bit integers in
  network byte order.

  URIs are encoded as specified in [RFC2616].

  Domain names are encoded as specified in [whatever the ref is]

  X.500 DNs are encoded as DER-encoded ASN.1 as it appears in the certificate
  or other object from which it's referenced.

Having said that, I'm not sure at the moment why you'd need something other
than a straight user name.  For example, I can't see why I'd be connecting to
a server and identifying myself as an IP address (I can certainly dream up an
imaginary scenario if given a few minutes, but I can't think of any real-world
situation where I'd need the ability to do this).  So another option would be
to leave everything but the user name unspecified and see if anyone ever needs
any of the other options, and if so how they want to handle them.

Peter.

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 30 Nov 2004 00:54:46 +0100

On Friday 26 November 2004 12:16, Peter Gutmann wrote:

> had "UTF-8 everything" which admittedly was a bit ambiguous, but I think
> the current requirement to convert things that aren't normally UTF-8 into
> UTF-8 will cause more interop problems than it solves, because some of the
> IDs that could potentially be used have ambiguous encodings in text form. 
> The obvious example is X.500 DNs, not only because (even in a perfect
> world) there are a pile of sematically equivalent forms that can't be
> easily compared with a strcmp(), but also because we're in an imperfect
> world where people put latin-1 into T61Strings that can't be reliably
> turned into UTF-8 and have multi-AVA RDNs for which some implementations
> will only see the first AVA and not the others, and a pile of other things.
>  Having to implement X.500 en/decoding and string comparison rules in a TLS
> implementation is probably asking a bit much.
[...]
> To resolve this, I think it's necessary to at least provide information on
> a couple of common ID types and their encodings, e.g:
>   correspond to account names on the server being connected to) are encoded
> as a UTF-8 character string, without any terminating null character.

If you do this then you have to include a tag to indicate the type. Otherwise 
you cannot tell whether the data there are a UTF-8 username or an IP address.

-- 
Nikos Mavrogiannopoulos

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 30 Nov 2004 23:21:45 +1300

>you cannot tell whether the data there are a UTF-8 username or an IP address.

Why would it matter?  All you're doing is comparing (or looking up) a client-
supplied { value, length } against a stored { value, length }.

Peter.