Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt

This discussion seems to really be about enforcing the following policy:

If the client can speak TLS 1.X but the "network" (middlebox) only 
allows TLS 1.Y, then, even though the server will happily negotiate TLS 
1.Y with other clients, it will reject this client and will not allow it 
to connect from inside this network.

Organizations often enforce weird and misguided policies on their users, 
e.g. forcing them all to use IE6 so that "legacy applications" do not 
need to be upgraded. Mind you, those older browsers only speak older 
SSL/TLS versions and *their* connections will still go through! 
Employing such middleboxes is just another policy of this type. Is it 
really our business to counteract the organization's policy?

Thanks,
	Yaron

On 09/25/2013 07:38 PM, Michael D'Errico wrote:
> Adam Langley wrote:
>> On Wed, Sep 25, 2013 at 7:03 AM, Bodo Moeller <bmoeller@acm.org> wrote:
>>> So maybe the right fix to this kind of problem is to adapt an idea from
>>> draft-rescorla-tls-version-cs-00 and create a signalling ciphersuite
>>> value
>>> that would *only* be used in SSL 3.0 connections by clients that have
>>> downgraded, and tells the server "If you can read this, tear down the
>>> connection because we shouldn't actually be using SSL 3.0 for this
>>> connection"?
>>
>> (I think I would want such an SCSV to indicate TLS 1.2 support rather
>> than TLS 1.0 support, but that's just a detail.)
>
> Instead of particular versions, it seems to me that an indicator of "I
> tried to connect using a higher version than I'm using now but had to
> fall back to this verion" would cover any case now or later.
>
> The server would respond with an extension value indicating whether it
> intends to communicate over the channel using the negotiated version or
> not.  (It may be OK with a TLS 1.2 -> TLS 1.1 downgrade, but not to 1.0
> or SSLv3, for example.)  Both sides would continue the handshake through
> completion to ensure that everything is legitimate.
>
> Mike
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls