Subject: RE: [TLS] WG Last Call for draft-ietf-tls-psk-02.txt

From: [email-masked]
Date: Thu, 21 Oct 2004 12:52:12 +0300

Nikos Mavrogiannopoulos writes:
> >
> > I'm not totally convinced about the usefulness of the RSA_PSK
> > ciphersuites myself (but certainly if you don't want to use
> > them, you don't have to implement them :-). Any opinions
> > from other WG members?
>
> Certainly but my point also is, if certificate authenticated 
> RSA ciphersuites are added, then why the DHE_RSA/DHE_DSS are
> not added as well? A server with a DSS only certificate can 
> only use DHE_DSS, so is not entitled to use certificate 
> authenticated PSK. 

Simply to avoid unnecessary complexity: if there's real need for
those, they can always be defined in a separate document later.
(The document does not have DH_DSS_PSK, DH_RSA_PSK,
ECDH_ECDSA_PSK, ECDHE_ECDSA_PSK, ECDH_RSA_PSK, ECDHE_RSA_PSK, 
or ECDHE_PSK versions either :-)

> > Note that there are many types of identifiers that are not
> > naturally composed of Unicode characters (e.g., IPv4/v6
> > addresses, IEEE 802 MAC addresses, X.500 Distinguished Names,
> > even DNS names). 
>
> Maybe tagging it would help then. So clients and servers can use 
> the tags to distinguish data in that field. Otherwise there is no 
> way to support all of these schemes, and we end up with clients 
> and servers that use X.509 DN, and others that use IP addresses, 
> and others that use just UTF-8, and no interoperation between 
> them is possible.

There's no way around that problem, though: if one end sends an 
X.500 DN and other end expects an IP address, it doesn't matter 
whether that's tagged or UTF-8 encoded.

The situations we'd like to avoid are (1) both ends are using,
e.g., Distinguished Names, but encode them in a different way, 
or (2) an implementation does not allow an administrator to 
enter the identifier the other end is expecting. 

Adding a "type tag" would most likely only make the situation 
worse and increase complexity. But your first proposal 
(mandating UTF-8 encoded character strings) would seem
to handle both situations quite nicely.

Given this, I propose changing this:

  "This document does not specify the format of the PSK identity
   or PSK identity hint; neither is specified how exactly the
   client uses the hint (if it uses it at all).  The parties
   have to agree on the identities when the shared secret is
   configured (however, see Section 6 for related security
   considerations).  In situations where the identity is entered
   by a person, it is RECOMMENDED that the input is processed
   using an appropriate stringprep [9] profile and encoded in
   octets using UTF-8 encoding [14].  One possible stringprep
   profile is described in [8]."

To this:

  "It is expected that different types of identities are useful
   for different applications running over TLS. This document
   does not therefore mandate the use of any particular type of
   identity (such as IPv4 address or FQDN) or identity hint;
   neither is specified how exactly the client uses the hint 
   (if it uses it at all).

   To increase the chances for succesful interoperation between
   applications that do agree on what type of identity is used,
   the identity MUST be first converted to a character string, 
   and then encoded to octets using UTF-8 [UTF8]. For instance,

   o  IPv4 addresses are sent as dotted-decimal strings
      (e.g., "192.0.1.2"), not as 32-bit integers in 
      network byte order.

   o  Domain names are sent in their usual text form (e.g.,
      "www.example.com" or "embedded\.dot.example.net"),
      not in DNS protocol wire format.

   o  X.500 Distinguished Names are sent in their string
      representation [draft-ietf-ldapbis-dn-14], not as
      BER-encoded ASN.1.

   In situations where the identity is entered by a person,
   processing the character string with an appropriate 
   stringprep [9] profile is RECOMMENDED."

Would this be more acceptable?

Best regards,
Pasi

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