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.
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
4. The "identical" version is ready to go, in the form of -03 that can
be published as an RFC right now.
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.
6. Reducing optional elements is always good security hygiene (hash
collision space, covert channels, stack overflow alignment, etc.) Take
away a useless knob and nobody can twiddle that knob against you.
Dave
-----Original Message-----
From: Martin Rex [mailto:mrex(_at_)sap(_dot_)com]
Sent: Tuesday, January 26, 2010 4:44 PM
To: Kemp, David P.
Cc: tls(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: [TLS] Confirming consensus about one
Kemp, David P. wrote:
Rationale:
Version -01 states that the semantics of SCSV is identical to the
semantics an empty RI, namely: "this client is capable of supporting
secure renegotiation, and this ClientHello message is an initial
handshake, not a renegotiation handshake."
But you do realize that we discussed this issue on the WG mailing
list and the I provided an explanation along the lines of a
semi-formal correctness proof that this rationale is based on
a misunderstanding and a poor choice of words in the specification.
http://www.ietf.org/mail-archive/web/tls/current/msg05466.html
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf