Re: [secdir] SecDir review of draft-ietf-tls-downgrade-scsv-03

[Bodo Moeller <[e-mail]>]

Thanks for your comments, Yoav!



> The Security Considerations section has some strange text about omitting
> the SCSV when "the protocol version given by ClientHello.client_version
> still provides an acceptable level of protection". This implies that it is
> appropriate to use a protocol version that does not provide and acceptable
> level of protection as long as the client sends the SCSV. This is not the
> case, and this is the reason that several browsers are disabling the
> downgrade to SSLv3. I realize it is difficult to write text that turns the
> secure/insecure dichotomy into a trichotomy (secure/so-so secure/insecure),
> but if we're going to make including the SCSV optional we need such text.
>

Could you make a concrete (if rough) suggestion for what you'd like to see
in the document?  Note that the text that you cite above was essentially
contributed by one of the WG chairs :-) [*]  Personally, I don't see a need
for additional text because I think that the document already makes it
quite clear that the reason why a client might tolerate an otherwise
unacceptable level of security when sending the SCSV is as a last resort
for connections to legacy servers.

Regarding your statement that "this is the reason that several browsers are
disabling the downgrade to SSLv3", I don't agree.  If TLS_FALLBACK_SCSV was
already widely deployed in servers, browser vendors would have had a much
less pressuring need to disable the downgrade to SSL 3.0 entirely -- with
the SCSV, SSL 3.0 would have been exclusively about hopeless legacy servers
anyway,


A scenario that bothers me is a server that returns an
> inappropriate_fallback whenever it receives a TLS_FALLBACK_SCSV with
> version TLS 1.1, but breaks at TLS 1.2. Such an (admittedly broken) server
> could potentially send the client into an endless loop of regular and
> fallback handshake attempts. An attacker could simulate this by RST-ing all
> TCP connections with TLS 1.2 in ClientHello. I think the draft should warn
> against doing the regular-fallback-regular cycle more than once. IOW: after
> receiving the alert, clients MUST NOT perform the downgrade dance on the
> following connection.


The problem is, the alert is not authenticated.  (We'd have to complete the
handshake to authenticate it.)  So a "MUST NOT" can't be right: if a
browser users tries to access a web page a second time after the above
failure, it's appropriate for the client to perform the entire downgrade
dance again if needed.  Implementors shouldn't go into infinite reconnect
loops, but I don't think there's anything special here about
TLS_FALLBACK_SCSV.



> Nits and minor issues:
>
> Since the client speaks first, it would make sense to have section 4
> (Client Behavior) before section 3 (Server Behavior). Section 3 describes
> how the server responds to this SCSV when the document had only hinted
> about when the client should send it.
>

My rationale for describing server behavior before client behavior was that
I think this makes it easier to read the document, given that server
behavior follows simple, concrete, and strict rules. After you've read
those in the Server Behavior section, I believe it will be much easier to
make sense of the (more complex) section on Client Behavior.  If you don't
know what server behavior TLS_FALLBACK_SCSV triggers, my fear is that the
Client Behavior section will seem very esoteric, abstract, and nebulous.



> The IANA Considerations are very confusing, saying on the one hand that no
> values have been allocated, and on the other hand that IANA has assigned
> 0x56,0x00. Unless the authors are requesting that IANA assign the numbers
> that they have used in early implementations, it's better to just write
> "IANA is requested to assign..." and replace the numbers in the rest of the
> documents with TBDs (if you leave actual numbers and IANA assigns different
> identifiers, it's likely to be overlooked by the RFC editor).
>

Right, the point is specifically to use the numbers that have been used in
existing implementations.  Isn't the "TO BE REMOVED" note rather clear
about that?  In any case, the contradictive part obviously isn't meant to
go into the final document -- the current form is meant to show the
intended final document text while also making it clear that IANA hasn't
yet assigned anything.



> A few missing articles:
> "The fallback SCSV defined in this document is not *a* suitable substitute"
> "if *the* TLS implementations also include support for (the) predecessor
> protocol SSL 3.0"


I don't think either of these is technically necessary, but I'l entirely
leave the decision about these articles to my co-author :-)  (In the first
case, by the way, it's again language contributed by said WG chair. [*])

Bodo


[*]  No intent to shift any blame: I think the current text is fine, or I
wouldn't have used it.  However, this lets you know who's in a special
position to convince me to change that wording.