Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

[[e-mail] (Martin Rex)]

Florian Weimer wrote:
> Joseph Salowey (jsalowey) wrote:
>>
>> This is an announcement for the working group last call for
>> draft-ietf-tls-downgrade-scsv-00.  Please review the document
>> and send your comments to the list by Friday, October 17, 2014.
> 
> I'm strongly against this proposal. 

I'm also strongly opposed to this proposal, because it does not provide
any value--there is not one single *additional* TLS handshake that it
will make succeed, instead, the only thing that this proposal will
provide is either zero benefit or fatal interop failure, i.e. it
if there is any result from it it will be headaches to users, sysadmins
and helpdesks.

This proposal is as far opposite from the spirit of the IETF as
one can possibly get.


What we would need instead of this proposal, is one that will

  (1) make more TLS handshakes succeed

  (2) make more TLS handshakes succeed with new protocol features

  (3) make more TLS handshakes succeed with new protocol features
      for regular app clients that do not have re-connect fallback in place,
      and _without_ interfering with conservative ClientHellos that these
      clients use to maintain interop with old, "broken" servers out there.


The "downgrade-scsv" has the effective semantics of
"kick me if you can read this", which is pretty silly on my scorecard.


A reasonable alternative SCSV would have the semantics
"Dear Server, I'm a new, full-featured client and would really like
to send you a full-featured ClientHello, but didn't dare doing as
the first message on the connection because of all the old broken
servers out there which choke on feature-rich ClientHellos".

And a new Server's response to such an SCSV should be to
respond with a ServerHello+ServerHelloDone which carries the SCSV
in the ServerHello.cipher_suite = SCSV, which the client will
recognize and understand as an invitation to send the desired
full-featured ClientHello (on the very same existing connection
transparently).


-Martin