Re: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt

[Bodo Moeller <[e-mail]>]

> Document: <http://www.ietf.org/id/draft-**pettersen-tls-version-**
> rollback-removal-02.txt<http://www.ietf.org/id/draft-pettersen-tls-version-rollback-removal-02.txt>
> >
> Tracker: <http://datatracker.ietf.org/**doc/draft-pettersen-tls-**
> version-rollback-removal/<http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal/>
> >
>


> The benefit of my proposal is that:
>
>  - it only needs to be deployed client-side.
>  - it does not require changes to the protocol, only to how the client
> handle a specific situation.
>  - once clients only accept renego patched server this method, *and* the
> version rollback functionality can be removed.
>
> There will initially be the downside of handling the .26% servers that are
> version/extension intolerant, but those can be quickly patched. There is
> also the problem of version/extension intolerant intermediates in the
> network that have been observed by the Google Chrome team.
>



> I'll also note that two other approaches (proposed by EKR and Adam
> Langley) for this have been discussed the past two years, using SCSVs, and
> these and mine were discussed at the IETF-84 TLS WG meeting.


Thanks for your comments!

Obviously all of the above proposals are somehow related.  Actually, I
think that your ID and mine in fact complement each other in
that draft-pettersen-tls-version-rollback-removal-02 provides heuristics
for how to handle (and avoid) protocol rollbacks in the *current*
implementation landscape, whereas draft-bmoeller-tls-downgrade-scsv-00
specifies a simple mechanism that can be used to avoid security problems
from protocol rollbacks in a very *general* way.




Martin Rex noted (in neighbor thread "[TLS] Comments/Questions on
draft-gutmann-tls-encrypt-then-mac-00.txt" where this came up, but which I
don't want to hijack entirely):

OH NO, not again!!
>
> Any kind of specification for TLS, that suggests to the server
> to apply heuristics and make (often flawed or unjustified) assumptions
> about what the client may want or may not want and have the _server_
> abort the handshake rather than the client, are a REALLY BAD IDEA and
> squarely against the IETF spirit to promote interop.


I'm not sure to what extent I agree to this claim (for example, we do allow
servers to abort with an insufficient_security alert if they don't agree
with any of the ciphersuites listed in ClientHello.cipher_suites), but in
any case please note that this is not actually what
draft-bmoeller-tls-downgrade-scsv-00 specifies.

Rather, the specification has very specific instructions for servers when
to abort the connection (certainly I'm all for encouraging
interoperability, but for a security protocol there clearly are limits to
this -- I'd rather not interoperate with man-in-the-middle-type attackers,
for example), and specifically leaves it to clients to request that
server-side behavior for a given handshake attempt or not.  The
specification includes recommendations that will ensure full security based
on the capabilities of the given client and server, but client
implementations are allowed to ignore these if there are appropriate
reasons.

(I think an essential difference to Eric's and Adam's earlier proposals is
that in my proposal, the client wouldn't enumerate its capabilities for the
purpose of server-side heuristics.  Instead, use is entirely directed by
the client, as needed by its protocol downgrade sequence.  In the ideal
case, with no client-side protocol downgrade taking place at all, nothing
happens.)

Bodo