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

From: Eric Rescorla <[email-masked]>
Date: Wed, 01 Dec 2004 15:14:53 -0800

Peter,

CAn you live with this?

-Ekr

[email-masked] writes:

> Hi,
>
> If we assume the typical scenario would be that a person enters
> the identifier and PSK in the TLS client (and server), then IMHO
> the current approach (UTF-8 encoding) significantly increases
> the chances for interoperability. It also simplifies actual
> implementations, since they don't have to implement encoding/
> decoding operations for all the different types of identifiers
> people might want to use.
>
> If, on the other hand, the identifiers and keys on both
> endpoints come from some key distribution system (or something),
> and this system actually cares about the type of the identifier
> then using e.g. DER for X.500 DNs might make sense... but I
> think the former case will be much more common (and many systems
> will probably just do strcpy/strcmp for something that a person
> entered somewhere, so UTF-8 will work fine).
>
> This way, we also avoid the need to define what exactly is a
> user name and what is not (not exactly simple if the "user" 
> not a person but a device or a software component), and all
> the interoperability issues this would bring up... so IMHO
> we should keep it as it is.
>
> Best regards,
> Pasi
>
>> -----Original Message-----
>> From: Peter Gutmann
>> Sent: Friday, November 26, 2004 1:17 PM
>> To: [email-masked]
>> Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-03.txt
>> 
>> 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
>

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

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

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 03 Dec 2004 20:04:06 +1300

>CAn you live with this?

It seems to be leaving it as Someone Else's Problem.  I agree that for any
normal/usual scenario the ID is going to be a (text-form) user name, but
requiring that anything that isn't a user name be subject to a non-injective
transformation seems to be asking for trouble.  I could live with having the
handling of user names clearly defined and everything else left open (to be
resolved in future updates if it ever becomes necessary, which I think is
unlikely), but requiring a surjective transformation as the current text does
doesn't seem like a good move.

Peter.