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

[Marsh Ray <[e-mail]>]

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.

> 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.

If I got a positive response back from DNS, then began handshaking TLS
with that server only find a certificate mismatch with some other
server, I would be surprised.

If I successfully completed a handshake with the wrong server which
presented a wildcard cert that happened to also be valid for the server
I requested, I would be even more surprised.

But hey, that's just me, reasonable people see things differently. :-)

> 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.

Protocols and sites that do want to deploy some kind of useful "default
TLS server" seem like the kind of case that "RECOMMENDED" and "SHOULD"
already allow for: "valid reasons in particular circumstances to ignore
a particular item, but the full implications must be understood and
carefully weighed before choosing a different course".

> 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.

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.

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"?

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

- Marsh