[MSEC] weis-esp-group-counter, was MSEC status update (fwd)

[[e-mail]]

Hi Brian and Lakshminath, 

<snip> 

> V.
> New work (to be adopted after asking for group's opinion):

<snip> 

> draft-weis-esp-group-counter-cipher-00: Ditto.

I do not have a strong objection to this draft being adopted as a MSEC 
working group item. However, there are several questions (problems?) that I 
wondered about when I did a quick superficial review of this draft. 

1) A fundamental problem is nonce or IV re-use, as recently discussed at 
length on CFRG. Wei Dai posted an good summary of those discussions and what 
to do about this problem about a week ago. I would suggest that this draft 
should include that guidance in its security considerations. That said, I 
suspect the risk of compromise is magnified in direct proportion to the size 
of the group membership. Instead of two endpoints, there are "N" endpoints 
that could accidently re-use a {SID, SSIV} pair, and this needs to be 
emphasized by this draft. There were about two dozen CFRG e-mail exchanges 
about random number generation, counter management, virtual machine 
interactions, and re-boot scenarios. At the least, the Sender-Specific IV 
(SSIV) field must be saved in a non-volatile storage after each use to avoid 
the scenario where a re-boot causes accidental {SID, SSIV} re-use. That way 
if a member re-boots then re-joins the same group, then it MUST also restart 
its SSIV at the last value used plus one. This is only one example. There 
are other cases mentioned by CFRG that need documentation. Perhaps the SID 
and SSIV must be qualified by a third field assigned by the GCKS, a 
"registration instance" counter? 

2) A second problem is the inability to scale to large groups because the 
per sender state that receivers must maintain to enforce anti-replay 
services. The draft does not mention anti-replay service or how it interacts 
in this multi-sender group scenario. The draft must state that anti-replay 
service is not recommended, or else explain how it is done such that it 
scales to a large group. 

3) The draft as written assumes that there is only a single cryptographic 
group and a single omnipotent GCKS. It seems to preclude any easy extension 
or accommodation for composite groups or distributed S-GCKS operations. In 
particular, the requirements in section 4 could be a source of complexity. 
Is an endpoint always required to interact with the same S-GCKS? Are all 
S-GCKS expected to know the SID of every potential group member? 

4) The assertion made in section 6, the Security Considerations, that the 
security is equivalent to that of a single sender is not true and should be 
replaced with text along the lines described above. 

hth,
  George

_______________________________________________
MSEC mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/msec