Re: Evaluation: draft-ietf-msec-mikey - MIKEY: Multimedia Internet KEYing

["Steven M. Bellovin" <smb@research.att.com>]

In message <E1A4hBT-0005CU-OP@asgard.ietf.org>, IESG Secretary writes:
>--------
>
>Last Call to expire on: 2003-07-31
>
>        Please return the full line with your position.
>
>                      Yes  No-Objection  Discuss  Abstain
>Steve Bellovin       [   ]     [   ]     [ X ]     [   ]

4.1.3 says "let n = inkey_len / 512, rounded up to the nearest integer".
Is it rounded up, or to the nearest integer?  If the division yields an 
integral result, is it bumped by 1?  The same comment applies to m.

Explain what relevance 512 has to SHA1, which externally takes messages 
of any size.  Are you referring to SHA1 internals?  What should be used 
for hash functions that don't have SHA1's internal 512-bit structure?
I suggest that you require than any new PRF be defined by its own RFC, 
rather than trying to give guidance here.

4.2.2: what parameters corresponding to 512 and 160 should be used for 
SHA-256, -384, or -512?

4.2.9: what process (per rfc 2434) is needed for new parameter 
registration?  How does this relate to Section 10?

5.4 suggests dropping messages from attacking peers.  Of course, until 
the message is authenticated you don't know whom it's from, which still 
leaves the door open to a CPU DoS attack.

5.5: what is done to avoid congestion?

6.11 Cite RFC 1750?  (Also cite it when discussing DH exponents.)



		--Steve Bellovin, http://www.research.att.com/~smb