RE: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) toProposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>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.robinson@xxxxxxx
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@xxxxxxxx [mailto:tls-bounces@xxxxxxxx] On Behalf Of The IESG
Sent: Tuesday, 1 December 2009 1:38 AM
To: IETF-Announce
Cc: tls@xxxxxxxx
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@xxxxxxxx mailing lists by 2009-12-14. Exceptionally,
comments may be sent to iesg@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls

<<attachment: smime.p7s>>

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]