[Ballot discuss]
Updated based on -11:

I found this a well written and clear document - thanks. Just a couple of points I'd like to discuss before changing my ballot position:

1) s3.1 contains the following:

If the listener acts in this way, however, it MUST generate
its key in a verifiable fashion, allowing it to verify that it
generated the key when it is echoed in the ACK.

What do mean by "in a verifiable fashion"? Do you really mean reproducible?

We mean, "in a fashion by which the receiver could verify they were the generator". Specifying such a mechanism is far out of scope (it may not even be particularly possible), but this is part of the rationale for the ACK echoing keys to permit stateless operation, like SYN cookies today.

Two concerns:

1. I'm concerned that this is a MUST and there might not be a way to do it. With SYN cookies, additional info is carried to allow the listener to figure out it was their key. Where would the additional information be carried here?

2. You say it's stateless, but if an implementation does something like SYN cookies they've got to keep state.

2) Cleared - Addressed with new text added to the security considerations.

3) Cleared (no action required - exchange with author cleared this one up).

4) Cleared (no action required - exchange with author cleared this one up).

5) s3.1/s3.2: Hate that this uses SHA-1 for the IDSN and token, but I guess you're not really worried about collision resistance. Is that true (gets a little bit at one of Stephen's)? If it's true, you need to say something about not really needing that property of the hash algorithm in the security considerations. Here's some text that's in a TLS WG draft that might be a good starting point:

The hash algorithm used in this specification
is required to have reasonable random properties
in order to provide reasonably unique identifiers.
There is no requirement that this hash algorithm
must have strong collision resistance.

I guess maybe just add:

The hash algorithm used in this specification to
generate the IDSN and token is …

For token, however, collisions would be a problem since the hash(key) = token, which is what is used to index the connection. Not a big deal on a small client, but I guess it might be an issue with servers with ~10k connections? Do you feel SHA-1 is inappropriate for this use?

If collisions are an issue then SHA-1 ought not be used see RFC 6194.

The other thing is once you deploy crypto trying to get rid of it is impossible. If we can use SHA-256 instead now it will probably be better in the long run.

6) Cleared - draft -11 has text to address this one.

7) s3.5: Why are you returning the receiver's key in the MP_FASTCLOSE? Couldn't you send something else back? Also need to update the security considerations to mention that the receivers key is also returned in the MP_FASTCLOSE option.

my one concern here is that implementations will use the same key for every connection and it's a little linked to #2: Is this from s3.1:

The key MUST be hard to guess, and it MUST
be unique for the sending host at any one time.

trying to say a new key should be used on each connection?