Nelson B Bolyard wrote:
On 2010-01-27 07:37 PST, Martin Rex wrote:
Yoav Nir wrote:
Actually it's easier to hard-code the ciphersuite list on the client,
because it never changes with most applications. Adding logic to
differentiate between initial handshakes and repeated handshakes
complicates the code (though not by much)
It more complicated than that, because SCSV is additionally necessary
for sensible behaviour even with -03 when doing old renegotiation
on a connection where the initial ClientHello did not use any
TLS extensions.
I think you meant to write "necessary to prevent vulnerable renegotiation on
a connection where the initial ClientHello did not use any TLS extensions".
If that is what you meant, please confirm.
It is necessary to actually perform an old-renegotiaion successfully
while at the same time preventing an attacker from being able to
proxy that old renegotiation into a renegotiation handshake of
an updated server that still allows backwards-interoperable
old renegotiation for old clients.
What you wrote sounds more like you were expecting "old renegotiation" to
succeed.
Correct, I am expecting that.
That is a configuration option that implementations (hotfixes into
installed base, early during the transition) are likely required
to offer.
That we recommend to discontinue old-style renegotiation is
a totally different issue.
If you were indeed expecting that, then why does SCSV play any
role in that at all?
The purpose of SCSV is to reliably prevent any undesired renegotiations
from being possible. The only handshakes where you can reliably
distinguish desired from undesired is those between updated clients
and updated servers.
If an implementation of TLS offers a configuration option to allow
old-style reneogitation for interop with installed base old servers,
then we should an can limit that fallback to old servers. This is
what the brand-new section 4.2 tries to explain (although it is
in dire need of editorial fixes in order to become comprehensible).
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf