Subject: [MSEC] Re: draft-ietf-msec-tesla-for-alc-norm-00.txt submission

From: canetti <[email-masked]>
Date: Thu, 15 Jun 2006 16:50:30 -0400 (EDT)

Vincent,

Overall the draft looks very good!
Here are some remarks:

-First line: Should say msec, not rmt.

section 3.1: To avoid confusion, its probably good to say here too that
the synchronization message from sender to receiver is to be signed, and
the signature should be verified.

4.3.1: which fields are to be covered by the signature in the bootstrap
message?

regarding whether to force rejection of packets where the authentication
failed (editor note on page 30). I'd try to poll the list on this issue,
and perhaps reach a rough consensus.

security considerations: it's perhaps worthwhile to discuss dos issues
which are specific to ALC - eg, the fact that even a single corrupted
packet can ruin an entire encoded stream. this also may be an argument in
the discussion on the previous issue.

best,

Ran

On Thu, 15 Jun 2006, Vincent Roca wrote:

> Hello,
>
> I have attached to this email an update of version 00 of the MSEC WG I-D:
>
>             The Use of TESLA in the ALC and NORM Protocols
>              draft-ietf-msec-tesla-for-alc-norm-00.txt
>
> Thanks a lot.
> Regards,
>
>   Vincent / Aurelien / Sebastien
>
> ------------------------------- http://planete.inrialpes.fr/~roca/
>  INRIA Rhone-Alpes - projet planete      [email-masked]
>  Zirst; 655 av. de l'Europe; Montbonnot  phone (+33) 4.76.61.52.16
>  38334 ST ISMIER cedex - France          fax   (+33) 4.76.61.52.52
>
>
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Vincent Roca <[email-masked]>
Date: Tue, 20 Jun 2006 16:15:08 +0200

Hello Ran,

> -First line: Should say msec, not rmt.
Corrected!

> the signature should be verified.
Well, this is already said in the 2nd and 3rd bullets. Or do you have in 
mind
another section?

> 4.3.1: which fields are to be covered by the signature in the bootstrap
Good point. I'll clarify it.

> and perhaps reach a rough consensus.
Yes. RFC4082, Section 3.5 (bullets 1, 3 and 4) says that these unsafe 
packets
__should__ be discarded. We say in the current I-D version that they
__MUST__ be discarded. If there are situations where accepting
unsafe/unauthenticated makes sense, then "SHOULD" is the right keyword.
Otherwise "MUST" is more appropriate.

We can also add a sentence explaining that using TESLA is anyway not
mandatory, and that a receiver can at any time decide to move to an unsafe
mode by ignoring all TESLA extensions. But this is done intentionally.

> the discussion on the previous issue.
Yes, we need to finalize Section 7.  "Security Considerations".

Thanks a lot for your comments!

Regards,

   Vincent

---

From: canetti <[email-masked]>
Date: Tue, 20 Jun 2006 11:53:07 -0400 (EDT)

Vincent,

> Well, this is already said in the 2nd and 3rd bullets. Or do you have in

OK. missed that. it's probably good as is.

> mode by ignoring all TESLA extensions. But this is done intentionally.

this is fine with me. I seem to recall that some people had reservations
about forcing a discard. If someone wants to object, then this is the
time...

Ran