This makes no sense to me.
Developers tend to live by the rule to be "liberal in what you accept" as it
tends to generate less interop problems.
It makes no sense to abort a TLS handshake just because it contains an SCSV
if everything else is OK. So This "MUST NOT" requirement will likely be
ignored by some implementations.
03 gives SCSV somewhat double and conflicting semantics.
1) Present in an initial handshake it signals client support for secure
renegotiation.
2) Present in a renegotiation handshake it signals that the client DOES NOT
support secure renegotiation (Handshake MUST be aborted).
I think this is asking for trouble.
/Stefan
On 10-01-27 8:33 AM, "Nikos Mavrogiannopoulos" <nmav(_at_)gnutls(_dot_)org>
wrote:
On Wed, Jan 27, 2010 at 1:05 AM, Martin Rex <mrex(_at_)sap(_dot_)com> wrote:
<aside>That's been the standard for PKIX RFCs for at least ten years
(actively acknowledged by WG mmembers), although perhaps its spread
to other groups should be discouraged.</aside>
I fully agree.
That may be attributed to the fact that a large part of PKIX is dealing
with policy issues with the objective to prevent/prohibit interoperability.
On the contrary. I believe allowing the sending of both SCSV and extension
might harm interoperability instead. Consider the case of most popular client
implementations are sending both SCSV and extension (it's easier to do so).
A developer of a server might then consider checking only for SCSV (since all
of the popular ones he tested with send both). Thus interoperability with less
popular clients that only send extension stops.
This scenario might not be very likely, but this kind of issues were
not rare in
TLS for quite long :)
best regards,
Nikos
_______________________________________________
TLS mailing list
TLS(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf