Subject: [TLS] Proposed changes to draft-ietf-tls-rfc4366-bis

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 9 May 2010 22:05:10 -0700

Below are proposed changes to resolve open items with
draft-ietf-tls-rfc4366-bis.  If these are OK then we should submit a new
revision and move the document forward.  

Add to Section 3 after the pseudo-code structure to resolve possible
ambiguity with multiple names of the same type:

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

Add to section 3 before the last paragraph to clarify session resumption
behavior:

"When the server resumes a session, the server_name extension is
ignored." 

TO clarify use of SHA-1 without agility:

Section 11.3:
ADD:
   This extension continues to use SHA-1 (like in RFC 4366), and does
   not provide algorithm agility. The property required of SHA-1 is
   second pre-image resistance, not collision resistance.
   Furthermore, even if second pre-image attacks against SHA-1 are
   found in the future, an attack against client_certificate_url 
   would require a second pre-image that is accepted as a valid
   certificate by the server, and contains the same public key.

Section 11.4:
OLD:
   The use of the SHA-1 certificate hash alternative ensures that each
   certificate is specified unambiguously.  As for the previous
   extension, it was not believed necessary to use both MD5 and SHA-1
   hashes.
NEW:
   The use of the SHA-1 certificate hash alternative ensures that each
   certificate is specified unambiguously. This context does not
   require a cryptographic hash function, so the use of SHA-1 is
   considered acceptable, and no algorithm agility is provided.

---

From: <[email-masked]>
Date: Mon, 10 May 2010 13:30:48 +0200

Joseph Salowey wrote:

> draft-ietf-tls-rfc4366-bis.  If these are OK then we should submit a
> new revision and move the document forward.
> 

It might be useful to also say that this is a change to RFC 4366
(otherwise, we're likely to get a DISCUSS asking about this :-). 
Something like:

   Note: Earlier versions of this specification permitted multiple
   names of the same name_type. In practice, current client
   implementations only send one name, and the client cannot
   necessarily find out which name the server selected. Multiple names
   of the same name_type are therefore now deprecated.

(the other proposed changes looked OK to me, too)

Best regards, 
Pasi

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 14 May 2010 22:21:50 -0400

There having been no objections to the changes posted at the beginning
of this thread, I've gone ahead and made them.

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

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 14 May 2010 20:02:03 -0700

> of this thread, I've gone ahead and made them.

Sorry, I've been busy.  One of the things added was:

    Add to section 3 before the last paragraph to clarify session
    resumption behavior:

    "When the server resumes a session, the server_name extension
    is ignored."

I have not yet done it, but I plan to have my session resumption
logic look at the SNI to see if it matches the name used for the
cached session.  If they don't match, a full handshake will be
completed.  We already have to verify that TLS version, cipher
suite, and compression method are compatible with the hello
parameters.  I don't see why the SNI is any less important.

Does the above text suggest that my plan would be non-compliant?

Thanks,

Mike

---

From: Marsh Ray <[email-masked]>
Date: Fri, 14 May 2010 22:56:24 -0500

>    "When the server resumes a session, the server_name extension

Conversely, the act of considering (i.e., not ignoring) the SNI
prohibits the server from resuming the session.

So this wording would seem to eliminate the possibility of having
multiple TLS server stacks selected by SNI.

Might rule out some interesting "reverse" proxy hardware on a
technicality. Or, more likely, the rule would just be ignored if the
design works in practice.

- Marsh

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 16 May 2010 21:43:08 -0700

This clarification is consistent with existing text in the draft and in
RFC 4366. 

" Note also that all the extensions defined in this section are
   relevant only when a session is initiated. ... 

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

Joe

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael D'Errico
> Sent: Friday, May 14, 2010 8:02 PM
> To: Donald Eastlake
> Cc: [email-masked]
> Subject: Re: [TLS] Proposed changes to draft-ietf-tls-rfc4366-bis
> 
> Donald Eastlake wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 16 May 2010 22:30:01 -0700

I understand the mechanics are that the server doesn't send the
extensions when it's resumed a session.

My question is whether the spec. disallows taking the SNI into
consideration when deciding whether to resume or not.  Suppose
my server handles foo.edu and bar.org at the same IP address
and uses SNI to determine which set of certificates and options
to choose from.

A client might establish a session using SNI=foo.edu.  Later,
it may try to resume that session, but send SNI=bar.org.  Which
should take precedence?  The client may cache sessions based
solely on the IP address and think that it can reuse any session
it's established on that machine in the past.

What if foo.edu doesn't care so much about security and just
wants all connections to work, so its cipher suite list is huge
and it doesn't care if RI is sent, etc.  But bar.org has strong
security and privacy requirements, so its cipher suite list is
short and contains only the best crypto available, and RI is a
must even for initial handshakes.

Would it make sense for the server to resume the old session
from foo.edu and hand it off to the bar.org application?  I'd
say absolutely not.  So in my software, I plan to check for a
match of the SNI prior to allowing a session to be resumed.

I would hate for this to be considered "illegal."

Mike

---

From: Martin Rex <[email-masked]>
Date: Mon, 17 May 2010 15:21:42 +0200 (MEST)

> This clarification is consistent with existing text in the draft and in

The way it is written appears somewhat misleading, and the resulting
change to 4366 indicates that we need to come up with a better description.

> Michael D'Errico wrote:

Your intended behaviour sounds perfectly fine and sensible.

> > Does the above text suggest that my plan would be non-compliant?

No.  Your intention is to determine whether a suitable cached session
exist for resumption.  Once you have determined that, you resume without
SNI affecting the characteristics of the resumed session.

But your confusion suggests that this should probably be rephrased 
in order clarify what is meant.

There are two entirely seperate issues that ought to be distinguished.

(1) criteria which the server considers in his decision whether to
    resume a TLS session from the cache by performing an abbreviated
    TLS handshake for the TLS session ID proposed by the TLS client in
    the ClientHello handshake message.

(2) effects of parameters in ClientHello (regular or through extensions)
    on the characteristics of the established TLS session.

What Joe an the new text says is only about (2).  When the server decides
to resumt a TLS session from cache, then it must be resumed as-is, none
of the parameters or extensions in the ClientHello is allowed to modify
the characteristics of the resumed TLS session.

(1) is a totally different beast.  Whether or not the server resumes a
TLS session proposed by the TLS client is completely at the
discretion of the server.  IMHO, it makes perfect sense for the
server to check whether the attributes that the client requests
through all those parameters in regular ClientHello plus TLS extension
actually match the characteristics of proposed cached session,
and to go through a full TLS handshake if they don't.
A server can also expire a session from his session cache whenever
it sees a need to do so.

In some implementations, the TLS session cache may be shared among
several processes on a host, not just a single application that tries
to offer virtual hosting with TLS through the server name indication (SNI)
TLS extension.  That correct client implementations shouldn't be
proposing to resume TLS sessions across "virtual hosts" boundaries is
not relevant for the server's decision.  The server should not try to
make any assumptions on client desire or behaviour, but instead act
deterministically based on the parameters in the supplied ClientHello
handshake message.

-Martin

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 17 May 2010 08:42:24 -0700

I do not think the behavior that Mike describes is strictly compliant
with RFC 4366 as it states that the SNI should be ignored when resuming
a session. From an interop point of view I think it is important to
clarify that the server does not use the SNI extension in the look-up
the session ID in the session cache.  If the session is resumed and
client presents an SNI extension in the resumption attempt it should get
the same result as if it did not.  The client should not attempt to use
a different SNI in the resumption as it is ambiguous.  

How about the following text:

"When the server resumes a session, the server_name extension is ignored
and not used in the lookup of the session in the session cache.  If the
session is resumed, the server will always use the server name
associated with the cached session. The server MUST NOT include a
server_name extension in the server hello. When resuming a session the
client MUST NOT use a different server name than the one used in
establishing the original session.  The client MAY omit the server_name
extension during session resumption. " 

Joe

> From: Martin Rex [mailto:[email-masked]]
> Sent: Monday, May 17, 2010 6:22 AM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 17 May 2010 09:38:22 -0700

Joseph Salowey (jsalowey) wrote:
> a session.

Right.  And I think that statement is a problem which should be
clarified.

> From an interop point of view I think it is important to

I agree that the client should not attempt to use a different SNI when
resuming a session.  In fact I'd say it MUST NOT.

But when a server is presented with an SNI and a cached session, why
wouldn't the server be allowed to check for consistency?  In fact, by
restricting a server to not be allowed to check, you are compromising
the security of the domain listed in the SNI.

> extension during session resumption. " 

I think part of the problem is that you are viewing SNI as an optional
feature useful only for convenience.  In my software it is critical to
the entire operation.  You can set up any number of virtual servers,
each of which has its own collection of certificate chains and keys,
options (such as whether to allow renegotiation, whether to request a
client certificate, etc.), and a list of domain names that map to the
virtual server.

When the SNI is received, it is used to figure out which virtual server
the client wants to connect to.  Once the particular virtual server is
chosen, all of the parameters including list of allowed cipher suites
and other options are installed.

So when a client offers to resume a session for one of my virtual
servers, but has also included an SNI for a different virtual server,
it is clear that it's either a mistake or possibly even malicious.

In my code, I've decided that the SNI is more important, so the session
is not resumed even if it is still in the session cache.  Thus a full
handshake occurs using the SNI from the client hello, and the client
ends up talking to the correct virtual server.

Mike

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 17 May 2010 09:59:20 -0700

> From: Michael D'Errico [mailto:[email-masked]]
> Sent: Monday, May 17, 2010 9:38 AM
> Cc: [email-masked]; [email-masked]; [email-masked]
[Joe]  If the server is always going to use the name that is cached then
the name is consistent.  It's not clear that the consistency check adds
anything.  The text below does restrict the client to not change the
SNI, so if you do the consistency check it should not cause interop
problems with compliant clients.   I think we could explicitly allow the
server to perform a consistency check, but that's not quite the same as
the ignore text that is in 4366.   

> > "When the server resumes a session, the server_name extension is
ignored
> ends up talking to the correct virtual server.
[Joe] From this description it sounds like we need to make a bigger
change to the section to accommodate this behavior.  What happens if the
client does not present an SNI during resumption?  Will this cause a
problem contacting the correct virtual server?  Is the SNI required by
your implementation during session resumption.  

> >>> This clarification is consistent with existing text in the draft
and
> > in
> >> to offer virtual hosting with TLS through the server name
indication
> > (SNI)

---

From: Martin Rex <[email-masked]>
Date: Mon, 17 May 2010 19:11:17 +0200 (MEST)

> with RFC 4366 as it states that the SNI should be ignored when resuming

I would really like to you distinguish the details more carefully.

"ignored when resuming a session" is something that applies
_after_ the server's decision to resume a proposed TLS session.

> the session ID in the session cache.

It is just the opposite.  If a Server _supports_ SNI, it ought to make
the chosen value from the previous handshake part of the cached TLS session,
and re-validate any SNI values supplied by the client in ClientHello
on every session resumption.

>
> If the session is resumed and client presents an SNI extension in the
> resumption attempt it should get the same result as if it did not.

Full agreement here.

>
> The client should not attempt to use a different SNI in the
> resumption as it is ambiguous.  

Although I'm also in full agreement on the client's behaviour,
this ought not to have any relevance for the server's decision.
The server is supposed to act on data that is actually present in
ClientHello.  The server should not try to guess what the client
may have desired and potentially mis-represented in ClientHello params.

> extension during session resumption. " 

I'd like to see instead something more like this:

"If a server implements _and_ confirms the use of a server_name extension
 proposed by a TLS client on a full TLS handshake, then the server MUST
 validate the contents of the server_name extension on all attempts of
 the TLS client to later resume this TLS session from the TLS session
 cache in an abbreviated handshake.  If a validation is necessary,
 and that validation fails, the server MUST perform a full TLS handshake.

 TLS clients that want to propose TLS session resumption, SHOULD provide
 the same parameters in ClientHello (including TLS extensions) as in the
 original handshake, because the server is supposed to validate these
 parameters against the characteristics of the cached session from the
 original full TLS handshake, and the server is supposed to perform
 a full TLS handshake instead of a TLS session resumption if that
 validation of the ClientHello parameters determines that it will
 result in a TLS session with different characteristics."

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 17 May 2010 11:40:22 -0700

Joseph Salowey (jsalowey) wrote:
>> [snip]

I accommodate an empty SNI by allowing the configuration of a
default virtual server.  When there is no SNI sent by the client
or if it doesn't match anything, the default is selected.

The case where a client attempts to resume a session without
sending an SNI is a problem for the client to fix.  It can not
assume the session will be resumed, so it isn't providing enough
information to the server.

I just checked my code and if the client omits the SNI on resume,
it will force a full handshake using the default virtual server
(if configured).

Mike

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 17 May 2010 22:05:30 -0700

So while I think what you say below seems reasonable, the "ignoring the
SNI on a resumed session" in section 3 of RFC 4366 could be interpreted
not to allow this behavior.  In your implementation the server uses the
SNI during the process of resolving the session ID to a session.  Are
others in favor of clarifying the specification to support this? 

In order to clarify this behavior we would change the session resume
behavior for SNI to something like:

"When the server resumes a session, the server_name extension may be
used in the lookup of the session in the session cache.  The client MUST
include the same server_name extension during session resumption as it
did in the full handshake that established the session. If the
server_name extension differs from what was included in the original
handshake the server MUST NOT allow the session to be resumed.  Instead,
it proceeds with a full handshake to establish a new session. When
resuming a session, the server MUST NOT include a server_name extension
in the server hello." 
   
Text at the end of section 1.1 will need to change to add SNI as an
exception.

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 18 May 2010 08:50:14 -0700

> resuming a session, the server MUST NOT include a server_name extension

Your proposed text looks good.

Mike