Yoav Nir wrote:
On Jan 27, 2010, at 12:50 AM, Kemp, David P. wrote:
Yes. I agree that SCSV could be defined to convey only 1 bit of
information while RI conveys 2 bits, and agree that -01 (which went
through last call) does not define it that way.
What I don't understand is why the issue of changing the semantics of
-01 and -03 to reflect a "1 bit SCSV" is so #$%& important.
1. It is trivially easy to code to either version.
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.
And it is a different question whether providers of an implementation
offer this configuration option (which a number of them likely has to),
or wether we recommend that this configuration setting is actually used.
These are two different guidances, and the -03 document does not
distinguish them, which is a bad idea.
2. There is no security impact of using either version.
3. It is easier to articulate and to understand an "identical" soundbite
than to explain how SCSV and empty RI are semantically different, and
"SCSV means the client supports RI". There. That was easy to articulate.
An empty extension is less easy IMO.
The concept that I had in mind when I created the label
TLS_RENEGO_PROTECTION_REQUEST was a signal that indicates
"Please protect me from an old-style TLS handshake"
And an old-style TLS handshake is one where you have no possibility
to detect whether there is an MitM attacking you.
4. The "identical" version is ready to go, in the form of -03 that can
be published as an RFC right now.
Process-wise, Pasi could have made a consensus call on exact SCSV
semantics on Dec 17th providing several options, the result of a
free and open discussion on SCSV semantics could have been part
of -03, Pasi could have re-issued an IETF Last Call on Jan 7th, we
would have received further editorial comments and today
an -04 document could be in much better shape, ready for IESG
approval and in perfect alignment with the IETF processes.
And although I hesitate to bring up the following since they are
non-essential,
5. SCSV is a hack meant to appease ancient and/or non-conforming
servers. That is one ugly baby, and I wish it would just disappear.
There is absolutely no reason for it ever to be sent in a ClientHello
containing a non-empty RI (it is a no-op that just wastes N bits of
bandwidth to convey 0 bits of additional information, and no legacy
implementation would ever send or interpret it), so I see absolutely no
downside to prohibiting it during renegotiation.
To me RI looks like a hack just as much as SCSV. Hopefully in the
future, the way to indicate support for secure renegotiation would
be in the client version of the ClientHello.
Unfortunately, that "go away" is impossible for any implementation
of TLS that offers interop with protocol versions 0x03,0x00 -> 0x03,0x03
(aka SSLv3 and TLS protocol version v1.0->v1.2).
And although clients could stop sending SCSV when they stop using
extension-less ClientHellos, the server-side support for SCSV is going
to stick forever.
Likewise, the TLS extension RI band-aid is going to be with us
for at least 20 years. It's not possible to make this design
an integral part of a future TLS version that obviates sending
this data over the wire. Except maybe defining an alternative
and negotiating that as well. The latter could obviate transfering
the data, but would require implementations to implement essentialls
two solutions for the same problem, which, unless someone finds
a problem with TLS extension RI (which I doubt), would be
a complete waste of resources.
I remember that Stephen Farrell suggested to standardize both
(TLS extension RI without SCSV plus a well-discussed successor
of draft-mrex-tls-secure-renegotiation), but *I* don't like
two solution where one is sufficient.
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf