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

[Watson Ladd <[e-mail]>]

On Oct 15, 2014 11:52 AM, "Martin Rex" <[e-mail]> wrote:
>
> 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).

This proposal looks to me to be clearly better theoretically. It's more
robust in the face of transient network issues. OTOH, if the practical
difference is minor, I'd rather get done sooner than later. I'm also by no
means knowledgeable about the impact on stateful firewalls expecting to see
TLS with a particular flow, or if this even is an issue.
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/
<https://www.ietf.org/mailman/listinfo/tls>tls