Subject: Re: [TLS] Questions about TLS Server Name Indication extension

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 28 Oct 2009 10:35:06 -0700

On 2009-10-27 23:54 PDT, Peter Gutmann wrote:
> Nelson B Bolyard <[email-masked]> writes:
> 
>> I eagerly await your answers and comments.
> 
> OK, I'll bite:
> 
>> Q1) A client hello's SNI extension is defined such that it may contain 
>> multiple names.
> 
> Intuitively I would say option (a) is the right one, if you're expecting
> to connect to a.foo.com then it doesn't seem to make much sense to say
> you'd also like b.foo.com, c.foo.com, amazon.com, youtube.com, and
> phishme.com.  I'm sure someone can dream up some bizarre corner case
> where you could in theory possibly somehow maybe do this, but in the
> interests of implementation sanity I'd say you're only allowed one name.

I've been informed that the SNI implementation in OpenSSL/mod_ssl/Apache
only honors the first host name in the client hello SNI extension, and
will send an unrecognized_name alert if that first name is unrecognized.

I'm quite willing to follow that example and let that become the de facto
standard.  I just wish the RFC was clear about it, and wonder why the RFC
even allows multiple names to be sent.

>> Q2) if multiple non-synonymous names are included, is the server free
>> to pick any one that it wants?
> 
> This one is resolved by the solution for Q1 above.
> 
>> Q3) Consider the "renegotiation" case, where a client and server
>> negotiate an initial SSL handshake ("in the clear") and then negotiate
>> a second handshake over the encrypted channel established by the first
>> handshake.
> 
> I'd say it's not permitted, it's still the same server and (again) all
> you're going to do is create confusion if you allow new SNI's to be
> inserted at this point.  This answers all the subquestions in one.

Well, consider that there are people who don't want to do client
authentication in the initial handshake because they don't want to send the
client cert over the wire in the clear.  Perhaps they also don't want to
send the virtual host name in the clear, or receive the cert for the
intended virtual host in the clear. So, one could imagine that they do
an initial handshake without any SNI, then a subsequent renegotiation
with SNI.

I'm not advocating that.  I'm merely suggesting that forbidding SNI in
renegotiation might be seen as unnecessarily restrictive in some applications.

> Q4 and 5 get a bit complicated, I'd need to hear a bit more about the 
> circumstances where this might occur...

I received some other email that suggests that my use of the word "scope"
rather than "space" may have made the question unclear, so let me try to
reword Q4 here.

In the context of a physical server acting as multiple virtual server,
is the space of session IDs coming from that server a single space that
encompasses all the sessions for all the virtual servers served by that
physical server?  Or does each virtual server have its own separate space?

If each virtual server has its own separate session ID space, then when
attempting to "resume" or "restart" a TLS session, the client hello MUST
bear an SNI extension to inform the physical server which virtual server's
session ID space contains the given session ID, and each virtual server
potentially has its own separate session store/cache.

OTOH, if there is a single session ID space for the entire physical server
covering all the virtual servers, then each cached session must record and
identify the virtual server with which it is associated.

I'm just wondering which way is the right way to implement session cache
lookup in an SNI environment.

---

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 28 Oct 2009 12:30:27 -0700

> potentially has its own separate session store/cache.

When attempting to resume a TLS session, the client hello must
bear an SNI extension for another reason: it's not guaranteed that
the server will accept the request to resume the session.  This issue
is discussed in Section 2.3 of the TLS extensions RFC 3546.  (The
RFC uses SHOULD instead of MUST.)

> identify the virtual server with which it is associated.

If a client certificate is used in the session, it seems that the
session should only be associated with the virtual server that
authenticated the client certificate, as opposed to the entire
physical server covering all the virtual servers.  I guess there
are multiple ways to accomplish that.

Wan-Teh

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 28 Oct 2009 16:26:05 -0700

>> identify the virtual server with which it is associated.

There's another issue that arises with both the SNI extension and a single
session ID space for the entire physical server.  Which takes precedence?

Consider this scenario:
Physical host has two virtual hosts, A and B.
First handshake:
  client sends SNI with host name A, empty session ID.
  server does full handshake, session ID 1.
Second handshake (renegotiation):
  client sends SNI with host name B and session ID 1,

Session ID 1 implicitly identifies host A.

The server could
A)  Honor the session ID and ignore the SNI.
B)  Compare the host name in the SNI with the host name for session ID 1,
    observe the mismatch, and do a new FULL handshake for host B.
C)  Compare the host name in the SNI with the host name for session ID 1,
    observe the mismatch, and return a fatal error alert.

RFC 5246 seems to suggest choice A.  It says:

   Most current TLS extensions are relevant only
   when a session is initiated: when an older session is resumed, the
   server does not process these extensions in Client Hello, and does
   not include them in Server Hello.

But I tend to lean towards choice B myself.

What do other SNI server implementations do in this case?

---

From: Michael Gray <[email-masked]>
Date: Thu, 29 Oct 2009 10:04:02 +1000

> What do other SNI server implementations do in this case?

A for IBM native SSL.  The Client SNI data is only processed if the session
can NOT be resumed.

Also as an answer to the previous question; we only consider that the
Client has sent a single name in Client SNI request.

Also on previous note <snip> 'because they don't want to send the client
cert over the wire in the clear" <snip>

For what reason would you require a client cert or a host name or a host
certificate to be not treated as public information?  Of course it could be
a good way to cover your tracks if you were up to no good :-)

Mick Gray
IBM

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 28 Oct 2009 17:52:04 -0700

>  client sends SNI with host name B and session ID 1,

I think "renegotiation" should be "resumption".

In this case, the client should not request a resumption
handshake with session ID 1, because the server won't
send a certificate in a resumption handshake, so the
client cannot verify the server has a certificate for host
name B.

The only exception is that the certificate for host name A
has a subject alternative name for host name B.

Wan-Teh

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 29 Oct 2009 18:58:10 +1300

Nelson B Bolyard <[email-masked]> writes:

>In the context of a physical server acting as multiple virtual server, is the
>space of session IDs coming from that server a single space that encompasses
>all the sessions for all the virtual servers served by that physical server?
>Or does each virtual server have its own separate space?
>
>attempting to "resume" or "restart" a TLS session, the client hello MUST bear
>an SNI extension to inform the physical server which virtual server's session
>ID space contains the given session ID, and each virtual server potentially
>has its own separate session store/cache.
>

Ah, I see what you mean now.  Well in general I don't think it's going to be
an issue, the session ID is a 32-byte blob so it's up to the server what it
puts in there, it can include a virtual server ID, cache ID, whatever it wants
in any format it requires.  In other words if the server wants to encode
configuration- or server architecture-specific details in the session ID then
the form and type is up to the server, you don't need an explicit SNI for
this, particularly since the free-form blob accomodates much more than just
the virtual server : cache ID pair that the SNI + session ID handles.

Peter.

---

From: Martin Rex <[email-masked]>
Date: Fri, 30 Oct 2009 00:26:57 +0100 (MET)

>   client sends SNI with host name B and session ID 1,

That client is obviously broken.

>     observe the mismatch, and return a fatal error alert.

If the server supports virtual hosting through SNI, it should
look up the session ID of the client only in the session cache
associated with the hostname A.

If a TLS session resume proposal with and SNI for B arrives,
there will be no cached session with that session ID in the
TLS session cache tied to credential for A, so it must result
in a full TLS handshake.

A server that has different credentials for A and B (and would
use them based on SNI is definitely broken if it agrees to a
proposed resume of a session originally established with A
in a ClientHello that carries an SNI for B, because the server
knows exactly that the server certificate that the client
has for this session is NOT the same certificate that the server
would send in a full handshake for B.  And similiar uncertainty
may apply to availability of a client certificate of even
an already cached client certificate.

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 29 Oct 2009 21:36:43 -0700

> Client has sent a single name in Client SNI request.

Thanks, Mick, for those concise answers.  Sadly, I don't sense that we
have a consensus from among the responses yet, except on the point that
the SNI client hello should only contain one name of each type.

I think that interoperability demands that we standardize these answers.

I predict that we'll end up with these below(which I think match yours)
but I fear that existing implementations differ from these a fair bit.

- Only one name per type is allowed and used in the client hello SNI.

- The session ID space covers all the sessions for the entire physical host
including all the virtual hosts, so by itself, the session ID contains all
the information necessary to determine which virtual host uses the session
with that ID.  It is not necessary to consult the SNI host name to know
which virtual host's session cache to examine to find the session ID.

- The SNI extension is ignored if the session can be resumed based on the
session ID, and no matching/checking is done to ensure that the SNI host
name matches the name in the resumed session, when the session is resumed.

> certificate to be not treated as public information?  

I don't know.  I work on NSS, an open source TLS library that is used in
lots of applications and is discussed in an open mailing list and newsgroup
(mozilla.dev.tech.crypto).  One of the application developers who uses NSS
has this issue, but I don't know why.  I'd guess it's the usual extreme
security p\a\r\a\n\o\i\a\ precautions that have kept me employed. :)

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 29 Oct 2009 21:52:39 -0700

> That client is obviously broken.

Perhaps, but the question is what does the server do about it?

> If the server supports virtual hosting through SNI, 

that's a given for this exercise

> it should look up the session ID of the client only in the session cache 

And it should choose hostname A because why?  Remember that in the above
example, the SNI bears host name B.

> If a TLS session resume proposal with [an] SNI for B arrives,

So, you're proposing that the server should look in the SNI first to see
which host name is there, and use that info to decide which virtual host's
server session cache to examine for the numbered session?  In other words,
each virtual host has its own separate session cache with fully overlapping
spaces of session ID numbers, disambiguated by the SNI host name, yes?
In this model, an SNI would be absolutely required to resume a session that
had been established with an SNI, yes?

> use them based on SNI 

The whole point of SNI is to have different credentials for different
virtual hosts.  If you don't have different credentials for different
virtual hosts, (e.g. if you have a single certificate for all your
virtual hosts) then you don't need SNI.

> is definitely broken if it agrees to a proposed resume of a session
> originally established with A in a ClientHello that carries an SNI for B,
> because the server knows exactly that the server certificate that the
> client has for this session is NOT the same certificate that the server 
> would send in a full handshake for B.

This objective could be accomplished with a single server session cache
that covered the entire physical server and all its virtual servers, IF
the server compared the host name in the SNI with the host name associated
with the session in the cache.  But I see that your proposal definitely
gives precedence to the SNI.  This is quite different than Mick's answer.

---

From: Martin Rex <[email-masked]>
Date: Fri, 30 Oct 2009 16:04:31 +0100 (MET)

> >> session ID space for the entire physical server.  Which takes precedence?

If the SNI made a difference in the server credential when the session
was originally created, then the SNI MUST make the same difference
for resume.  The a requirement for consistency and reproducable behaviour.

If the SNI did not make a difference when the cached session was
originally created (e.g. the server doesn't support SNI), then it
does not need to make a difference on resume.

> Perhaps, but the question is what does the server do about it?

Compensate for the broken client and perform a full SSL handshake.

A broken client is no excuse for inconsistent or non-predictable
server behaviour.  Since most real server limit the size of their
session cache, you will, depending on the load of the server,
not be able to predict at what point the server will have purged
the cached session from his cache and will have to perform a
full TLS handshake.

If that full handshake will result in a TLS session with
substantially different characteristics, or even with a completely
different server credential, then the server behaviour will
effectively become inconsistent and non-predictable if
the server agrees to resume sessions that substantially differ
from other session characteristics specified in the ClientHello.

A server implementation that will behave inconsistent and
non-predictable is always a bad idea.  It does not matter that
the spec fails to discourage or prohibit such a behaviour.
It remains a pretty a bad idea and a sign of a broken server
even when the spec does something stupid like recommending
such inconsistent and non-predictable behaviour.

> example, the SNI bears host name B.

Sorry for my mistake.  A session resume request with SNI B should
be looked up in the session cache associated with SNI B, of course.
(if the server supports SNI).

> server session cache to examine for the numbered session?

Correct.

> In other words,

Correct.

> virtual hosts) then you don't need SNI.

If a server supports SNI, but shares a single credential for several
(or all) virtual hosts, then there would be no consistency or
non-predictability problem if the server shared the TLS session
caches in the same fashion.

In my architecture, the SSL session cache of the server is tied
to the server credential.

If the architecture permits updating the server credentials
while the server is running under full load, then you really want
to be able to flush exactly and efficiently the cached TLS sessions
related to that specific previous credential and leave the rest
of the cached TLS sessions assiciated with other, still unchanged
credentials, untouched.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 30 Oct 2009 09:21:03 -0700

Here's a possible reason for a client to include multiple domain
names in the SNI.  Suppose a user enters "foo.edu" into their
browser.  The browser may decide to send the two names "foo.edu"
and also "www.foo.edu" to the server in an attempt to connect on
the first try, rather than get rejected on the first connection
and have the overhead of retrying.

Even if you disagree that that is a possible scenario, if you want
to restrict what you can do with a protocol there should be a good
reason to do it.  Either it must present a security issue, or it
must cause undue burden on implementers for no benefit.  I don't
see how it is a security issue for the server to look up more than
one name, and there is no burden in adding a simple loop to look
up those names sequentially.  In fact, you already need the loop
to skip any name types you don't recognize, so the issue is whether
you put a break statement in your loop or not.

Mike

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 30 Oct 2009 10:10:43 -0700

The only thing you can count on when resuming a session is the session
ID.  If you have more than one session cache, then you need to be able
to determine solely from the session ID which session cache contains
the session.  I do this by structuring the 32 bytes of the session ID
into a 6-byte cache ID, a 10-byte counter, and 16 bytes of random noise.

The cache ID makes it easy to determine which cache to look in when
trying to locate a session; the counter guarantees uniqueness of session
IDs (the upper 5 bytes are initialized with the creation time); and the
random component makes it unlikely for an attacker to guess a valid
session ID randomly.

My implementation allows virtual hosts to have their own session cache
or to share their cache with any number of other hosts.  Since session
IDs are unique, the benefit to sharing is to share configuration
parameters.  You can specify a limit to the total number of cached
sessions and the expiration time on a per-cache basis.

Mike

---

From: Martin Rex <[email-masked]>
Date: Fri, 30 Oct 2009 19:17:56 +0100 (MET)

> and have the overhead of retrying.

I'm sorry, I don't understand you scenario.

Current implementations of TCP can have only two communication peers,
not three and the TLS handshake works also only with two participants,
server and client.

The client MUST know which of the hostnames was used to open a particular
network connection, so there is NO situation where more than one name
should go into SNI here.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 30 Oct 2009 11:31:05 -0700

The desire seems to be to have a way to first negotiate a secure channel
to a machine, then to perform the intended handshake over this secure
channel to keep the real handshake private.

This could be done by adding a new NameType to the SNI extension.  This
new NameType would let the server know that it is performing a handshake
merely to create a private channel over a public medium like the Internet.
Immediately following the negotiation of this secure connection, the
client would be required to perform the intended handshake.  Note that
the session ID specified by the client in the 2nd handshake would be
empty.  The "name" associated with this name type would most likely be
empty (two zero bytes indicating zero length) since it means "the host
I'm connected to".

Both handshakes could return non-empty session IDs.  Upon resuming the
first session, the client would be at the point where it needed to
renegotiate the session using a valid SNI and empty session ID.
Resuming the second session would get them all the way to the virtual
host.

There are obvious security issues -- a client would need to make sure
that the host it connected to was friendly so when it performs the real
handshake, the information doesn't end up in the wrong hands.  Or perhaps
the security offered is similar to the use of TLS for SMTP where clients
don't necessarily care who the server is, just that their message is
encrypted when sent over the Internet; they rely on the DNS to make sure
they're connected to a real MX for the recipient.

Mike

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 30 Oct 2009 11:39:56 -0700

They could share IP addresses.

But the point is that you and I don't know for certain that there is
no possible requirement for a client to send multiple hostnames, so
imposing a limitation of only one hostname could preclude some future
application from being able to use TLS (without modifications or
private agreement).

If it was hard to implement checking for a match in a list, I'd agree
with you, but literally it is a simple while loop that calls your
lookup function for each name in the SNI extension.

Mike

---

From: Martin Rex <[email-masked]>
Date: Fri, 30 Oct 2009 19:52:42 +0100 (MET)

> sessions and the expiration time on a per-cache basis.

It's perfectly sensible that TLS server composes the TLS session IDs
in a fashion that facilitates cache management and session lookup
(including guaranteed uniqueness when creating new session IDs,
obviating cache collision checks).

Keep in mind, that the security of the sessions do not come from
uniqueness and non-predictability of the session ID, however.
SSL session IDs travel in the clear in the client hello and
their purpose in life is to be re-used "replayed" frequently. :)

In addition to cache management aspects, the TLS server should keep
robustness in mind.  e.g. robustness against TLS clients with
a broken client-side TLS session cache management that will
recklessly propose a TLS session resume for a session (ID) originally
established with Mars to just about every earthling they're asked
to connect to later on.

And before a TLS server checks for existence of a TLS session,
whose session ID is proposed in a ClientHello, it should determine
wheter it would be willing to establish a new session through
a full handshake based on the other information in the ClientHello
and under what conditions it would do so.

If the TLS server finds a TLS session with the proposed session ID
in his cache, it should then use the results from the previous
determination of the ClientHello parameters whether it is OK to
attempt to resume the cached session, or whether it is advised
to perform a full SSL handshake, because of a significant mismatch
of the newly determine session characteristics from those
of the cachend session identified by the client-proposed Session ID.

This is a simple and straightforward robustness principle leading
to consistent behaviour, that will save implementors and consumers
of the technology a lot of time and headaches.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 30 Oct 2009 20:14:33 +0100 (MET)

> They could share IP addresses.

You mean that you client performs DNS-lookup for both names,
determines that they point to the same IP-Address and then
decides to address a single request for both?

How many HTTP Host: Header fields is your client going to send,
and is the semantics for the server defined what to do with
multiple Host: header fields.  We also didn't cover this in
the revised text that urges an application to cross-check
SNI vs. Host: Header fields.

JUST DON'T DO IT.

> application from being able to use TLS (without modifications or

We should not try to fix a problem before we even know that there is a
problem (with limiting ServerNameList to unique members of each NameType).

> lookup function for each name in the SNI extension.

Past experience regularly demonstrates that this is going to result
in broken implementations.

Take the list of client ciphersuites in the ClientHello message for
example.  It was hard to believe for me that there would be broken
SSL/TLS Servers out there that used the ordering/preference of
the ciphersuites in the ClientHello instead of the preference
of the server to pick a common ciphersuites.  At a minimum,
the precendence of the servers preferences over the clients
should be configurable with the servers preferenca/configuration
being the default.

A hardcoded "clients list takes precedence" or a default for this
indicates that the implementor didn't think about the security
implications and may have been to easily misguided by obviously
suboptimal wording in the specification.

Every spec contains errors and suboptimal or misleading wording.
It's _MUCH_ easier to realize the problems when trying to implement
a spec.  So when implementing specs, it is very important to
use common sense when reading it and strive for consistent
and predictable behaviour.

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 30 Oct 2009 12:24:11 -0700

> does not need to make a difference on resume.

RFC 5246 says:

   In general, the specification of each extension type needs to
   describe the effect of the extension both during full handshake and
   session resumption.  Most current TLS extensions are relevant only
   when a session is initiated: when an older session is resumed, the
   server does not process these extensions in Client Hello, and does
   not include them in Server Hello.  However, some extensions may
   specify different behavior during session resumption.

You're saying that SNI is not like "Most current TLS extensions" in that
when an older session is resumed, the server DOES process this extension,
and its behavior is NOT different during session resumption than during
session initiation.

I think that's a legitimate and self-consistent proposal, one of several
that I could envision, which is why I raised this subject.  But as we've
seen in this thread, others (e.g. IBM) clearly have implemented a very
different model.

For the sake of interoperability, I think we need to define a single
standard definition to which we all adhere.

> Compensate for the broken client and perform a full SSL handshake.

IBM's answer was: ignore the SNI and resume session ID 1 with host A,
which seems to be what RFC 5246 says TLS should do for _most_ TLS hello
extensions.  But I agree that we _could_ *define* SNI to not be like
_most_ TLS hello extensions, if we choose.

> server behaviour.  

I agree that, ONCE we all agree that your definition is the right one,
then we agree that the above behavior is that of a broken client.
OTOH, if we end up agreeing that IBM's answer is the right one, then
I don't think we necessarily agree that a client behaving as described above
is necessarily broken.

Regards,
/Nelson

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 30 Oct 2009 12:26:15 -0700

> established with Mars to just about every earthling they're asked

Section 7.2.2 of RFC 5246 concerning Error Alerts handles this.  If
a connection terminates with a fatal alert, the session associated
with that connection MUST NOT be resumed.  So perhaps a server will
try to resume the session once, but it will delete it from its cache
when the handshake fails.  Other servers that don't recognize the
session ID will perform full handshakes.

> and under what conditions it would do so.

I do it the other way around -- after retrieving the session, checks
are made to make sure the cipher suite and compression algorithm are
listed in the ClientHello.  This is mandatory according to section
7.4.1.2.  The only other check I currently have is for the age of the
session to make sure it is fresh enough.

> of the cachend session identified by the client-proposed Session ID.

RFC 4366 states:

    -  If, on the other hand, the older session is resumed, then the
       server MUST ignore the extensions and send a server hello
       containing none of the extension types.  In this case, the
       functionality of these extensions negotiated during the original
       session initiation is applied to the resumed session.

Mike

---

From: Michael Gray <[email-masked]>
Date: Sat, 31 Oct 2009 05:32:23 +1000

> and have the overhead of retrying.

That is an interesting use case scenario.  Have you actually observed a
browser doing this?  I have not so far.  What sort of risk is there for the
Client if the browser starts doing this sort of thing?  On the other hand I
recommend to our consuming products to have the flexibility at the Server
side i.e. the Server is configured with multiple Server Names that point to
a common certificate which supports multiple DNS names.  For example say a
Server is hosting 123.com, abc.com and xyz.com, then the TLS Server can be
configured with:

abc.com > abc.com_certificate
www.abc.com > abc.com_certificate
123.com > 123.com_certificate
www.123.com > 123.com_certificate
...

You can imagine a number of variations on the above when you see some
Server Certificates with a large number of SAN DNS names.

The TLS Server then selects the correct certificate based on the TLS Client
SNI request.  The Application Server itself then asks the TLS Server what
certificate was used to establish the connection so that the Application
Server can select the correct data base etc etc.

> you put a break statement in your loop or not.

If there is consensus on this and no security risk then we would implement
it as an option as I do not see that the RFC prevents this.

Mick Gray
IBM

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 30 Oct 2009 12:51:45 -0700

> SNI vs. Host: Header fields.

I was merely trying to come up with a possible scenario in which
you could hypothetically send two hostnames in the SNI extension,

> problem (with limiting ServerNameList to unique members of each NameType).

People ARE trying to "fix" the extension by imposing a restriction
that is not currently present in the spec.  I maintain that there
is no savings of effort implementing the spec as is, versus imposing
a one-name-per-name-type restriction.

You still need to iterate through the list (since you may not recognize
the first name type), and look up the names of types you do recognize.
To implement one-name-per-name-type, you need to add a "break" statement
to stop processing the list once a lookup failure occurs.  So the code
to implement one-name-per-name type is actually MORE WORK than doing
it the way the spec is written today.  Oh, and you now have a bug since
you broke out of the loop before finding all the other name types in the
list.

> should be configurable with the servers preferenca/configuration

The client ultimately overrules the server since it only has to offer
those cipher suites it is willing to negotiate.  The server can choose
whichever it likes, but only from the list it receives.  A client can
send a single cipher suite if it desires only that one.

> suboptimal wording in the specification.

I don't see any issue other than performance.  A server will simply
refuse to negotiate any cipher suite that doesn't match its security
needs.  If it negotiates RSA_WITH_RC4_MD5 and that doesn't provide
enough security, then whoever configured the list of allowable cipher
suites can only blame themselves, not the client.

> and predictable behaviour.

I've implemented lots of specs, so I agree with you that clarity is
important.  It is just as easy to say, "Note: there may be any number
of names of a particular name type" as it is to say, "There MUST NOT
be more than one name of a particular name type."

If the more restrictive version led to considerably simpler coding,
I'd readily agree with changing it, but as I've pointed out above,
there is no simplification of the code.

Mike

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 30 Oct 2009 13:25:40 -0700

I think that it would be a good change to require a client to include the
same SNI extension when resuming a session.  The complexity of my code to
find a session among multiple session caches is far greater than it would
have been if I could have relied on the hostname from SNI.

RFC 4366 currently disallows using SNI to resume:

I'd be in favor of changing RFC 4366 to mandate providing the same SNI when
resuming a session, if nothing will break because of it.

Mike

---

From: Martin Rex <[email-masked]>
Date: Fri, 30 Oct 2009 21:31:16 +0100 (MET)

> session ID will perform full handshakes.

That appears to strict to me.  I would make the server delete
a session from his cache when an attempted resume results in a failure.
I can not currently think of an error (i.e. fatal alert) after a
mutual successful finished message verification that should cause
the server to flush the affected ssl session from his session cache.

> session to make sure it is fresh enough.

An actual implementation will probably involve certains decisions
based more on personal taste than factual requirements.

The most important issue is consitent and predictable/deterministic
behaviour of the server, even when broken clients are involved.

>        session initiation is applied to the resumed session.

Correct, but you should not read it backwards.

If the server agrees to resume (for whatever reason), the other
accompanying information in the ClientHello should NOT be used to
modify that cached session.

Does rfc-4366 say anywhere that the server _must_not_ involve the
parameters and extensions present in a ClientHello in his decision
to resume or not resume a cached SSL session when the client
includes a session id in the ClientHello handshake message?

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 30 Oct 2009 17:40:19 -0700

> the server to flush the affected ssl session from his session cache.

The main one is a BAD_RECORD_MAC alert if decryption fails, padding
is wrong, the MACs don't match.  The record version could be wrong;
the record could be greater than 2^14 bytes.  None of these things
should happen under normal circumstances, so you have to assume an
attack is underway.

> includes a session id in the ClientHello handshake message?

Aside from what I quoted, I don't believe so.  The server can decide
not to resume a session for whatever reason it wants.  In fact there
is no requirement to support session caching at all.  What the text
means is that IF the server agrees to resume the session, the resumed
session will have the same features as the original according to the
extensions in the original handshake, regardless of the extensions in
the ClientHello for the resumed session.

Mike