Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> 
> Martin Rex wrote:
> > 
> > TLS does not need to know anything about DNS (server) names involved
> > in a communication.  That is, and has always been, clearly specified
> > by all versions of TLS to be entirely an application matter.
> 
> There is never a clear line you can draw between one layer and another,
> such that no TLS layer will ever reach higher toward an application, or
> that no application will reach lower toward the TLS layer.

The architecture has very clear lines.

Where there is often a less clear line in in software modularization.
The latter is not necessarily a problem.  But the software modularization
should be perfectly clear of whether something is a core protocol function
or a helper/convenience function for the application to facilitate the
applications part of the job.

> 
> In my TLS code, there is a simple configuration scheme that applications
> use to tell the TLS layer which domain names map to which certificate
> chains.

That sounds fine to me.  You're saying that applications tell the TLS layer
which domain names map to which certificate chains/credentials.
That is just what I've been asking for.

Whether the credentail selection during the handshake is performed
through application-supplied preconfiguration involving helper/convenience
functions (that might be supplied by the TLS implementation), or through
some callback entirely within the server application code in an
implementation detail.


>
> Once set up, the application doesn't need to do anything more
> since the TLS code then handles certificate selection based on the SNI,
> version, cipher suite, supported signature algorithms, and key usage.
> It's quite complicated.

I don't think it is complicated.

The application supplies credentials and provides the necessary
information or guidance how to map client-supplied server_name
values to server credentials.  The server TLS implementation
needs to ensure that the credential can be used with the other
cryptographic parameters in ClientHello.  If there is more than
one credential available, more than one may match the selection
criteria, so there usually is a server-side preference order for
the server credentials.


> 
> You might condemn this as some sort of layering violation, but it really
> does make life easier for application writers.  I wrote the code once
> instead of requiring every application writer to have to reinvent it.

What you describe does not look like a layering violation to me.

In principle, it should be possible to implement SNI in TLS in a fashion
so that applications can invent and use new server_name types without
any changes to the TLS implementation.


-Martin