Subject: RE: [MSEC] Brief summary of msec meeting at 58th IETF

From: <[email-masked]>
Date: Wed, 12 Nov 2003 10:42:25 +0200

(Sorry for my ignorance but...)

Why is Tesla going informational - it may not help the Internet Community much there.

Rod.

> -----Original Message-----
> From: [email-masked]
> Subject: [MSEC] Brief summary of msec meeting at 58th IETF
> 
> Folks,
> 
> Following is a brief summary of MSEC meeting in 58th IETF, and the
> expected deliverables within the coming months. (This is NOT
> the minutes. These will come later.)
...
> * Last call for the TESLA informational draft

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: canetti <[email-masked]>
Date: Wed, 12 Nov 2003 09:03:21 -0500 (EST)

Rod,

Thanks for asking, indeed the summary was not clear on that point.
The plan is to have, in addition to the general informational draft on
TESLA mentioned in the summary, a standards-track draft that describes how
to use TESLA within ESP. (This is part of the update of the  MESP draft.) 

In fact, let me use this chance to elaborate on the plans regarding
the update of the MESP draft. The plan is to have the update address
the following points:
-The direct use of ESP rather than a separate transform (MESP)
-How to do replay protection in case of multiple senders
-How to do TESLA-based source authentication
-How to do source authentication based on signing each packet 

Right now Mark Baugher, Brian Weis and myself have committed to working on
it. More volunteers are welcome.

Another issue here is whether to describe the three "How to do"s 
in a single draft or in three separate, more focused drafts. Our current
tendency is to go for separate drafts. Any thougts, any one?

Ran

---

From: Brian Weis <[email-masked]>
Date: Wed, 12 Nov 2003 09:03:45 -0800

> tendency is to go for separate drafts. Any thougts, any one?

My opinion is that we would be best off to have a data transforms
document that describes the general issues of data transforms when
applied to multicast packets. E.g., general issues with source
authentication, and replay protection for multiple senders. This gives
informational guidance to implements of data transforms, just as GKMARCH
does for key management protocols.

Then there need to be documents applying those concepts to specific data
transforms. For example, we need normative documents to define how to
deal with source authentication (e.g., TESLA) in ESP, following the
rules in RFC 2406bis and RFC 2401bis. However, another document might
describe how to do source authentication in the context of SRTP, which
has different processing rules. I don't expect these documents to be
much more complicated or involved than RFC 2404 ("The Use of
HMAC-SHA-1-96 within ESP and AH"). The key is that they are focused, and
provide exact guidance for an implementor of a particular data
transform. As an example of what I've proposing see:
	http://www.ietf.org/internet-drafts/draft-bew-ipsec-signatures-01.txt

Thanks,
Brian

-- 
Brian Weis
Strategic Cryptographic Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: canetti <[email-masked]>
Date: Wed, 12 Nov 2003 13:10:04 -0500 (EST)

Brian,

I agree that in order to have a complete and good coverage of the data
transforms area we need an "atchitectural" data transforms document
on the level of GKMARCH. In fact, it was in the plans at some point in the
past but got overlooked. Also documents specifying application/transport
layer transforms within MSEC (such as SRTP) are welcome.

So, in all, we're looking at the following set of drafts:

1 TESLA introductory (informational)

2 Data transforms architecture (informational)
  
3 ESP with digital signatures (standards track)
4 ESP with TESLA (standards track)
5 ESP with multiple senders (standards track)

potential additional drafts:

6 SRTP within MSEC (with TESLA? signatures?) (standards track)
7 ESP with chained signatures (standards track)  (this is Lakshminath's
  suggestion)

Drafts 1, 3 are practically written. Also for 4 there is a pretty good
rough draft. 5 should not be much work. 6 should be a medium-size task,
whereas 2 and 7 are probably more work. Definitely we have all the
knowledge needed for writing these drafts. Hopefully with enough
volunteers we can get the writing done in time and keep Thomas happy.. :)

Ran