Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

For my understanding: why is this proposal vitally dependent on the server sending inappropriate_fallback alert? If the server receives the SCSV, has a higher protocol version enabled than that in the ClientHello, and quietly aborts the handshake, isn't the downgrade attack thwarted?

Thanks,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex
Sent: Monday, January 27, 2014 4:18 PM
To: Bodo Moeller
Cc: tls@ietf.org
Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

Bodo Moeller wrote:
> Michael D'Errico <mike-list@pobox.com>:
>>
>> We should consider whether we can define a single SCSV that a client 
>> issues when it thinks a server is extension intolerant.
>>
>> Such an SCSV could be used in conjunction with a normal extension 
>> used for downgrade protection, if the client gets pushed all the way 
>> back to TLSv1.0 without extensions, or to SSLv3.
>>
>> This approach could solve the problem of desiring more SCSVs in the 
>> future.
> 
> Hm, that would mean having the SCSV for special-case downgrade 
> protection (extension intolerance) and an extension for general-case 
> downgrade protection (when extension intolerance is not an issue).  
> That means requiring more code to be added to servers (to *all* 
> servers, since these mechanisms only work as intended if all servers support them).

But you _are_ aware that your proposal is vitally dependent that the TLS server puts a fatal SSL alert on the wire before closing the connection?  Historically, (close to) all applications running on top of Microsoft SChannel (including MSIE client and IIS server) do not send any fatal alerts before closing connections, because they use a transport-free API (Microsoft SSPI, similar to GSS-API) to their TLS implementation, and the application code does not support
(a) processing a fatal error messages and (b) sending tokens over the network at the same time.  It's basically the same reason why the forwarding of error tokens and outputs of "gss_delete_sec_context()"
was deprecated in GSS-API v2 -- because most apps will simple refuse to do it.

It would not be possible to hide such a change in behaviour (writing a fatal alert to the network before closing the connection) within SChannel, it would also require a change to at least Microsoft IIS.
How likely is that going to happen?  (It's been the way it is not for the last ~14 years...).

Which server implementers are eager to send such a fatal alert as is contained in this proposal anyway?  I will certainly ensure that our server implementation will NEVER grow such silly behaviour.

-Martin
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls