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

[Andrey Jivsov <[e-mail]>]

On 10/24/2014 04:04 PM, Bodo Moeller wrote:
>
> >> Also note that in the *specific* hypothetical scenario that you 
> describe, the server actually would accept the fallback retry: you 
> said that TLS 1.0 is the highest protocol version supported by the 
> server; this is not higher than ClientHello.client_version in the TLS 
> 1.1 retry, so the server wouldn't reject.)
>
> > No, this is not what I was saying.
>
> Yes, it is ("Let's assume that the server supports all protocols 
> SSL3.0-TLS1.0").  I gather that's not what you meant, though.
>
( Sorry for confusion caused by two typos. )

Yes, I am talking about a "modern" server (so TLS1.2 is implemented or 
TLS1.3 in the near future).

> > In my scenario the server supports TLS1.2 in general with some 
> ciphersuites (and will support TLS1.3 in the future). The server is 
> configured in a way that the ciphersuite that it can negotiate with 
> the client requires SSLv3.
> >
> > What does draft-ietf-tls-downgrade-scsv-03 want the server to do 
> here: assume it's highest version is TLS1.2 or SSL 3.0? I.e. is the 
> max. version a static property on the server or dynamic based on 
> ciphers in ClientHello?
>


> There's no -03 draft, but the current draft's implication should be 
> clear: the server compares protocol versions only and hence rejects. 
> (Pretending that the highest protocol version is SSL 3.0 wouldn't make 
> sense.)
>

Thanks, that's what I thought the draft is saying. The server simply 
uses hardcoded value that represents the highest version it implements. 
Well, consider that if the server "pretends" that its version is SSL 3.0 
(because this is what it will negotiate in my example, along the lines 
of the logic for the client in the draft), this will avoid breaking the 
fallback connection, an unnecessary failure in the example I gave.

Repeating my point earlier, it looks kind of harsh to fail TLS 1.1 on 
the server when it can only negotiate SSL3.0 with that client.

In summary, I still don't see good justification for discrepancy: the 
client "SHOULD include the TLS_FALLBACK_SCSV", while the server "MUST 
respond with an inappropriate_fallback". I would prefer that the server 
had SHOULD keyword, which is a reasonable keyword for secure protocols. 
The draft is not MUST with TLS, of course, and it would be reasonable to 
give some wiggle room to server implementation to determine when to fail 
the handshake.