[TLS] RE: Last call comments for draft-santesson-tls-(ume-04, supp-00)

["Stefan Santesson" <[e-mail]>]

Pasi,

Thanks for the good review work.

I agree to all points and requests for changes except for the following
issues/concerns:

4) I would much rather keep the current user mapping hint definition.
Both ways works technically and it is more a matter of taste. The
current hint type form is already implemented in code and thus it would
mean a lot of work for little gain to change it.

5) I do not disagree. We originally had a ref to 1034 but Kurt advised
us that we should refer to 1123. Apparently this was not correct. RFC
3280 makes the same type of reference to 1024 for information contained
in the dNSName subject alt name.

6) For this draft we mean that it should be a domain name according to
the "preferred name syntax" as discussed before. This name form is not
specific to Microsoft. If this is not enough then we could provide some
information in an informational Annex as you suggested.

7) I had the same concerns. I'm not sure whether a document that is
referenced in a SHOULD statements is to be considered informative or
normative. I will align the document with the decision made.


Stefan Santesson
Program Manager, Standards Liaison
Windows Security


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: den 3 april 2006 12:45
> To: Stefan Santesson; [e-mail]
> Cc: [e-mail]
> Subject: Last call comments for draft-santesson-tls-(ume-04,supp-00)
> 
> Some additional last call comments for draft-santesson-tls-ume-04
> and draft-santesson-tls-supp-00:
> 
> 1) The IANA considerations sections in both documents are
>    incomplete (missing the requests to assign new numbers),
>    in some details correct (number ranges overlap), and unclear.
>    Here's a proposal for better text:
> 
>    draft-santesson-tls-supp:
> 
>    This document defines a new TLS handshake message,
>    "supplemental_data", assigned a value of TBD-BY-IANA from the TLS
>    HandshakeType registry defined in [RFC4346].
> 
>    This document establishes a new registry, to be maintained by IANA,
>    for TLS Supplemental Data Types.  Initially, the registry is empty.
>    Values from the range 0-16385 are assigned via Standards Action
>    [RFC2434].  Values from the range 16386-65279 are assigned via
>    Specification Required [RFC2434].  Values from the range
>    65280-65535 are reserved for Private Use [RFC2434].
> 
>    draft-santesson-tls-ume:
> 
>    This document defines a new TLS extension, "user_mapping", assigned
>    a value of TBD-BY-IANA1 from the TLS Extension Type registry
>    defined in [RFC4366].
> 
>    This document defines a new TLS supplemental data type,
>    "user_mapping_data", assigned a value of TBD-BY-IANA2 from the TLS
>    Supplemental Data Type registry defined in
>    [draft-santesson-tls-supp].
> 
>    This document establish a new registry, to be maintained by IANA,
>    for TLS User Mapping Types. Initially, the registry contains one
>    entry: upn_domain_hint (0). Values from the range 1-63 are assigned
>    via Standards Action [RFC2434].  Values from the range 64-223 are
>    assigned via Specification Required [RFC2434]. Values from the
>    range 224-255 are reserved for Private Use [RFC2434].
> 
> 2) tls-ume, Section 5: "The client SHOULD only send the
>    UserMappingDataList in the supplemental data message if it is
>    agreed upon in the hello message exchange"
> 
>    This is wrong (and violates a "MUST" in tls-supp): the user
>    mapping data list MUST NOT be sent if it was not agreed in the
>    ClientHello/ServerHello exchange.
> 
> 3) Security considerations in both documents should explicitly
>    point out that the information is not encrypted (and thus visible
>    to eavesdroppers), and is sent before the peer is authenticated
>    (unless the "double-handshake" trick is used). This may be obvious
>    to the authors, but not to everyone reading these documents...
> 
> 4) tls-ume: Would it make sense to define two UserMappingData types,
>    one for "user@domain" and another one for just "domain", instead
>    of combining them in one type?
> 
> 5) tls-ume, Section 3: ".. contain a domain name in the "preferred
>    name syntax," as specified by RFC 1123". RFC 1123 never even
mentions
>    the term "preferred name syntax" (it is mentioned in RFC 1034,
>    though).
> 
> 6) tls-ume: The document should contain at least an informative
>    reference to a document describing what this Microsoft UPN is.
>    Simply saying it's of the form "user@domain" is not very helpful.
>    For instance, does "domain" mean it's a DNS name? (Windows uses
>    the word "domain" also for names that don't have anything to
>    do with DNS). Is the domain part an IDN-aware or IDN-unaware
>    domain name slot? (Or neither?) Are some special characters
>    (e.g., punctuation, at sign) in the "user" part forbidden,
>    or escaped/encoded somehow specially?
> 
> 7) References in tls-ume: IMHO references N7,N8,N9 seem more
>    Informative than Normative. Reference N5 is never cited in text.
>    RFC 1123 is cited in the text, but not included in reference list.
> 
> Best regards,
> Pasi

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