On Fri, Nov 07, 2014 at 10:48:47AM -0500, Wietse Venema wrote: > Example: merging existing submission servers mail.example.com and > mail.example.net. Why require that the administrator acquire a new > combined certificate? Why require that the administrator acquire > multiple IP addresses? Why require that users change their mail > client (to use a non-standard port etc.)?
Indeed this is a sensible use-case for server-side SNI. Sadly MUAs get very little attention from vendors, there's simply no money in shipping a better MUA these days. Otherwise, we might have seen some adoption of https://tools.ietf.org/html/rfc6186 with the burden of configuring the submission service for a domain reduced substantially and the SNI issue partly resolved along the way. Apart from MUAs being abandonware, the other obstacle is that a secure implementation of http://tools.ietf.org/html/rfc6186 really needs a secure DNS + DANE, this can be somewhat hidden by doing SRV lookups only when creating a mail account and caching the data indefinitely until the user decides to re-discover his submission service. With prompts for the user to confirm any initial or changed settings. So yes, we should do server-side SNI, but I'd prefer to wait another year if I may. FWIW SNI is UTF-8 on the wire, so there would potentially need to be code to deal with that. Including Unicode variants of the "." separating labels and support for unassigned code points (the SNI name is a "query" string), ... https://tools.ietf.org/html/rfc3490#section-3.1 https://tools.ietf.org/html/rfc4366#section-3.1 If the SNI name happens to be in A-label form, we'd have to canonicalize it to UTF-8 before looking for the corresponding keys. There's a bunch of subtle issues here. -- Viktor.
