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(_dot_)robinson(_at_)rsa(_dot_)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-bounces(_at_)ietf(_dot_)org [mailto:tls-bounces(_at_)ietf(_dot_)org]
On Behalf Of The IESG
Sent: Tuesday, 1 December 2009 1:38 AM
To: IETF-Announce
Cc: tls(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org mailing lists by 2009-12-14. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)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
TLS(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf