v Nir
> -Original Message-
> From: tls-boun...@ietf.org [mailto:tls-boun...@ietf.org] On Behalf Of
> pasi.ero...@nokia.com
> Sent: Tuesday, January 26, 2010 12:49 AM
> To: ietf@ietf.org; t...@ietf.org
> Subject: [TLS] Confirming consensus about one draft-ietf-tls
(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
Martin Rex wrote:
Nelson B Bolyard wrote:
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 of
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
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 (tho
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 yo
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
Martin Rex [mailto:m...@sap.com]
Sent: Tuesday, January 26, 2010 4:44 PM
To: Kemp, David P.
Cc: t...@ietf.org; ietf@ietf.org
Subject: Re: [TLS] Confirming consensus about one
Kemp, David P. wrote:
>
> Rationale:
>
> Version -01 states that the semantics of SCSV is identical to t
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
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 understa
I've stayed out of this discussion so far, because my opinion has already been
noted, but since you've changed the subject...
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 th
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.
___
org [mailto:tls-boun...@ietf.org] On Behalf Of
pasi.ero...@nokia.com
Sent: Tuesday, January 26, 2010 3:49 AM
To: ietf@ietf.org; t...@ietf.org
Subject: [TLS] Confirming consensus about one
draft-ietf-tls-renegotiationdetail
Concerns have been raised that the IESG may have judged community
consensus about on
17 matches
Mail list logo
