Subject: [TLS] Other S->C signaling methods

From: Stefan Santesson <[email-masked]>
Date: Tue, 24 Nov 2009 15:44:08 +0100

I have some more crazy ideas to throw into the bucket for the S->C
signaling.

We have been pretty locked on trying to squeeze the 1 bit of information
form the server (I support secure renegotiation) in any of the existing
fields of the handshake, or the server hello.

The main reason we don¹t want to use extensions is valid for C->S, since we
don¹t want to break servers that can¹t handle extensions.
But the same rationale is not necessarily true for S->C signaling since:

1. The client has already declared that it is patched (through magic ciphe
suite), and should be able to accept whatever the server sends back as
proof. 
2. The server should be able to add whatever data to its handshake message
structure once it has accepted that the client is patched.

So for S->C, as an alternative to abuse current fields, I see a number of
other potentially valid alternatives:

1. Return an RI extension, even if one was not sent by the client. The
problem is that this is a violation of the TLS protocol. It is illegal to
add a server extension that was not present in the client hello. But except
that problem, it might work.
2. Extend the Server Hello with a new secure renegotiation confirmation
value/flag. 
3. Define a new handshake message that is sent right after ServerHello. This
handshake message would be sent back to the client only of the magic
CipherSuite was sent by the client, confirming that the server supports
updated finished messages. I¹m not sure whether this would cause any serious
problems, but in case it doesn¹t, this is the one I like best.

/Stefan

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Nov 2009 16:32:42 +0100 (MET)

> structure once it has accepted that the client is patched.

Theoretically you are correct.  We're doing a negotiation and
in the S->C reply, that is only sent when the client indicated that
it will understand the answer, we could define a whole new protocol.

But in practice, we want the fix to change as little as possible
and work in all existing usage scenarios.  That certainly includes
those scenarios that are actively using TLS extensions.

IMHO, that means we should make it fit into SSLv3 ServerHello
(which is a part of ExtendedServerHello)

Allowing servers to return a fixed octet string that represents
a correctly encoded single extension in the ServerHello might
be an option -- but this is something that we can do only once.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 24 Nov 2009 16:46:46 +0100

Martin,

> (which is a part of ExtendedServerHello)

Not saying that you are wrong, could you motivate this a bit further.

E.g. Why would it be easier (and less ugly) for a server/client to mix with
the protocol version bits versus sending and parse a new small handshake
message after the server hello?

/Stefan

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Nov 2009 17:16:09 +0100 (MET)

> message after the server hello?

The addition of a new handshake message will likely impact
the entire protocol state engine (OpenSSL architecture comes to mind),
one might have to change the record layer, the message pipelining,
it will become visible in the per-handshake-message callbacks.

There may be a lot of other things I haven't thought of,
but I'm really worried that this may break assumptions of
callers of the TLS applications.  I'm worried about breaking
existing usage scenarios and consumers of TLS, because that may
be a real problem in getting a patch deployed quickly.

When changing data in the _network_encoding_ of a handshake message
only, then it should be fairly easy to contain the changes to
that code that composes this particular handshake message
(server-side for ServerHello) and that code that parses this
particular handshake message (client-side for ServerHello).

And I firmly believe, the negotiation of SSL/TLS should happen inside
ClientHello & ServerHello  (or ExtendedClientHello&ExtendedServerHello).

Personally, I'm much less considerate to middle boxes like firewalls
that might have to adapt slightly if they're totally entangled with
each and every bit of a ServerHello.  These beast are likely to be
still under maintenance, and they have to adapt all the time.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 25 Nov 2009 18:41:27 +1300

Stefan Santesson <[email-masked]> writes:

>problem is that this is a violation of the TLS protocol. It is illegal to add
>a server extension that was not present in the client hello. But except that
>problem, it might work.

This shouldn't be so bad, the client has already indicated via the magic
cipher suite that it'll know how to deal with this, so it shouldn't break
anything.

>updated finished messages. I=B9m not sure whether this would cause any
>serious problems, but in case it doesn=B9t, this is the one I like best.

It should be OK for the same reason that the RI extension is, but I don't know
if it's worth defining a new message type just for this, an RI ext might be
less overhead to implement.  It really depends on how many implementations
support extensions already...

Peter.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 25 Nov 2009 09:11:32 +0100

So how would this work as a middle way between the proposals:

C->S Signaling:
 1) Client MUST include either the magic CipherSuite or RI extension or both
 2a) TLS compatible server MUST support magic CipherSuite and RI.
 2b) SSLv3 servers MUST support magic CipherSuite and MAY support RI

S->C Signaling:
 1) Servers MUST include RI

Finished calculation:
 1a) The RI of the serverHello holds necessary data from previous handshake;
or
 1b) Finished calculation is modified to include virtual handshake messages

This would allow the current implementation of RI (more or less) but also
allow safe fallback when connecting to servers that can't parse extensions.

All servers must include the bits of an RI extension in the server Hello,
but that should be a lot easier than to implement full extension handling
for receiving RI from the client.

This would at least save us the ugliest hacks when it comes to S->C
signaling.

/Stefan

---

From: Yoav Nir <[email-masked]>
Date: Wed, 25 Nov 2009 11:39:18 +0200

> 2b) SSLv3 servers MUST support magic CipherSuite and MAY support RI

How about:
2a) TLS 1.1+ compatible server MUST support magic Ciphersuite and RI
2b) SSLv3 and TLS 1.0 servers MUST support magic Ciphersuite and MAY support RI

> 1) Servers MUST include RI

Since this violates the TLS specs, I think servers MUST include RI only if the client included RI. Otherwise, they MUST use the tbd "other signal"

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 25 Nov 2009 11:05:05 +0100

> 2b) SSLv3 and TLS 1.0 servers MUST support magic Ciphersuite and MAY support

Yes. That struck me as the right thing to do right after posting.

> Since this violates the TLS specs, I think servers MUST include RI only if the
> client included RI. Otherwise, they MUST use the tbd "other signal"
> 

Well, it would gracefully violate this rule of TLS. But it would be
announced so it should not break anything... Or would it?

It seems that we need to stretch something to make this work, and the
question is what stretch is least ugly but still implementable.

The big downside with abusing a bit of a current defined field (version or
compression method) is:
 1) Hopefully we will never have to do this type of fix again, but if we do,
then what bit should we abuse next time around.
 2) It obfuscates the protocol, makes it harder to understand and more
likely to attract implementation errors in the future.

/Stefan

---

From: <[email-masked]>
Date: Wed, 25 Nov 2009 13:53:14 +0100

Yoav Nir wrote:

> Since this violates the TLS specs, I think servers MUST include RI
> only if the client included RI. Otherwise, they MUST use the tbd
> "other signal"

The renegotiation-fix RFC will anyway have "Updates: RFC 5246" on the
cover page, so it could (if the WG so chooses) relax this requirement
in the current TLS specs.

Best regards,
Pasi

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 25 Nov 2009 13:12:59 +0000

> announced so it should not break anything... Or would it?

Personally I wouldn't mind this at all. Yes it is breaking the rules of the TLS
spec but I'd prefer that to the other hacks (including the few I suggested). For
that specific case we could require the extension be fixed (meaning it could be
treated as an opaque blob to compare/add) to simplify implementation.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Nov 2009 15:34:18 +0000

Apologies in advance if this was already dismissed, its
hard to keep track of all the options offered already.

Another option for older versions that don't use RI.

How about a new server_hello_done_patched HandshakeType
value?

S.

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Nov 2009 17:43:42 +0100 (MET)

> How about a new server_hello_done_patched HandshakeType

We don't have ServerHelloDone in TLS session resume
(initial handshake on a connection).

If we are sure to make it a session property on the full
handshake that created this session (independent whether
initial or renegotiation), it might work.

I'm not sufficiently familiar with modified TLS handshakes,
to make an assesment for them (didn't EAP use a modified handshake)?

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 25 Nov 2009 14:22:48 -0800

> 2b) SSLv3 and TLS 1.0 servers MUST support magic Ciphersuite and MAY support RI

Why would you separate TLS 1.0 servers from TLS 1.1+ ?

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Nov 2009 23:34:34 +0100 (MET)

> Why would you separate TLS 1.0 servers from TLS 1.1+ ?

Maybe because a large number of TLS 1.0 servers do not support TLS extensions
(rightly so), they're just extensions-tolerant.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 25 Nov 2009 23:34:50 +0100

I think the rule set posted by Michael is better.

The client may not know what version of TLS the server will choose when
sending it's hello, so a generic rule of C->S signaling seems more
appropriate.

/Stefan

On 09-11-25 11:22 PM, "Nelson B Bolyard" <[email-masked]> wrote:

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

---

From: Robert Relyea <[email-masked]>
Date: Wed, 25 Nov 2009 15:33:45 -0800

> (rightly so), they're just extensions-tolerant.
er, a small number of incorrectly coded TLS 1.0 servers do not support
TLS extensions.
A large number of TLS 1.0 servers do, and have done so for a long time.
A *large* number of TLS 1.0 clients already send extensions today.

If your TLS 1.0 code does not handle extensions, please fix it.

thanks,

bob

---

From: Martin Rex <[email-masked]>
Date: Thu, 26 Nov 2009 00:48:56 +0100 (MET)

> If your TLS 1.0 code does not handle extensions, please fix it.

Your statement is at least ambiguous.

TLSv1.0 (rfc-2246) and TLSv1.1 (rfc-4346) both do clearly *NOT* support
TLS extensions, they're both _only_ extensions-tolerant.

TLSv1.2 is the first protocol version of TLS that supports
TLS extensions in the base spec.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 25 Nov 2009 18:07:42 -0600

> If your TLS 1.0 code does not handle extensions, please fix it.

Easy enough. But what if it's not your code?

Pretend you're an IT admin who just rolled out the patch to every PC in
the company last night, and today the groundskeeper opens a support
ticket because he can't access the management interface to the automated
lawn sprinkler system.

You say "please fix it".

"What, the sprinklers?" he says. "They're working fine. It's just since
you rebooted the PC last night the winder just gets stuck there waitin'
on the sprinkler login page."

You say "please fix it".

"I thought that was your job. Besides, I got a truckload of mulch and
and a work crew to spread it coming in 30 minutes. If I don't change the
timing on them sprinklers they're going to cut on right when they get
working. You'll have a dozen muddy landscapers on your hands though, and
they ain't got no sense of humor. I'll just tell em you're gonna fix it."

You say "please fix it".

"All right, all right. I'll try calling the sprinkler company. Won't do
any good though, they got rid of all the people who knew what they were
doing so we stopped paying maintenance on that thing at the beginning of
the year. They won't talk to us since. Planning to replace it in the
fall, ya see."

Stay tuned next week for the hilarious conclusion of "Muddy MIS Mixup".

- Marsh

---

From: Nelson B Bolyard <[email-masked]>
Date: Wed, 25 Nov 2009 16:18:10 -0800

> If your TLS 1.0 code does not handle extensions, please fix it.

Bob, when you wrote "support", I suspect you meant "tolerate".  Right?

---

From: Robert Relyea <[email-masked]>
Date: Wed, 25 Nov 2009 16:34:13 -0800

> Easy enough. But what if it's not your code?

My statement was to the TLS 1.0 coder, not to the IT administrator.

It was on behalf of that IT administrator that I make the statement. It
was the IT administrator that we had in mind when we implemented
fallback solutions for extension intolerant servers.

In this case, the IT administrator needs to eventually get a patch for
*all* of his servers and clients.

Designing systems assuming that the new clients will not send TLS
extensions --- event TLS 1.0 clients is already ignoring the real world.
Client send extensions. They will continue to do so. TLS 1.0 servers
already parse these extensions. RI is just one more on the list.

Clients already tiptoe around the broken implementations. This is not
new. RI does not cause it, it is already happening. These
implementations will have to be patched at some point anyway, they may
as well be patched to at least be tolerant of extensions.

bob

---

From: Kyle Hamilton <[email-masked]>
Date: Thu, 26 Nov 2009 00:33:53 -0800

We've already heard that Microsoft IIS sends an extension in the case
of working with a particular cipher, even in the event that the client
didn't request the extension.  (It contains the information necessary
to work with the cipher suite.)

If this protocol revision is documented as having the client send a
special cipher suite tag, AND then the server will send some extra
data after the ExtendedServerHello no matter what version of the
protocol is in use, then anyone who implements the cipher suite tag
should have also implemented the check for server support.

Now, I'm going to turn this around a bit: what if a client sends that
it knows how to do the new renegotiation, and then doesn't?  How long
would it take for the server to catch on?  Is there an attack vector
here?  (Would the server want to immediately initiate a renegotiation
to verify?)

-Kyle H

---

From: Martin Rex <[email-masked]>
Date: Thu, 26 Nov 2009 16:55:51 +0100 (MET)

> to work with the cipher suite.)

*I* didn't say that.

There are two test TLS servers on the Internet that will return
an unsolicited ServerHelloExtension when a particular cipher suite
is negotiated.

One of them replies with this:
Server: Apache/1.3.34 (Debian) mod_ssl/2.8.25 OpenSSL/0.9.8e

(I can't reach the other from our internal network).

WinXP and W2K3 do not seem to allow sending ClientHelloExtensions
to Cryptographic Service Providers, but it seems that _somehow_
they allow to receive unsolicited ServerHelloExtensions.

-Martin