Re: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt

In 4, this says "Servers MUST treat receipt of
TLS_RENEGO_PROTECTION_REQUEST exactly as if the client had sent an
empty "renegotiation_info" extension" - presumably not _exactly_ - the
hash calculation is different, right?

In 5, "TLS clients which support this draft MUST generate either
the"renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST
cipher suite with every ClientHello" - because
TLS_RENEGO_PROTECTION_REQUEST is equivalent to an empty extension it
can only be used in the first ClientHello.

6.1, " However, it is expected that many TLS servers that do not
support renegotiation (and thus are not vulnerable) will not support
this extension either, so in general, such behavior would not work
well." is pretty feeble - what do we suggest clients do in this case?
Yeah, I've heard that some people don't want to change their
implementations - so what? If they want to be nonconformant, that's
their choice - we should not be encouraging that choice, though.

6.2 "In order to enable clients to probe, even servers which do not
support renegotiation SHOULD implement the minimal version of the
extension described in this document for initial handshakes, thus
signalling that they have been upgraded." - SHOULD should be MUST.

https://mail.google.com/mail/?zx=16yvh4iv244dd&shva=1#vftt_inbox/12513961f5f15eea
On Sun, Nov 29, 2009 at 8:30 AM, Stefan Santesson <stefan@aaa-sec.com> wrote:
> Geoffery,
>
> The current version of this draft is:
> http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01
> It does no longer have the sections you refer to.
>
> /Stefan
>
>
> On 09-11-29 4:27 AM, "Geoffrey Keating" <geoffk@apple.com> wrote:
>
>> Apple supports this draft, with the following modification:
>>
>> The draft does not address the security issue for existing clients unless it
>> requires that renegotiation occur only when the extension is present.  I
>> suggest strengthening the language in 4.2 to read
>>
>> To prevent such attacks, servers MUST NOT allow clients who do not offer the
>> "renegotiation_info" extension to complete a renegotiation.  If the client
>> initiated the renegotiation the server SHOULD respond to such requests with a
>> "no_renegotiation" alert [RFC 5246 requires this alert to be at the "warning"
>> level.]  If the server initiated the renegotiation the fatal
>> "handshake_failure" alert is appropriate.
>>
>> and delete the sentence 'Servers SHOULD follow this behaviour'.
>>
>> With this modification, section 4.1.1 is redundant and may be deleted.  It is
>> also possible to delete section 4.3 as with this modification, if the client
>> is convinced to drop the extension, either servers support the draft and will
>> refuse to renegotiate without the extension and are still secure, or don't
>> support the draft and will ignore the extension, and so would be insecure
>> anyway.
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>