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

["Yngve N. Pettesen" <[e-mail]>]

On Thu, 23 Jan 2014 11:06:04 +0100, Eric Rescorla <[e-mail]> wrote:

> WG Members,
>
> This message is a call for acceptance of
> http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01
>
> As a TLS WG item.
>
> Please provide any comments on this action by Feb 7. Because
> there has been only modest discussion of this document, the
> chairs ask people who have already spoken in favor or against
> this document to re-register their opinion (feel free to just say
> +1 or -1 and point back to the archives.)

-1

I dislike this approach for several reasons:

1) I dislike the recent tendency to use (throw) an SCSV for (at) any  
protocol problem showing up. At present these decisions seem to be too  
ad-hoc IMO. If this use of SCSVs is to continue (which I do not recommend)  
perhaps the WG should first define a policy for when to use them, and  
possibly also set aside a range of ciphersuite values for SCSVs and  
interpretation of unknown SCSVs? E.g. should some SCSVs be considered  
critical, and should a server that knows about SCSVs but which does not  
understand a critical SCSV abort the connection?

2) The use of this SCSV require both client and server to be updated to  
understand the SCSV. The deployment of such a fix is going to take a  
minimum of 5-10 years (The renego patch, fixing a major security  
vulnerability, have only recently passed 80%, more than 3 years after it  
was released). I would prefer a solution that only require one party, the  
client, to be updated.

3) Involving two parties in determining what to do about the fallback  
issue will complicate implementations, and also risk interoperability  
problems. There is one party that specifically knows that it has been  
falling back, and who can (and IMO should) be making the decisions: the  
client. The reason for the fallback (assuming no client bugs) may be  
normal network issues, server non-compliance, non-compliant intermediates,  
or an MITM attack.  The only cases in which an SCSV might help, is in the  
case of non-compliant intermediates and MITM attacks, but that requires  
(as mentioned above) that the server supports the SCSV indication. If the  
server does not support the SCSV the client will have to assume that the  
server is just non-compliant and continue the connection using an older  
protocol, or use other means to try to discover if the connection is being  
interfered with before trusting it.

In my opinion the WG should not, at this stage, take on a specific  
solution as as work item, but should instead explore, as an I-D (by a  
neutral editor), the problem space and alternative proposals for solving  
the issues, including SCSVs, proxy indications (such as my renego-based  
proposal), or recommending "no fallback". That would collect information  
about the problems and proposals in a single document, and make the matter  
more readily accessible to new readers than trying to review several years  
of discussion threads in the WG mailing list. As for the time aspect,  
using 6-12 months to produce such a document might create a better  
understanding of the problem and solution, and would not delay the 5-10  
year deployment by much (for that matter, there are still many SSL v3-only  
servers 15 years after TLS 1.0 was published, so deployment might be 10-20  
years instead; unless the WG decides to set hard deadlines and to risk  
"breaking the internet").

A couple of questions that might be investigated in such a document  
includes: Should the solution support SSL v3-only servers? TLS 1.0 servers  
without TLS Extension support? Should SCSV capable servers be required to  
implement TLS 1.2? Can the indication be implemented as an extension  
instead? and so on.


Sincerely,
Yngve N. Pettersen

-- 
Using Opera's mail client: http://www.opera.com/mail/