The deadline for providing additional information was yesterday.
The results very clearly show that the course of action preferred by the
community is publishing the document without making further changes to
the details concerning the SCSV.
Cheers,
Joe
TLS Working group co-chair
According to ou
(2) I prefer *NOT* publishing the specification as-is, and instead
prefer to remove the 4 accidentally added rfc-2119-incompliant
imperatives from -03 back to the technically sensible semantics
which had the original WG and IETF consensus. The document editor
has proposed fix
At 9:49 AM +0100 1/26/10, wrote:
>If the recent discussions have caused you to change your mind (or we
>have interpreted your preference incorrectly, or you were not on
>either list), please send an email to the TLS WG mailing list by
>Tuesday February 2nd. In your reply, please include one of the
I prefer publishing the specification as-is.
Additional comment:
The SCSV is a temporary fallback, one that will not be needed when clients
enter strict mode, since when that happens servers have to support the RI
extension. Its use should therefore be kept to the minimum needed to
prov
pasi.ero...@nokia.com wrote:
>
> The detail in question is whether the "Signalling Cipher Suite Value"
> (SCSV) can be included when performing secure renegotiation (in
> addition to the renegotiation_info extension).
>
> Currently, the SCSV is not included. In the version that went to IETF
> Las
(1) I prefer publishing the specification as-is.
I've already changed my code to comply with the MUST NOT send SCSV
and RI in the same hello message, and have my server abort if it
sees both. So far nobody that has connected to my test server* has
sent both, and there have been lots of connec
I was not on your list, but:
(1) I prefer publishing the specification as-is.
-hs.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Concerning the SCSV behavior I prefer publishing the specification as-is.
regards,
Nikos
On Tue, Jan 26, 2010 at 9:49 AM, wrote:
> Concerns have been raised that the IESG may have judged community
> consensus about one specific detail of draft-ietf-tls-renegotiation
> prematurely. In particular
(1) I prefer publishing the specification as-is.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shen...@drh-consultancy.co.uk, PGP key: via homepage.
___
