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

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 2 Jun 2010 22:22:32 -0700

It seems that the behavior is dependent upon the application.  I'm not
sure we would come up with useful text here.  In the interest of getting
this document published I suggest we leave it as is.  

Joe

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael D'Errico
> Sent: Tuesday, May 25, 2010 10:58 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
> 
> Martin Rex wrote:
> > Michael D'Errico wrote:
> >> In my server code, the SNI is checked to see if there is a matching
> >> virtual host with that domain name.  If there is, then no alert is
> >> sent.  If there is no matching virtual host, then it checks whether
> >> there is a default virtual host set up.  If there is a default,
then
> >> an unrecognized_name alert is sent with the warning level.  When no
> >> default is configured, the alert sent is fatal since the handshake
> >> can not continue.
> >>
> >> The warning lets the client know that there was not a match, but
> that
> >> the server can still continue using its default.
> >
> >
> > While this behaviour appears quite sensible/plausible, it will lead
> > to the behaviour in the wild that Yngve is reporting.
> >
> > An application which
> > does not configure any SNI characteristics, is not using SNI, and
> > for these, the server TLS implementation should _NOT_ be sending
> > SNI mismatch TLS alerts unless the application explicitly requests
> so.
> 
> My server code will not send an alert unless the client (a) sent an
> SNI and (b) that SNI did not map to a virtual host.
> 
> So that should not cause a problem.
> 
> It might be a good idea to clarify when sending an unrecognized_name
> alert would be appropriate and clarify that it can be just a warning
> and what that means.
> 
> Mike
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 3 Jun 2010 09:24:16 +0200

I believe that it is quite bad practice to delegate to application
protocol. This is protocol stack signalling and shouldn't be
application specific. Otherwise interoperability problems occur. A
protocol spec should be clear on what it does.

regards,
Nikos

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 3 Jun 2010 07:02:43 -0700

If we are going to make a change then we need some suggested text. 

Joe

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Nikos
> Mavrogiannopoulos
> Sent: Thursday, June 03, 2010 12:24 AM
> To: Joseph Salowey (jsalowey)
> Cc: Michael D'Errico; [email-masked]; [email-masked]

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Thu, 03 Jun 2010 17:32:07 +0200

Hi,

Actual text depends on what one want the extension and the alert to do.

Relevant text:

    A server that receives a client hello containing the "server_name"
    extension MAY use the information contained in the extension to guide
    its selection of an appropriate certificate to return to the client,
    and/or other aspects of security policy.  In this event, the server
    SHALL include an extension of type "server_name" in the (extended)
    server hello.  The "extension_data" field of this extension SHALL be
    empty.

    If the server understood the client hello extension but does not
    recognize the server name, it SHOULD send an "unrecognized_name"
    alert (which MAY be fatal).

What needs to be specified is what a warning with this alert should mean  
to the process of establishing the connection, and how it should be used  
in combination with the returned extension. IMO only one of them may be  
returned.

My preferred option is that the alert is only sent when the server does  
not want to continue the negotiation, that is, a fatal alert, and not  
return a server_name extension in case it did not know the hostname, but  
is willing to continue.

If that is the route we go then the last paragraph above could be changed  
to

    If the server understood the client hello extension but does not
    recognize the server name, and is not willing to establish a connection,
    it MUST send a fatal "unrecognized_name" alert. If it is willing to
    establish the connection it MUST NOT return a "server_name" extension,
    and SHOULD NOT send a "unrecognized_name" warning.

One can also add a note that some current implementations will send a  
warning _and_ include the "server_name" extension (that is the current  
status on the server I observed with the configuration issue), and that  
some clients escalate the warning to Fatal.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 03 Jun 2010 10:21:33 -0700

I agree with Yngve that a server should send either an empty SNI
extension OR an unrecognized_name alert but not both.  However, I
disagree that the server SHOULD NOT send a warning alert since that
hides information from the client.

The possible cases are:

     1 - server understood the SNI and used it to select an appropriate
         certificate chain and other parameters
     2 - server understood the SNI but did not recognize it as one of
         its configured virtual hosts; however, the server is set up
         to use a default configuration in that case
     3 - server understood the SNI but did not recognize it as one of
         its configured virtual hosts; there is no default configuration
         available so the handshake can not continue
     4 - server does not understand the SNI extension

The way my server reacts to each of these cases is:

     1 - add an empty SNI extension to ServerHello
     2 - send a warning unrecognized_name alert
     3 - send a fatal unrecognized_name alert
     4 - send nothing

Yngve would prefer that nothing is sent in case 2, but then a client
can not distinguish it from case 4.

Mike

Yngve Nysaeter Pettersen wrote:
> If that is the route we go then the last paragraph above could be 
> changed to
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 04 Jun 2010 07:43:07 +0200

> hides information from the client.
[...]
> can not distinguish it from case 4.

I believe that his point was, what can the client do anyway? In both
cases the client just follows the handshake and will be prompted if the
"default" certificate doesn't match the connected host. Would the client
need to be warned that he is being connected using the "default"
certificate rather than any specific?

regards,
Nikos

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 3 Jun 2010 23:38:33 -0700

Hi Yngve,

Thanks for the text, some questions below:

> From: Yngve Nysaeter Pettersen [mailto:[email-masked]]
> Sent: Thursday, June 03, 2010 8:32 AM
> To: Nikos Mavrogiannopoulos; Joseph Salowey (jsalowey)
> Cc: [email-masked]
changed
>     and SHOULD NOT send a "unrecognized_name" warning.
[Joe] It seems we still have the same problem, this just replaces the
warning with a lack of empty server_name extension.  I'm not sure I see
what this gains.  It also doesn't seem appropriate in this case to
mandate a change in behavior on the server.  It seems that the server
should return a server_name extension if it understands the extension
(its implemented and enabled).  

It doesn't seem that this is different than other cases where the client
receives a warning. From 5246 the text about warnings says:

" If an alert with a level of warning is sent and received, generally
   the connection can continue normally.  If the receiving party decides
   not to proceed with the connection (e.g., after having received a
   no_renegotiation alert that it is not willing to accept), it SHOULD
   send a fatal alert to terminate the connection.  Given this, the
   sending party cannot, in general, know how the receiving party will
   behave.  Therefore, warning alerts are not very useful when the
   sending party wants to continue the connection, and thus are
   sometimes omitted.  For example, if a peer decides to accept an
   expired certificate (perhaps after confirming this with the user) and
   wants to continue the connection, it would not generally send a
   certificate_expired alert."

Maybe we should change the second paragraph text to 

"If the server understood the client hello extension but does not
 recognize the server name, and it refuses to continue it MUST 
 send a fatal "unrecognized_name" alert.  If the server continues the 
 handshake, sending a "unrecognized_name"
 alert with a warning level is NOT RECOMMENDED, since the 
 client behavior is unpredictable.  Some clients
 may respond by aborting the handshake while others may allow it
 to continue to certificate validation, which may fail as a result 
 of a name mismatch. "

> >> > It seems that the behavior is dependent upon the application.
I'm
> >> not
> >> >> From: [email-masked] [mailto:[email-masked]] On
Behalf
> >> Of
> >> >> >> virtual host with that domain name.  If there is, then no
alert
> >> is
> >> >> >> an unrecognized_name alert is sent with the warning level.
When
> >> no

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Fri, 04 Jun 2010 17:59:24 +0200

> (its implemented and enabled).

I think the questions that needs answering are "What does this extension  
and alert mean?" and "What do we want the client to do when it receives  
the alert?" (A thought: Are there other extensions and warning alerts that  
suffer from the same problem?)

The problem is that most warnings are not very useful to client, as  
mentioned in your quote from 5246, and most alerts are fatal anayway. This  
is part of the background for why I separated out the handful of warning  
we can handle automatically, and handled all other as fatal.

Regarding the extension what to do depends on what the extension from the  
server means. Is it "I support the extension" or "I recognized the name"?  
In the latter case it could be used to decide what to do if the presented  
certificate does not match the hostname (In which case the question  
becomes whether or not to throw a fatal alert, or present a warning to the  
user)

>  to continue to certificate validation, which may fail as a result

Looks acceptable to me.

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Jun 2010 18:01:57 +0200 (MEST)

> certificate rather than any specific?

I think the issue is much more about API semantics.

Most APIs are pretty binary, either they succeed, or they fail with
a (numeric) error code.  The case "succeeds with a warning code"
is fairly unusual for APIs, and very unusual to application programmers.

Defining non-fatal error codes might be possible, but you don't know
what exactly apps will do: will they simply ignore error codes that
are classified non-fatal or will they abort on all error codes that
they do not recognize.

And as soon as you have several software/abstraction layers in your
software architecture, the picture becomes more and more fuzzy,
because you don't know whether intermediate layers are prepared
to deal with non-fatal error codes and in particular non-fatal
error codes that were defined after the intermediate layers
were shippped.

A warning-level "unrecognized_name" alert is useful for the receiver
only when it is made available to the application on top of TLS in
a clearly defined and consistent fashion.  If we want to allow
warning-level "unrecognized_name" alerts, then we must define
the API semantics for the receiving TLS implementation that
its calling app is going to experience.  Otherwise, we should get
rid of it (and use the fatal-level alert for the situation where
the server is condigured to abort the handshake).

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 04 Jun 2010 09:17:59 -0700

I would like to see text that says a peer SHOULD ignore warning alerts
that it doesn't otherwise handle.  Clearly the peer that sent the alert
with a warning level doesn't think it's a showstopper -- if it was a
problem, the alert level would have been fatal.

Peers that escalate a warning to fatal are not playing nice; they are
causing other software to abandon the practice of sending warnings even
though they could prove useful.  Just because you can't imagine why a
warning alert would be useful, today, doesn't mean that a use will never
be found for it.

Mike

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Jun 2010 18:47:04 +0200 (MEST)

> warning alert would be useful, today, doesn't mean that a use will never

I think we are talking past each other.

I do not have any problems with the existence of warning level alerts.

But defining only the situation when one peer can send a particular
warning level alert is entirely insufficient.  The definition of
a warning-level alert _MUST_ describe how the receiving peer is
supposed to react to this.  In most cases, a warning-level alert
indicates that something unusal happend on the last protocol
exchange, and there is no means _within_ the TLS handshake to resend
a previous handshake message with different properties -- which means
that we will may have to specify application/API semantics. 

For the warning-level unrecognized_name alert, I believe we have to specify
application/API semantics for the receiver.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Fri, 04 Jun 2010 12:14:44 -0500

On 6/4/2010 11:47 AM, Martin Rex wrote:
> supposed to react to this.

I don't agree with such an absolute statement.

Sometimes the only use of a protocol message is to provide information
to a software developer who wrote the code so he has some clues to go on
when the bug report with the protocol trace lands in his inbox.

Although it is good to try to avoid it, the vast majority of nontrivial
systems have failure modes that were not anticipated during development
and testing. As a developer, I really value the ability to issue some
opaque internal error code message into some log file. Somehow the
system got into a state that I didn't expect it could, if I could have
described how the system should react, I would have coded it that way.

A strict policy like "all warnings must X" just leads to the warning
message facility being unusable for cases where X is too difficult.

- Marsh

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 4 Jun 2010 10:37:02 -0700

The discussion in 5246 indicates that the warning messages are
unpredictable.  I don't think we can solve this problem in this document
so we wither discourage the warning in this case or we just explain the
unpredictability.  Below are two proposed text change to paragraph after
the structure definition in section 3 in draft-ietf-tls-rfc4366-bis-08.
Let me know which you prefer soon as we need to get this document
finished, because other documents are waiting on it.  

Thanks,

Joe

(1) "The ServerNameList MUST NOT contain more than one name of the same
name_type. If the server understood the client hello extension, but does
not recognize the server name, and it refuses to continue it MUST send a
fatal unrecognized_name(112) alert and terminate the handshake.  If the
server decides to continue the  handshake, sending a
unrecognized_name(112) alert with a warning level is NOT RECOMMENDED,
since the  client behavior is unpredictable.  Some clients respond by
aborting the handshake while others allow it  to continue to certificate
validation, which may fail as a result of a name mismatch. "

or

(2) "The ServerNameList MUST NOT contain more than one name of the same
name_type. If the server understood the client hello extension but does
not recognize any of the server names, it SHOULD send an
unrecognized_name(112) alert (which MAY be fatal). Sending an
unrecognized_name(112) alert with a warning level will lead to
unpredictable behavior as some clients respond by aborting the handshake
while others allow it to continue to certificate validation, which may
fail as a result of a name mismatch."

> Martin Rex
> Sent: Friday, June 04, 2010 9:47 AM
> To: Michael D'Errico
> Cc: [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Jun 2010 20:47:44 +0200 (MEST)

> when the bug report with the protocol trace lands in his inbox.

It seems that I wasn't clear enough in my description.

This must first of all describe how the implementor of the technology TLS
must make this information available to the consumer of the
technology/implementation (i.e. the application caller).

This is similar of how an implementation of TCP must exihibt specific
semantics to the application caller on receipt of certain TCP flags,
e.g. the TCP PUSH flag.

If the spec does not describe this, then it may result in either getting
entirely ignored--at which point it is useless complexity in the spec,
or result in unnecessary interop problems, i.e. if a client unconditionally
abort receiving a warning-level unrecognized_name alert.  In both cases
such a (mis-)feature would have to be stripped when advancing the spec
to draft, so there is no point including it in the spec in the first place.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Jun 2010 21:51:05 +0200 (MEST)

> finished, because other documents are waiting on it.  

I do agree that we're talking about an extension (SNI) and an alert
for an existing spec (rfc4366) and an existing installed base,
so describing the risk of sending a warning-level "unrecognized_name"
alert to clients is sensible and appreciated.

Still, I think we have to document what _clients_ SHOULD and SHOULD NOT
do when receiving a warning-level "unrecognized_name" alert.  This was,
and still is not clear from the specification, rather it is essentially
undefined  (it is _not_ implementation defined, because a server
can not reliably distinguish individual peer client implementations by
looking at the contents of the ClientHello handshake message it sent).

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Fri, 04 Jun 2010 14:52:29 -0500

> to draft, so there is no point including it in the spec in the first place.

OK, I'll buy that at the level of "should" but not at "_MUST_", if that
makes any sense.

Part of the value in using a separate library with a defined API is that
it reduces the number of states and failure modes that the application
code has to consider. It's exactly like object-oriented encapsulation
which allows the scary mechanical guts of an implementation to be hidden
behind a relatively simple interface. In reality, application code often
deals with TLS connections through the same interface as regular TCP
socket connections. This is great, as long as it's not an
oversimplification of what is really complicated.

As both a "casual user" and occasional "power user" of networking APIs,
I rely on having the option of working with every little detail of the
protocol when I need it. Making an API (or set of APIs) that satisfy
everyone is a real art!

Nevertheless, the vast majority of application code seems to have a
choice of two options when encountering an exceptional condition:

   1. Ignore it and continue as if nothing is wrong.
   2. Abort the operation and propagate the error up to the caller.

In relatively rare cases, a third option is:

   3. Change something (e.g. wait some time) and retry.

Since all of these options require truly non-trivial implementation on
the application side in order to result in a robust system, mandating
application behavior as part of a protocol spec may be asking a bit much.

This is a data security protocol after all and the handshake should
"fail to succeed" if the endpoint identities don't match up right.

IMHO Language like "if the server refuses to continue" should be avoided
in this kind of spec. It's the job of the spec to specify whether the
server should continue or terminate because it is or isn't safe, so in a
sense this warning is just pushing the hard decisions onto the library
and application.

When faced with a 'warning'-like condition, we should try really hard to
define it to be either a fatal error or a success (though possibly with
informational-level messages).

In most cases the name on the certificate would serve to eliminate any
confusion, but there are wildcard certs in use too.

I'm sorry if I missed this in earlier discussion, but why on earth would
an SNI-aware server ever want to continue a handshake with a client that
asked for a name he didn't serve?

A simple solution seemed to work for session resumption:

>From http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-08 :
>    A server that implements this extension MUST NOT accept the request to
>    resume the session if the server_name extension contains a different
>    name.

Can we just define this situation as a fatal handshake error and be done
with it?

- Marsh

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 04 Jun 2010 15:18:47 -0600

> Can we just define this situation as a fatal handshake error and be done

+1

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 04 Jun 2010 20:30:52 -0700

> validation, which may fail as a result of a name mismatch. "

I prefer the above text, but would modify it slightly:

     If the server decides to continue the handshake, sending an
     unrecognized_name(112) alert with a warning level is NOT
     RECOMMENDED at this time due to legacy client software that
     escalates it to a fatal error.  New software is encouraged
     to treat warning alerts as informational, and not to abort
     an otherwise legitimate handshake.

Mike

---

From: Martin Rex <[email-masked]>
Date: Mon, 7 Jun 2010 17:03:05 +0200 (MEST)

>      an otherwise legitimate handshake.

Technically, there is no such thing as an "escalation to a fatal error",
so this exact wording is inappropriate.

If a TLS peer decides to abort the handshake when receiving a warning-level
alert, that TLS peer  SHOULD send a fatal alert before closing the
connection.

When receiving a fatal-level alert, there is nothing else to send back
(the TLS peer will _NOT_ read this anyway, and there may even be unread
handshake message still in the incoming network pipe of the TLS peer
that sent the fatal alert).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 7 Jun 2010 16:46:29 +0200 (MEST)

> certificate rather than any specific?

I actually fail to see the exact purpose of a warning-level alert
"unrecognized_name".  The client is supposed to perform the server endpoint
identification in any case, and that warning should not affect the
outcome of that process at all.

Btw. this warning-level alert could be stripped from the handshake
by an attacker _without_ affecting the handshake message hash and
finished calculations (alerts are not handshake messages and are therefore
invisible to the handshake message hash).  Similarly, an attacker
can insert such a warning-level alert into handshakes without affecting
the handshake message hash.

I think there should be a guidance in the spec what the
receiver of that alert at level warning should do.

   A client that receives a warning-level "unrecognized_name" alert
   SHOULD ignore this alert and continue the TLS handshake.  The purpose
   of a warning-level "unrecognized_name" is for diagnostic purposes,
   if anything.

   A client TLS implementation MAY offer API functionality for the client
   application to determine what warning-level alerts were received
   during a TLS handshake.  When the server endpoint identification
   performed by the client application fails, then a client application
   might want to query whether any warning-level alerts have been
   received during the TLS handshake and mention these in the information
   presented to a user or written to a logfile for diagnostic purposes.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Mon, 07 Jun 2010 12:51:48 -0500

On 6/7/2010 9:46 AM, Martin Rex wrote:
> identification in any case,

Let us not forget anon-anon connections!

Even for authenticated-server connections, some authentications are
stronger or more specific than others. This can be affected by SNI.

> and that warning should not affect the

For example, an SNI-aware client app may request webservice.example.com,
but a DNS mixup sends him to the SNI-aware server serving
www.example.com with a wildcard certificate valid for *.example.com.

In this case I think a failed handshake would be the best outcome.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 07 Jun 2010 10:53:35 -0700

> outcome of that process at all.

I feel like I'm "guilty until proven innocent" on this one.

Have you ever connected to a secure site only to have the HTML contain a
warning that inadequate security was established?  This used to happen
if you connected to www.paypal.com with DES3 (but now it is just closing
the connection).  The purpose of that behavior was to give the end user
more diagnostic information than they get when the connection is merely
dropped after sending a fatal handshake_failure alert.

It would help if a no_common_ciphers alert was added to TLS.  That alert
would be sent when the server doesn't support any of the client's
proposed cipher suites.  It could also be used at the warning level in
the case of paypal's former behavior.  The handshake would complete
(after sending the warning) and then the server application would display
its error message in the HTML sent to the client.  The client's low-level
TLS code could be interrogated as to whether anything strange occurred
and it would be able to provide an answer.

The unrecognized_name warning alert can provide similar information to a
client application.  If something goes wrong and the client application
is looking for a reason why, it can ask the TLS layer if anything strange
happened.  If this warning alert was received, that information might
help the client diagnose the problem and determine what corrective action
to take.

However I disagree with your wording:

Clearly you don't see much use for this alert, but you should not impose
that bias on others.  It is up to the application to decide what to do
with the facilities provided by the TLS protocol.

Mike

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 07 Jun 2010 19:56:15 +0200

> In this case I think a failed handshake would be the best outcome.

But a warning alert cannot serve this purpose. A fatal alert is the
appropriate in that case.

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 07 Jun 2010 20:05:59 +0200

> dropped after sending a fatal handshake_failure alert.

TLS doesn't handle this. TLS doesn't even specify a security level for a
connection (and it isn't easy to).

> (after sending the warning)

How would it complete if they don't have common ciphers?

> help the client diagnose the problem and determine what corrective action

For the current example it is obvious what went wrong by viewing the
certificate sent isn't it?

> with the facilities provided by the TLS protocol.

I think it is important to have a good case of a thing to be handled in
code. If a TLS warning alert is _never_ going to be used, or it does not
provide valuable information to the peer. However if you think that this
information is valuable and it might even save debugging time for
implementors then I think it would be a nice opportunity to reconsider
(at least for me). Otherwise I think that the information provided by
this alert is redundant since it can be also seen by the certificate sent.

regards,
Nikos

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 07 Jun 2010 11:50:23 -0700

> connection (and it isn't easy to).

Paypal is who decided that DES3 was not acceptably secure for them.  I am
not suggesting that TLS can decide what is right for every application.

> How would it complete if they don't have common ciphers?

They allowed DES3 to be negotiated, but then in the application they sent
an HTML error page if the cipher suite used it.  The idea was apparently
that they thought they could present a better error message than a browser
would if they simply failed with a handshake_failure alert.

> certificate sent isn't it?

It may be, but having more than one data point is better.  Why suppress
it?

> this alert is redundant since it can be also seen by the certificate sent.

In a past life I wrote email server software.  I was very young, new to
standards groups, even very new to programming.  I used to argue against
things that I didn't understand very well because they sounded difficult
to implement or I couldn't see their potential usefulness.  It was wrong
for me to try to impose my own limitations on others who were much more
capable than I was at the time.  Fortunately I didn't cause any permanent
damage.

However, I see the opposite happening here.  I've put hundreds, maybe
thousands of hours into my TLS implementation and have thought through
every last detail.  I would love to have many more alerts added to TLS
(some warning, some fatal, maybe some both) to aid in diagnosing why
connections don't succeed, or perhaps why they succeeded, but maybe not
in the way they should have (e.g. with Paypal's former behavior).

It's frustrating to have to defend a feature that already exists in TLS
from people that want to scrap it simply because they personally haven't
found a use for it.

Mike

---

From: Martin Rex <[email-masked]>
Date: Mon, 7 Jun 2010 21:46:11 +0200 (MEST)

> with the facilities provided by the TLS protocol.

I am sorry for again being ambiguous in my descriptions.

This wording is supposed to apply to >>TLS client implementations<<,
and these are supposed to completely ignore warning-level alerts and
continue the TLS handshake.  Whether or not the resulting TLS session
characteristics meet the expectations or policy of the calling application
is an entirely different matter and up to the application to decide.

The client application can do _nothing_ useful with a warning-level
alert "unrecognized_name" other than show it to a user or write it
to a logfile.  In both situations, it MUST NOT stall the ongoing
handshake, but instead either abort (sending a fatal handshake alert)
or ignore and continue this handshake.

A non-negligible amount of the installed base of browsers (~50%) and
programmatic clients is not going to send an extension SNI, so servers
will likely have to provide something sensible for that situation anyway,
and for quite some time to come -- entirely without that alert.

-Martin

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 7 Jun 2010 13:08:55 -0700

<snip>
> 
> It should be in both places, especially since there won't be another
> update to the main spec for several years.
> 
[Joe] 4366-bis does not update 5246.  Right now we need to focus on
resolving this issue for SNI so we can get the document out. 

> The problem seems to be that the names given to alert levels both
sound
> bad.  Really what they mean are "fatal" and "non-fatal" but since the
> name "warning" was chosen as the label, implementers who haven't
thought
> much about it decide that warning == bad, so they escalate it to
fatal.
> 
> They need to be told that warning alerts should not automatically be
> treated as fatal, but should be ignored by default.  If they have gone
> through an analysis and determined that a particular warning alert is
> really fatal for them, then they are justified in aborting the
handshake
> when they see that particular warning.
> 
> > My version of how the text should be is:
> >
> > fatal unrecognized_name(112) alert and terminate the handshake.
> > The server might decide to continue the  handshake, but in that case
it
> > is NOT RECOMMENDED send any warning alert. Clients SHOULD be
prepared to
> > receive and ignore the unrecognized_name(112) alert with warning
level.
> 
> I could live with this text.  I would also like section 9 (Error
Alerts)
> to mention that warning alerts should be treated as informational
(non-
> fatal) by default to help avoid similar problems in the future.
> 
> Mike

---

From: Martin Rex <[email-masked]>
Date: Mon, 7 Jun 2010 22:10:25 +0200 (MEST)

> when the bug report with the protocol trace lands in his inbox.

We are discussing a network protocol here, and there we need a
_MUST_ define the semantics of a protocol signal for both, the sender
and the receipient.  Everything else is going to be an interoperability
problem (as observed by Yngve), or at least useless protocol complexity.

> message facility being unusable for cases where X is too difficult.

This description oversimplifies the whole issue.

If there are protocol elements that convey information between to
communication peers, then the semantics of that piece of information
must be well-defined for both, sender and receipient.  Some of the
conveyed information affects the communication protocol itself,
other information is conveyed for consumption by the calling
application, not for the protocol engine itself -- such as a
warning-level alert "unrecognized_name".

It makes perfect sense to require this information be made available
_by_the_recipient_TLS_implementation_ to the receipient calling
application _somehow_ (details unspecified).  A calling application
that does care about this non-fatal information will have to retrieve it.
The calling app may decide to abort the fully established TLS session and
retry with different parameters later on.  But the TLS (client)
implementation receiving a warning-level "unrecognized_name"
alert SHOULD ignore this alert and continue the TLS handshake.
There is nothing that the receiving TLS implementation itself can do
about this warning-level alert.

Aborting on an unexpected (or even unknown warning-level TLS alert)
appears to be generally a bad idea, because it creates unnecessary
interop problems.  The IETF golden rule for protocol applies here
"be liberal in what you accept".  TLS protocol engines that
unconditionally fail when receiving unknown or unexpected
warning-level alerts (excluding those warning-level alerts that
have a well-defined protocol-engine semantic, such as close_notify)
exhibit a significant lack of robustness.

-Martin

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 7 Jun 2010 13:29:11 -0700

OK, here is some new suggested text.  Let me know if you can live with
this.  

"The ServerNameList MUST NOT contain more than one name of the same
name_type. If the server understood the client hello extension, but
refuses to continue because it does not recognize the server name, it
MUST send a fatal unrecognized_name(112) alert and terminate the
handshake.  If the server decides to continue the  handshake, sending a
unrecognized_name(112) alert with a warning level is NOT RECOMMENDED,
since existing  client behavior is unpredictable.  A client that
receives a warning-level unrecognized_name(112) alert SHOULD ignore this
alert and continue the TLS handshake, which may fail as a result of a
name mismatch.  The warning MAY be logged as part of diagnostic
information recorded for a failed handshake."

Thanks,

Joe

> Sent: Monday, June 07, 2010 1:10 PM
> To: Marsh Ray
> Cc: [email-masked]

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 07 Jun 2010 13:51:23 -0700

> is an entirely different matter and up to the application to decide.

This may be a language problem.  I interpret a suggestion that a client
should "completely ignore" something, that it should throw it away and
behave as if it never saw it; doing anything with the information (even
just making it available to the application) would violate the protocol.

I'm saying that, yes, it should continue the handshake as if it never
saw the warning alert, but no it should not be forbidden from remembering
that it was received or from passing that information along.

> or ignore and continue this handshake.

You don't consider being able to write an error message to a log file
useful?  I agree that showing this alert to an average user won't be
much help, but if they show it to their system administrator, there's
a chance that they would have a clue as to the problem.

> and for quite some time to come -- entirely without that alert.

Eventually they will all be sending SNI or will perish.  IPv4 space
is running out fast.  But this is a straw man since the alert is not
sent to a client that doesn't send SNI at all.

Mike

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Jun 2010 00:03:59 +0200 (MEST)

> information recorded for a failed handshake."

I am fine with what I think is the intention of this wording,
but I would actually appreciate to be more specific about what
"may fail as a result of a name mismatch" applies to exactly.

                                                     A TLS client
  implementation that receives a warning-level unrecognized_name(112)
  alert SHOULD ignore this alert and continue the TLS handshake.
  If there is a mismatch between the server name used by the client
  application and the server name of the default 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 wether to proceed
  with the communication.  TLS implementations are encouraged to
  make information available to application callers about warning-level
  alerts that were received during a TLS handshake. Such information
  can be useful for diagnostic purposes.

-Martin

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 7 Jun 2010 16:10:36 -0700

OK with me, so we have:

"The ServerNameList MUST NOT contain more than one name of the same
name_type. If the server understood the client hello extension, but
refuses to continue because it does not recognize the server name, it
MUST send a fatal unrecognized_name(112) alert and terminate the
handshake.  If the server decides to continue the  handshake, sending a
warning-level unrecognized_name(112) alert is NOT RECOMMENDED, since
existing  client behavior is unpredictable. A TLS client implementation
that receives a warning-level unrecognized_name(112) alert SHOULD ignore
this alert and continue the TLS handshake.  If there is a mismatch
between the server name used by the client application and the server
name of the default 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.  TLS implementations
are encouraged to make information available to application callers
about warning-level alerts that were received during a TLS handshake.
Such information can be useful for diagnostic purposes. "

> From: Martin Rex [mailto:[email-masked]]
> Sent: Monday, June 07, 2010 3:04 PM
RECOMMENDED,

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 07 Jun 2010 16:16:54 -0700

Looks good.

Mike

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 08 Jun 2010 15:59:57 +1200

Martin Rex <[email-masked]> writes:

>communication peers, then the semantics of that piece of information must be
>well-defined for both, sender and receipient.

... unless the protocol is IPsec, OCSP, CMP, TSP, portions of SSH, uhh... what
else is there... well, in any case I think I've made my point.

>The IETF golden rule for protocol applies here "be liberal in what you
>accept".

What people usually omit when they quote this is the footnote in the appendix
to the apocrypha:

"... unless it's a security protocol".

Peter.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 08 Jun 2010 10:16:44 +0200

> Such information can be useful for diagnostic purposes. "

It is ok with me. My only reservation would be "... sending a
warning-level unrecognized_name(112) alert is NOT RECOMMENDED ...". One
might deduce, ok let's send some other alert to indicate the situation.
I'd prefer "... sending any warning-level alert to indicate this
situation is NOT RECOMMENDED ..."

regards,
Nikos

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Jun 2010 15:27:46 +0200 (MEST)

Peter Gutmann wrote:
> > The IETF golden rule for protocol applies here
> > "be liberal in what you accept".
> 
> What people usually omit when they quote this is the footnote in the
> appendix to the apocrypha:
> 

That IMHO misses the point by a significant margin.

"be liberal in what you accept" was never meant in the sense
of being sloppy in performing validation of security-critical parameters.

As previously described here
  http://www.ietf.org/mail-archive/web/tls/current/msg06356.html
SSL-Alerts during the TLS handshake are _not_ protected by the
TLS handshake message hash that is authenticated with the finished
messages, so Alerts are purely optional protocol features that are
not security relevant and therefore the golden IETF rule applies
to them without restriction.

If we want to convey security-critical parameters in the TLS handshake
protocol, then it must either be part of regular handshake messages
or otherwise get covered by the protection of the handshake message
hash and/or finished message calculations.

> > must be well-defined for both, sender and receipient.
> 
> ... unless the protocol is IPsec, OCSP, CMP, TSP, portions of SSH, uhh...
> what else is there... well, in any case I think I've made my point.

I do not understand what you mean.

In security protocols it is much more important to specify the exact
semantics of all security-critical parameters for both, sender and
recipient, otherwise this will result in interop problems, because
being sloppy about checking security-critical parameter values is
_not_ an option.

Did you want to assert that the mentioned protocols contain a lot of
underspecified security-critical parameters?

-Martin

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 8 Jun 2010 10:48:53 -0400

My belief is that the only reason for different errors/warnings/alerts to
have different *numbers* is so that programs can, in a reliable way, behave
differently based on that number.

Donald
=============================
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street
Milford, MA 01757 USA
[email-masked]

---

From: Sean Turner <[email-masked]>
Date: Tue, 08 Jun 2010 11:50:54 -0400

> situation is NOT RECOMMENDED ..."

If you're going to use "NOT RECOMMENDED" add it to section 1.2.  You 
could use something like*:

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
  NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
  "MAY", and "OPTIONAL" in this document are to be interpreted as
  described in [RFC2119].

* http://www.rfc-editor.org/errata_search.php?eid=499

spt

---

From: "t.petch" <[email-masked]>
Date: Tue, 8 Jun 2010 14:44:51 +0200

I was about to say that ... but eventually realised I was misinterpreting the
text, so I suggest adding a clause to express the 'if-then-else' more
rigourously ie

name_type.

If the server understood the client hello extension, but
**decides not to continue because it does not recognize the server name, it
MUST send a fatal unrecognized_name(112) alert and terminate the
handshake.

**If the server understood the client hello extension but** decides to continue
the  handshake, sending a warning-level unrecognized_name(112) alert is NOT
RECOMMENDED, since existing  client behavior is unpredictable.

...."

which also makes it clear we are not covering the case of client hello extension
not understood.

Tom Petch

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 8 Jun 2010 22:22:04 -0700

We should revise the draft with the text below, and add NOT RECOMMENDED
to section 1.2. When the revision is available we can have Sean continue
progressing the document. 

"The ServerNameList MUST NOT contain more than one name of the same
name_type. If the server understood the client hello extension, but
decides not to continue because it does not recognize the server name,
it MUST send a fatal unrecognized_name(112) alert and terminate the
handshake.  If the server understood the client hello extension, but
decides to continue the  handshake, sending a warning-level
unrecognized_name(112) alert is NOT RECOMMENDED, since existing  client
behavior is unpredictable. A TLS client implementation that receives a
warning-level unrecognized_name(112) alert SHOULD ignore this alert and
continue the TLS handshake.  If there is a mismatch between the server
name used by the client application and the server name of the default
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.  TLS implementations are encouraged to
make information available to application callers about warning-level
alerts that were received or sent during a TLS handshake.  Such
information can be useful for diagnostic purposes."

> From: t.petch [mailto:[email-masked]]
> Sent: Tuesday, June 08, 2010 5:45 AM
> I was about to say that ... but eventually realised I was
misinterpreting
> the
> **decides not to continue because it does not recognize the server
name,
> the  handshake, sending a warning-level unrecognized_name(112) alert
is
> NOT
> > > > OK, here is some new suggested text.  Let me know if you can
live
> > with
> > > > refuses to continue because it does not recognize the server
name,
> > > > receives a warning-level unrecognized_name(112) alert SHOULD
ignore
> > this
> > > > alert and continue the TLS handshake, which may fail as a result
of
> > a

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 09 Jun 2010 07:29:12 -0700

> it MUST send a fatal unrecognized_name(112) alert and terminate the

OK.

> behavior is unpredictable.

After reading this again, I think it's missing something:  If the
server understood the extension but did not recognize the server name,
yet continues with the handshake anyway using default configuration
parameters, sending a warning-level....

Mike

> A TLS client implementation that receives a

---

From: Martin Rex <[email-masked]>
Date: Wed, 9 Jun 2010 16:56:46 +0200 (MEST)

Michael D'Errico wrote:
> 
> After reading this again, I think it's missing something.

I felt the same.

Another possible approach would be to slightly rearrange that part.

 "The ServerNameList MUST NOT contain more than one name of the same
  name_type.  If the server understood the client hello extension,

  but does not recognize the server name, the server has two options.
  Either abort the handshake sending a fatal unrecognized_name(112)
  alert or continue the handshake using a default credential.
  Sending a warning-level unrecognized_name(112) alert in the latter
  case is NOT RECOMMENDED, since existing client behaviour is
  unpredictable.

-Martin

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 9 Jun 2010 08:12:47 -0700

Thanks,  

The text below looks much better looks much better. Let's go with that. 

Joe
> Sent: Wednesday, June 09, 2010 7:57 AM
> To: Michael D'Errico
> Cc: Joseph Salowey (jsalowey); [email-masked]
> > > warning-level unrecognized_name(112) alert SHOULD ignore this
alert
> and
> > > credential chosen by the server, this mismatch will become
apparent
> when

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Jun 2010 09:37:54 -0700

>>   case is NOT RECOMMENDED, since existing client behaviour is

This is definitely more understandable than earlier revs. However, there is still not enough definitive wording. I propose:

The ServerNameList MUST NOT contain more than one name of the same
name_type.  If the server understood the ClientHello extension but
does not recognize the server name, the server SHOULD take one of two
actions: abort the handshake by sending a fatal
unrecognized_name(112) alert, or continue the handshake using a
default credential. Sending a warning-level alert such as
unrecognized_name(112), but continuing the handshake, is NOT
RECOMMENDED because the client's expected behavior in response to
this is unpredictable.

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 09 Jun 2010 10:13:48 -0700

I agree Martin's text is better than mine.  But I'd like to modify
it slightly:

    Sending a warning-level unrecognized_name(112) alert in the
    latter case is allowed, but NOT RECOMMENDED since .....
                ^^^^^^^^^^

Mike

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 09 Jun 2010 10:16:41 -0700

Paul Hoffman wrote:
> 
> ... there is still not enough definitive wording. I propose:
> 

The last sentence makes it unclear whether sending the alert is not
recommended or if continuing the handshake is not recommended.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Wed, 09 Jun 2010 12:26:49 -0500

On 6/9/2010 11:37 AM, Paul Hoffman wrote:
> 
> This is definitely more understandable than earlier revs. However,
> there is still not enough definitive wording. I propose:
> 
> does not recognize the server name, the server SHOULD take one of
> two actions: abort the handshake by sending a fatal 
> default credential.

Is it necessary to specify that the continued handshake SHOULD "use a
default credential"? TLS doesn't really require handshakes to use
credentals after all.

Perhaps this is extraneous overspecification?

If not, perhaps some clarification of the meaning of this term
"default credential" would be helpful. I'm not sure if this is what was
meant, but one possible rewording might be "or continue the handshake as
if the client had not specified a server_name extension."

> Sending a warning-level alert such as 

I accept that I may be in the minority on this (I honestly don't see why
this case shouldn't be considered grounds for outright handshake
failure). Still, as a guy who writes app code on the client side, the
server side, and sometimes in between it seems to me like what we're
calling "unpredictable client behavior" here is really the effect of
conscious design decisions that made by implementers of TLS libraries
and client application code.

So if a modern SNI-aware client wishes to abort the handshake on
receiving the name mismatch warning, is it really appropriate for the
revised spec to attempt to defeat that by saying the server should
withhold this information from the client and the warning SHOULD NOT be
sent at all?

- Marsh

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 Jun 2010 11:28:47 -0600

> recommended or if continuing the handshake is not recommended.

Perhaps this is better:

   It is NOT RECOMMENDED to send a warning-level alert such as
   unrecognized_name(112) but continue the handshake, because
   the client's expected behavior in this case is unpredictable.

/psa

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 9 Jun 2010 11:06:42 -0700

Thanks all, I think we now have it:

"The ServerNameList MUST NOT contain more than one name of the same name_type.  If the server understood the ClientHello extension but does not recognize the server name, the server SHOULD take one of two actions: either abort the handshake by sending a fatal-level unrecognized_name(112) alert, or continue the handshake.  It is NOT RECOMMENDED to send a warning-level unrecognized_name(112) alert, because 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.  TLS implementations are encouraged to make information available to application callers about warning-level alerts that were received or sent during a TLS handshake.  Such information can be useful for diagnostic purposes."

> Peter Saint-Andre
> Sent: Wednesday, June 09, 2010 10:29 AM
> To: [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Wed, 9 Jun 2010 20:13:57 +0200 (MEST)

> default credential"? TLS doesn't really require handshakes to use

The purpose of the server_name extension is to allow the server to
choose a server credential that is going to pass the client's
server endpoint identification check.

And even when DH_anon cipher suites are used, there certainly is a
"credential" involved, it just is not associated with any name.

> Perhaps this is extraneous overspecification?

I don't think so.  It makes a nicer fit with the (new) later text
describing the server endpoint identification performed by the
client application.

> if the client had not specified a server_name extension."

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.

> and client application code.

Admittedly, "unpredictable" sounds slighlty strange, although it
matches reality.  For the server, there are roughly two kind of
"visible" client reactions when sending a warning-level alert
unrecognized_name(112).   Either the client aborts the handshake
(with or without sending a fatal alert), or the client continues
the handshake.

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.

> withhold this information from the client and the warning SHOULD NOT be

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

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 09 Jun 2010 11:14:32 -0700

> and client application code.

Let me try another approach.

Now that you know that my server code might send an unrecognized_name
warning alert to you in some very limited circumstances, what will you
do in your client code?  Since you don't care about this particular edge
case, the sensible thing is for you to ignore it.

Here's some pseudo-code:

     if (alert_level is fatal)
     {
         abort handshake;
     }
     else if (alert_level is not warning)
     {
         abort handshake;  // protocol error
     }
     else if (alert is close_notify)
     {
         forward EOF to application;
     }
     else
     {
         // ignore warnings we don't care about
     }

> withhold this information from the client and the warning SHOULD NOT be

The ability to send a warning-level unrecognized_name alert is in the
current spec (RFC 4366).  You are arguing that since you don't care
about the information it conveys that we should ban it.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Wed, 09 Jun 2010 13:54:21 -0500

> "credential" involved, it just is not associated with any name.

Guess I thought of it as unauthenticated key agreement without use of
credentials.

> 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 

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

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

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 Jun 2010 23:23:01 +0200 (MEST)

> Guess I thought of it as unauthenticated key agreement without use of

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.

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

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

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

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

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

> 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

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 11 Jun 2010 15:47:46 -0700

> SNI is _not_ a naming service.  It is not even a part of TLS itself.

I have no idea what point you're trying to make here.  What gives you
the idea that the server name extension is not a part of TLS?  It was
a missing requirement that has been added as an extension, which is
similar to the "Host:" header of HTTP.  "Host:" was not a part of the
first HTTP specification, but its need became clear and it was added
later.  That does not mean that "Host:" is not actually a part of HTTP!

> and conveyed through a TLS extension.

No, it's not a "hint."  It tells the TLS layer which domain name the
client is trying to communicate with.  If you have a server that handles
more than one domain name on the same IP address, there is no other way
for the TLS layer to know which certificate chain to use in its negotia-
tion.

>    of protocols that run on top of TLS. 

Yes, but it was decided that RFC 5246 would not subsume RFC 4366 (TLS
extensions), so of course RFC 5246 does not say anything about SNI.

> is violating the TLS spec and can easily cause needless interop problems.

It's apparent that you don't understand what SNI is for.  TLS absolutely
needs to know which domain name a client is trying to connect to so that
an appropriate certificate chain can be selected.  The "Host:" header
fixed HTTP so that it could handle multiple domains on a single IP
address; that and the SNI extension fix HTTPS to work for multiple
domains on a single IP address.  Nothing fancy about it, and certainly
not broken.

Mike

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 Jun 2010 16:02:18 +0200 (MEST)

Michael D'Errico wrote:
> the idea that the server name extension is not a part of TLS?

> an appropriate certificate chain can be selected.

No, it doesn't.  It is a clear violation of the architecture if TLS
itself messes around with the names in certificates.

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.

Even if may TLS implementations today provide helper functions to
applications for performing server endpoint identification, it is still
a matter of the application to make use of these function, or to
perform endpoint identification in a completely different fashion.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 14 Jun 2010 08:36:36 -0700

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

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

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.

Mike

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 14 Jun 2010 18:46:56 +0200

> instead of requiring every application writer to have to reinvent it.

Note that he's talking about the protocol not about a specific
implementation. A library could handle everything over all layers or
only handle few things on a layer. It is just an implementation for a
specific purpose. It is perfectly ok to see network implementations
mixing tcp/ip and dns resolving, even TLS, although they are not
strictly in a single layer.

However layers should be clear in the protocol descriptions to allow for
replacing layers transparently. TLS does not need DNS to work, nor
TCP/IP. If the new internet runs on BBP/CD, TLS will still work.

regards,
Nikos

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 14 Jun 2010 10:31:27 -0700

> TCP/IP. If the new internet runs on BBP/CD, TLS will still work.

I know that TLS does not depend on DNS or TCP/IP.  My code has no idea
about either of them; it just processes strings.  My objection was to
Martin's belief that SNI is somehow not a part of TLS because it is
"just" an extension.  He implied that if TLS code uses the SNI for
anything other than to pass it to the application, it must be broken.
That is just his opinion, and when I release my code he will have the
freedom to not use it.

This thread is now off topic, so I won't say anything more about it.

Mike

P.S. where can I find the spec for BBP/CD?  :-)

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 14 Jun 2010 19:26:26 +0200

I wro

the  client protocol client needs
> a way to communicate the desired dnsname to TLS layer
> and to the application entity,  the latter not necessarily in theory
> if TLS is always used. SNI is one way to do the first.
I am wrong here. The target is not the TLS layer. Rather
the SNI is an addressing information targeted to the application
piggypacked to a TLS protocol element.

Could also be done by some kind prefixing application data unit
followed by some starttls like thing to enter the TLS layer.

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 14 Jun 2010 18:22:21 +0200

> version, cipher suite, supported signature algorithms, and key usage.
One might call this a facility intermediate layer to simplify application
coding for "common" cases.
> instead of requiring every application writer to have to reinvent it.
Internal API structures and features do not necessarily need to follow
protocol layers and provide for all options. No problem I think.

Whether it is better to have apis aligned with protocol layers depends
on the protocols, the layer structure, application needs, the temperature
of coffee etc.   Shadokism and/or oversimplification may occur.

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 14 Jun 2010 18:08:24 +0200

> by all versions of TLS to be entirely an application matter.
... and a server doesn't need to have a DNS name at all.

I am not whether I understand (or ever understood) what
SNI is for, at least I'd say that if an application protocol that
uses dns names to identify different application level endpoints
(which is common due to ip address shortage),
and if the application wants to use different TLS protection
mechanisms for each of the endpoints, or , when the
client part would expect this as a possibility, either in general
for the application or in particular for the intended
communication, the  client protocol client needs
a way to communicate the desired dnsname to TLS layer
and to the application entity,  the latter not necessarily in theory
if TLS is always used. SNI is one way to do the first.

A priori, it has nothing to do with certificates,
in SRP/TLS authentication one may not even have such things,
in practice, for at least one not totally unimportant protocol,
the only "visible" effect is the usage of different certificates to
be used for authentication.

an (theoretical) application protocol for example could
require an IP matching address in order to recognize
a server endpoint.

Peter

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 Jun 2010 21:57:50 +0200 (MEST)

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

> 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

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.

> 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