>The IESG has received a request from the Transport Layer Security >WG (tls) to consider the following document: > >- 'Transport Layer Security (TLS) Renegotiation Indication Extension ' > <draft-ietf-tls-renegotiation-01.txt> as a Proposed Standard
My colleagues and I support this draft. We would like the following to be considered: In section 1 there is a missing full stop: >thus be detected This Should be: >thus be detected. This In section 1, there is a reference to the extension prior to it being defined. Perhaps the following should be changed from: >An attempt by an attacker to inject himself as >described above will result in a mismatch of the extension and can >thus be detected To: >An attempt by an attacker to inject himself as >described above will result in a mismatch of the handshake hash and can >thus be detected In section 1, an ID is mentioned. I am not sure it adds anything to the specification having this here. Perhaps if the purpose is to acknowledge the people who created the draft, they could be acknowledged in the Acknowledgements section. Given this, I think that the following should be removed: >The extension described here is similar >to that used for TLS Channel Bindings >[I-D.altman-tls-channel-bindings]. If this were to be removed, the text in section 3 would also need to be removed: >Note that this value is the "tls-unique" >channel binding from [I-D.altman-tls-channel-bindings] In section 3 the term "TLS resumption" is used. In RFC5246 I think this is typically referred to as "session resumption". Perhaps the text should be changed from: >The above rules apply even when TLS resumption is used. To: >The above rules apply even when TLS session resumption is used. In section 4 there is a typo, a " is missing and the word "in" is missing. This line should be changed from: >"renegotiation_info" extension, only renegotiation_info" may be used >rehandshakes. To: >"renegotiation_info" extension, only "renegotiation_info" may be used >in rehandshakes. In section 4 last paragraph it discusses a minimal client. It says: >Any compliant server will reject any (apparent) attempt >at renegotiation by such a client. And in section 3 it says: >If the contents >are incorrect, then it MUST generate a fatal "handshake_failure" >alert and terminate the connection. This implies that the cipher suite is not entirely equivalent to an empty renegotiation_info extension. If a server receives an empty renegotiation_info extension on a rehandshake then it must generate a fatal "handshake_failure" alert and terminate the connection rather than merely rejecting the renegotiation (by generating a "no_renegotiation" alert at warning level). I think that the paragraph in section 4 should be altered to say: >Any compliant server MUST generate a fatal "handshake_failure" >alert and terminate the connection when it sees any (apparent) attempt >at renegotiation by such a client. In section 6.1, it says the word "rehandshakes" when I think that it should say "renegotiates". Hence, change from: >reject all rehandshakes and simply not signal it. However, it is not To: >reject all renegotiates and simply not signal it. However, it is not Peter ------------------------------------------------ Peter Robinson - peter.robin...@rsa.com Engineering Manager RSA, The Security Division of EMC - http://www.rsa.com/ Level 32, Waterfront Place, 1 Eagle Street, Brisbane, Queensland 4000, AUSTRALIA. Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400. -----Original Message----- From: tls-boun...@ietf.org [mailto:tls-boun...@ietf.org] On Behalf Of The IESG Sent: Tuesday, 1 December 2009 1:38 AM To: IETF-Announce Cc: t...@ietf.org Subject: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) toProposed Standard The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Transport Layer Security (TLS) Renegotiation Indication Extension ' <draft-ietf-tls-renegotiation-01.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-12-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19412&rfc_flag=0 _______________________________________________ TLS mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf