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

Stefan Santesson <stefan@aaa-sec.com> Wed, 25 November 2009 10:05 UTC

User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Wed, 25 Nov 2009 11:05:05 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Yoav Nir <ynir@checkpoint.com>
Message-ID: <C732BFE1.6A4D%stefan@aaa-sec.com>
Thread-Topic: [TLS] Other S->C signaling methods
Thread-Index: Acptsy1zhxwZfDECTfuC9le7mA74RgAA5Ur5
In-Reply-To: <EE250978-F894-4464-88D4-B308719C10DD@checkpoint.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Other S->C signaling methods
Precedence: list

On 09-11-25 10:39 AM, "Yoav Nir" <ynir@checkpoint.com> wrote:

> 
> On Nov 25, 2009, at 10:11 AM, Stefan Santesson wrote:
> 
>> 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
> 
> 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
> 

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

>> S->C Signaling:
>> 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"
> 

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

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

[TLS] Other S->C signaling methods Stefan Santesson
Re: [TLS] Other S->C signaling methods Martin Rex
Re: [TLS] Other S->C signaling methods Stefan Santesson
Re: [TLS] Other S->C signaling methods Martin Rex
Re: [TLS] Other S->C signaling methods Peter Gutmann
Re: [TLS] Other S->C signaling methods Stefan Santesson
Re: [TLS] Other S->C signaling methods Yoav Nir
Re: [TLS] Other S->C signaling methods Stefan Santesson
Re: [TLS] Other S->C signaling methods Pasi.Eronen
Re: [TLS] Other S->C signaling methods Dr Stephen Henson
Re: [TLS] Other S->C signaling methods Stephen Farrell
Re: [TLS] Other S->C signaling methods Martin Rex
Re: [TLS] Other S->C signaling methods Nelson B Bolyard
Re: [TLS] Other S->C signaling methods Martin Rex
Re: [TLS] Other S->C signaling methods Stefan Santesson
Re: [TLS] Other S->C signaling methods Robert Relyea
Re: [TLS] Other S->C signaling methods Martin Rex
Re: [TLS] Other S->C signaling methods Marsh Ray
Re: [TLS] Other S->C signaling methods Nelson B Bolyard
Re: [TLS] Other S->C signaling methods Robert Relyea
Re: [TLS] Other S->C signaling methods Kyle Hamilton
Re: [TLS] Other S->C signaling methods Martin Rex