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

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> On 6/9/2010 1:13 PM, Martin Rex wrote:
> > 
> > And even when DH_anon cipher suites are used, there certainly is a 
> > "credential" involved, it just is not associated with any name.
> 
> Guess I thought of it as unauthenticated key agreement without use of
> credentials.

A simple DH exchange could be called an "unauthenticated key agreement".

A TLS handshake with a DH_anon ciphersuite is somewhat different.
The purpose of the protected communication channel is that you
can exchange a lot of information and be sure that you are still
talking to the same peer and not arbitrarily changing different
peers.  Technically, you could even store a TLS session that uses
a DH_anon cipher suite in the TLS session cache and resume it
later.  You couldn't do that if there weren't credentials involved.
Only that these credentials do not identify anyone in particular.


> 
> > Personally, I would be fine with RECOMMENDing that the server should 
> > behave as if it did not receive the extension all in the case that it
> > does not recognize the server_name.  Doing this improves robustness 
> > (principle of least surprises).  But I don't know how others feel 
> > about this.
> 
> If my web browser asked my ISP-provided DNS resolver for a missing
> hostname and instead got some default webserver with advertising pages,
> I would be irritated, but not surprised.

SNI is _not_ a naming service.  It is not even a part of TLS itself.
SNI is a hint for the server application created by the client application
and conveyed through a TLS extension.

RFC-5246 is pretty clear about this (last sentence of section 1):

   the decisions on [...] how to interpret the authentication certificates
   exchanged are left to the judgment of the designers and implementors
   of protocols that run on top of TLS. 

So a TLS server implementation that makes bold assumptions about what
fancy things it should do with the server_name in an incoming ClientHello
is obviously broken.  This is an application-level issue, and a TLS
server application should not do anything unless explicitly instructed
to do so by the calling application.  A TLS server implementation that
attempts to be "smart" without being directed by the server application
is violating the TLS spec and can easily cause needless interop problems.


>
> > However, when the server decides to continue the handshake then it 
> > wouldn't be very helpful if the client chokes on a warning-level 
> > alert unrecognized_name(112) and aborts the handshake.
> 
> Keep in mind that this scenario is only likely to occur as a result of
> some other screwup (e.g., DNS or server misconfiguration). Unless
> there's common usage I'm not aware of the possibililty of any
> "successful" outcome from this handshake seems pretty small.

It would be a pretty bad idea for a server to abort a handshake
based on a mismatch of the server_name in an SNI extension of the
ClientHello if the server would continue the handshake when there
had not been any SNI extension in ClientHello.  Such server are just
going to cause extra headaches and support nightmares.

A mismatch of the SNI server_name value does not impair the security
of the TLS handshake and the server endpoint identification in any way,
unless the client TLS or client app is defective.

And the exact relationship of the server_name used by the client
and the interpretation of the certificate of the server is a
specified to be purely a matter of the application protocol
on top of TLS.


> 
> > A TLS client implementation that aborts receiving a warning-level
> > unrecognized_name(112) alert is defective. It is the duty of the
> > client application to determine whether to abort the handshake
> > (and/or communication) when the server endpoint identification
> > fails.
> 
> The application code may in fact be implementing that behavior, or it
> may have chosen to delegate that decision to the TLS implementation.

A client application that abort on receipt of a warning-level
unrecognized_name(112) alert instead of a failure of the server
endpoint identification would be just as defective as a TLS client
implementation doing this.


> 
> The point of a warning is to inform the endpoint of a potentially
> significant situation so that he can make an informed decision about
> whether or not to continue.

As I previously indicated, there _is_ no significant situation that
such a warning-level alert could convey.  It may be helpful for
human users, operators or helpdesk personal to know that a such
a warning had been sent by the server when the handshake does not
complete successfully.

The only thing that the client application needs to do and get
right is the server endpoint identification, and that is completely
independent of whether it sends an extension SNI and whether the
server supports or ignores SNI.


> 
> This sounds a bit self-contradictory to me:
> > [...] the client's behavior in response to warning-level alerts is
> > unpredictable. If there is a mismatch between the server name used by
> > the client application and the server name of the credential chosen
> > by the server, this mismatch will become apparent when the client
> > application performs the server endpoint identification, at which
> > point the client application will have to decide whether to proceed
> > with the communication.
> 
> On one hand we're saying we can't use a proper warning here because the
> client might decide to abort. On the other we're hoping the server
> presents the client with a bad cert so he can "decide whether to proceed"?

It describes the fact that there are defective clients in the installed
base that will choke on receiving warning-level alert.

There is a lot of software out there broken in all kinds of ways,
and there is little value in sending data, data that is unnecessary,
just because the original spec said it could be sent, if one is aware
that it will result in interop problems with a non-negligable part of
the (defective) installed base.


> 
> Note that the early abort in this situation probably avoids a lot of
> wasted crypto math and could conceivably prevent an inadvertent DoS.

Such broken client behaviour is completely irrelevant to the determined
attacker.  So you would like the "misconfigured" client in a tight
deadly embrace to deplete sockets and increase network traffic and
inflate network traffic logs rather then becoming a CPU-bound resource hog?  

I am not sure that I would prefer one over the other.  But I would
expect that a "nice" client is more likely to end a deadly embrace
due to a failed server endpoint identification than to some weird
new SSL Alert which didn't even exist when the client app was
written and which started coming up when the lastes SSL patch
was installed...


-Martin