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

Yoav Nir <ynir@checkpoint.com> Wed, 25 November 2009 09:39 UTC

From: Yoav Nir <ynir@checkpoint.com>
To: Stefan Santesson <stefan@aaa-sec.com>
Date: Wed, 25 Nov 2009 11:39:18 +0200
Thread-Topic: [TLS] Other S->C signaling methods
Thread-Index: Acptsy1zhxwZfDECTfuC9le7mA74Rg==
Message-ID: <EE250978-F894-4464-88D4-B308719C10DD@checkpoint.com>
References: <C732A544.6A39%stefan@aaa-sec.com>
In-Reply-To: <C732A544.6A39%stefan@aaa-sec.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Other S->C signaling methods
Precedence: list

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

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

> 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