Re: [TLS] 4366bis TLSext SNI -- case-sensitivity, permitted chars

This looks like an oversight in the new text.  Just to clarify the suggestion is to add the following as a new paragraph after the paragraph ending "... use of A-labels defined in [RFC5890]."

 " DNS hostnames are case-insensitive.  The algorithm to compare
  hostnames is described in [RFC5890] Section 2.3.2.4."

Thanks,

Joe

On Nov 18, 2010, at 12:37 PM, Martin Rex wrote:"

> Geoffrey Keating wrote:
>> 
>> Martin Rex <mrex@sap.com> writes:
>> 
>>> Looking at the OpenSSL diffs for CVE-2010-3864 and crosschecking with
>>> rfc4366 and rfc4366bis I noticed that some text was removed or lost
>>> from the description of the Server Name Indication extension
>>> for rfc4366->rfc4366bis.
>>> 
>>> 
>>> The IMHO most important part that was lost is:
>>> 
>>>    "MUST compare ... case-insensitively."
>>> 
>>> and OpenSSL appears to perform a case-sensitive match (strncmp) only.
>> ...
>>> New text is:
>>> https://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-12#page-8
>>> 
>>>  "HostName" contains the fully qualified DNS hostname of the server,
>>>   as understood by the client. The hostname is represented as a byte
>>>   string using ASCII encoding without a trailing dot. This allows the
>>>   support of internationalized domain names through the use of A-labels
>>>   defined in [RFC5890].
>>> 
>>>   Literal IPv4 and IPv6 addresses are not permitted in "HostName".
>> 
>> Perhaps we could insert this between the two paragraphs quoted:
>> 
>>  The DNS hostname is to be compared in a case-insensitive manner but
>>  case should be preserved, as described in [RFC1035].
>> 
>> (The RFC 1035 reference is so that we don't have to explain what
>> 'case-insensitive' means.)
> 
> Considering the new Reference to [RFC5890], pointing to Section 2.3.2.4
> of that document might be more appropriate.
> 
> https://tools.ietf.org/html/rfc5890#section-2.3.2.4
> 
> So something like
> 
>   DNS hostnames are case-insensitive.  The algorithm to compare
>   hostnames is described in [RFC5890] Section 2.3.2.4.
> 
> might be more consistent.
> 
> -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls