Subject: [MSEC] draft-perrig-msec-tesla-intro-00.txt

From: LANIEPCE Sylvie FTRD/DMI/CAE <[email-masked]>
Date: Thu, 11 Apr 2002 10:16:27 +0200

Adrian,
Thank you for your answers. Please, see in line.

> I do not understand why there is no more need for the second security
> condition defined in the TESLA SMUG draft (check that i is not an
> interval in the future, i.e. i<floor((t_j-t_0)/T_int))

Right. This check is useful for verifying a key, to reduce the impact
of a DoS attack where the attacker floods the receiver with random keys.
We do describe this check in the draft, look for the following in
Section 4.5: x = floor((t_j - T_0) / T_int)

To my understanding, the security condition you mention (the one described
in section 4.5) describes a check to verify that the sender "is not yet in
the interval during which it discloses the key K_i" used to calculate the
M_j packet's MAC received by the client (x<i+d).
Apart from this check, the SMUG TESLA draft was giving A SECOND security
condition: to check that interval i is not in the future (i>x); this second
check (which is, I think, different from the one described in section 4.5)
does not appear anymore in the MSEC TESLA draft and I was wondering why
(this was my question, sorry I was unclear).
<<<<<<<<<

> Could you please add some comments about F(k)=f_k (0), F'(k)=f'_k(1) : 0 ?
1 ? 

This is a standard approach for generating two computationally
indistinguishable values. The rationale is to use a cryptographic key
in only one cryptographic operation. K_i is already used to derive
K_{i-1}, so we don't want to use K_i also as the key for the MAC.

That is explained in the draft and is OK. My question was referring more
precisely about f_k(ZER0) and f'_k(ONE). But anyway, this point is not that
important for me... forget it
<<<<<<<<<

Thank you again for your time Adrian. Thanks also to Bob and Mark for the
layer placement discussion.

Sylvie