Hi Daniel,

> Yes, I agree with that interpretation. Here's the paragraph from RFC3546:
>
> "HostName" contains the fully qualified DNS hostname of the server,
> as understood by the client. The hostname is represented as a byte
> string using UTF-8 encoding [UTF8], without a trailing dot.

exactly, this was the paragraph I was thinking about (and even cited in
my first mail about this issue).

> You interested in taking a shot at a patch for this problem? It seems like
> it may be a good idea to simply normalize (strip trailing dots) at a central
> early point in time.

While I agree with the idea of normalizing the domain name as a first
step, we need to take the higher level protocols into consideration.
Every protocol on top of TLS can cause problems. Considering HTTP let us
look into RFC 2616 section 3.2.2 [0]:

   If a proxy receives a host name which is not a fully qualified domain name,
   it MAY add its domain to the host name it received. If a proxy receives a
   fully qualified domain name, the proxy MUST NOT change the host name.

I am not exactly sure how the interplay between proxies and HTTP(S)
traffic is specified but my point is that the hostname (the user
supplied to the application) must not be modified when it travels up the
layers. When we provide the URL 'https://www.google.com.' the TLS layer
needs to do its normalization (as required per RFC 3556) and send out
'www.google.com' in the SNI part of the communication, however on the
HTTP layer is has to stay the same. Even worse, a proxy would be allowed
to modify it like adding the search domain (resulting in a HTTP hostname
like 'www.google.com.local.') if the domain was not fully qualified.
I have not checked the RFCs of IMAP and SMTP yet, but probably similar
observations can be made. Hence the normalization would be less central
but more very specific to SNI.

Since I am not too familiar with the standards and implementations I
could be wrong. The proxy case might not be relevant in the context of
TLS, since it should never be able to modify the tunneled content.
However some companies use transparent proxies which also decrypt
outgoing traffic basically playing MITM all day (since all the clients
have a custom root CA installed), but then again the RFC was probably
not refering to this scenario. The host name in HTTP is also relevant
for HTTP cookies even higher up the layer stack.

This corners of the web stack lack some specification coverage, so we
should probably decide what would be best to fill the gaps.

Regards,
Leon

[0] http://tools.ietf.org/html/rfc2616#section-3.2.2
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-04-28