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

From: Geoffrey Keating <[email-masked]>
Date: Sat, 28 Nov 2009 19:27:13 -0800

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.

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 29 Nov 2009 17:30:07 +0100

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" <[email-masked]> wrote:

> 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.
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Ben Laurie <[email-masked]>
Date: Sun, 29 Nov 2009 16:08:21 -0800

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

---

From: Geoffrey Keating <[email-masked]>
Date: Sun, 29 Nov 2009 19:47:03 -0800

> It does no longer have the sections you refer to.

The sections were reorganised for the -01 version, so in that version it's 6.2 that I suggest strengthening and section 4 that becomes redundant and can be removed.

>> With this modification, section 4.1.1 is redundant and may be deleted.