Yoav Nir wrote:
On Nov 30, 2009, at 5:37 PM, The IESG wrote:
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.
I oppose publishing the current draft.
I strongly support it.
I don't buy the claims that extension handling as required here
is so hard to implement and all clients & servers need modification
in any case. (Not that its really relevant, but writing that code
would be much easier that reading the recent TLS list traffic;-)
I also don't see any concrete benefit in not sending the verify
data over the wire, but I do see more possibility for error in
terms of how to incorporate that data if its not sent.
My comments on -01 are below. While I'd like to see these addressed
of course, I think progressing this document speedily is more
important than resolving my comments. I think the same applies
to all other comments that I've seen, both during IETF LC and
on the TLS list since this problem was announced.
Regards,
Stephen.
1. The reference for the HTTP splicing attack is still a
placeholder. "[REF]"
2. I don't see any particular reason why the ServerHello RI value
contains both client and server values. I think it'd be marginally
better if the server just sent its value since the current approach
makes it easier for a server to mess up the ordering.
3. (Crossing page 5/6) It says the both "MUST verify" that the
values are correct, but doesn't explicitly say how to verify
the values, but just "as specified below" - where below?
It might be good to be extra-clear here, and add e.g. "A correct
value is one that was the verify_data of the Finished message
from the previous TLS session, or else the "empty" value given
above." or something like that.
4. I'm slightly concerned that middleboxes might barf on the
new ciphersuite. Be good if someone had tested that in the wild,
but I've not seen a mail that says that that's happened. (The test
I mean is inclusion of a totally new ciphersuite value, not the
inclusion of a previously-allocated-but-mostly-unused value.)
5. (Similar to above.) It'd be great if we had data to allow
us to recommend either the RI in the initial handshake or else
recommend the ciphersuite. I can see implementers not knowing
what to do there, leading to a 50-50 split in terms of who
does what, possibly leading to lack of interop. If it were up
to me, I'd remove the ciphersuite and just go with the RI.
6. Is there an explicit statement somewhere that servers MUST
support both the RI extension and the ciphersuite? If so, I
skipped over it, so maybe highlighting it somehow would be
good. If not, please add, so that someone generating tests
from the RFC's "MUST" statements generates one for that.
7. 6.2 says: "If servers wish to <<avoid attack>> they MUST
NOT <<do stuff>>" Isn't that equivalent to servers SHOULD
NOT? I think a SHOULD NOT is better. (And that's the form
used in section 7.)
8. I would be for removing the new requirement that the
identity not change. This spec is in response to one thing
and should only fix that thing. Any other considerations
should not get the "emergency" treatment being applied
here especially since there could be unforseen side-effects
of the additional change. (E.g. some deployed application
making use of an id-change.)
9. The security considerations and the introduction
should include a statement that another mitigation that's
useful in many cases is for a server to simply disallow
all renegotiation and encourage implementers to allow
deployments to control that.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf