Subject: RE: [MSEC] WG Last Call for RSA-signatures draft (closing dateFriday20 August 2004)

From: <[email-masked]>
Date: Tue, 10 Aug 2004 09:51:38 -0400

Thomas,

Well, if MSEC is open to other schemes as optional standard, how about we
make comments on proposals made by me (Recall Packet scheme, Rogue Member
detection, Delegated TESLA). There was no vote or hum taken in finding if
some of those could be working group items.

On one hand MSEC veteran members criticized Recall Packet scheme being 
vulnerable to packet loss (I pointed that out myself), on the other hand
they are proposing/discussing schemes based on hash chaining which is also 
vulnerable to packet loss and IPR-ladden. I view that as hypocritical
behavior on part of veteran MSEC members.

Don't you think identifying a Rogue member in a Multicast group is an
important problem which MSEC WG can take? But there was no comment on
that either.

I donot know if you realize, going to every IETF meeting and monitoring
WG mailing lists as part of the job, is a luxury many of us can not afford.
It takes lot of efforts and convincing to be able to do that. There is 
sometimes only a small window of time in which you can do IETF work, before 
going back to regular work. I had this small window in time and I did not
get constructive feedback from MSEC working group on the work I did and 
proposed. Instead of hum, I got mum response.

If the concern is about the IPR. Not everything I proposed has IPR. Secondly,
the IPR-related work could be made as an option rather than mandatory.

Best,
Atul

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Thomas
> Hardjono
> Sent: Tuesday, August 10, 2004 1:01 AM
> To: Sharma Atul (Nokia-ES/Boston); [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [MSEC] WG Last Call for RSA-signatures draft (closing
> dateFriday20 August 2004)
> 
> 
> 
> 
> Atul,
> 
> Actually, the issue is more related to practicalities.
> 
> We need a solution that can work today and is understood by 
> the broader 
> security community in the IETF (e.g. IPsec WG, RMT WG).
> 
> This does not mean that MSEC is abandoning other solutions.  
> In fact, we 
> are still going to work on TESLA (ps. the TESLA-Intro draft 
> has already 
> done WG Last Call). We are waiting for the TESLA-specs draft to be 
> finalized and the authors OK with it going Last Call.
> 
> Bear in mind MSEC discovered that there is no single solution 
> that fits 
> all, since there are many application-areas needing 
> source-authentication 
> (e.g. routing, mobile, satellite), each with differing constraints.
> 
> So if there are other solutions out there, MSEC is open to 
> using them and 
> standardizing them.
> 
> 
> thomas
> ------
> 
> 
> 
> At 8/9/2004||07:56 AM, [email-masked] wrote:
> 
> >In the past 1+ year I have familiarized myself with the 
> problem (read the
> >literature and monitored this list), being able to do data source 
> >authentication
> >without digital signatures was the basic problem definiton 
> (including the 
> >book
> >co-authored by you).
> >
> >Now in IETF-60 we did a 180 degree turn and are saying 
> digital signatures per
> >packet are not that bad after all. How do we justify this 
> turn? Processing 
> >power
> >is increasing? Well, that means symmetric HMAC can be done 
> even faster.
> >
> >The trade-offs are listed reasonably well in the draft. Are 
> we going to 
> >propose
> >something else for endpoints which do not have enough 
> processing power?
> >
> >Denial of Service attack from outside the group is fixed by 
> a group-wide 
> >symmetric
> >HMAC. But there is no mention of DoS attacks possible from 
> within the group
> >sending bad/spoofed signatures.
> >
> >In presence of multiple senders, how would a receiver pick the right 
> >public key.
> >This is not made explicit in the document. I would expect 
> that from a 
> >document in
> >the last call.
> >
> >One factual inconsistency: Section 2.0 mention minimum RSA 
> modulus size
> >496 bits(62 bytes). But Section 3.0 implies minimum being 61 bytes.
> >
> >Atul
> >
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of ext Thomas
> > > Hardjono
> > > Sent: Friday, August 06, 2004 2:11 PM
> > > To: MSEC MSEC
> > > Cc: [email-masked]
> > > Subject: [MSEC] WG Last Call for RSA-signatures draft 
> (closing date
> > > Friday20 August 2004)
> > >
> > >
> > >
> > >
> > > Folks,
> > >
> > > As mentioned in the MSEC WG meeting this week at IETF60, the
> > > RSA-signatures
> > > draft is ready for WG Last Call.
> > >
> > > You can get the latest version here:
> > > http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-sign
> >atures-01.txt
> >
> >Therefore, we would like to begin WG Last Call for this 
> draft, with a closing
> >date of Friday 20 August 2004.
> >
> >Please send your comments to the list a.s.a.p.
> >
> >Regards.
> >
> >thomas
> >------
> >
> >
> >
> >
> >
> >__________________________________
> >Do you Yahoo!?
> >New and Improved Yahoo! Mail - 100MB free storage!
> >http://promotions.yahoo.com/new_mail
> >_______________________________________________
> >msec mailing list
> >[email-masked]
> >http://six.pairlist.net/mailman/listinfo/msec
> >_______________________________________________
> >msec mailing list
> >[email-masked]
> >http://six.pairlist.net/mailman/listinfo/msec
> 
> _______________________________________________
> msec mailing list
> [email-masked]
> http://six.pairlist.net/mailman/listinfo/msec
> 
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Tue, 10 Aug 2004 12:27:27 -0400

Atul,

I will ignore your non-technical comments and address the differences 
between your "Recall Packet scheme" and hash chaining:

First, there are ways to get around packet losses in hash chaining.  I 
recall seeing some related references in your I-D, so you are aware of 
them.  The catch, as I noted in the meeting during your presentation, is 
that the per-packet overhead quickly approaches the overhead of the 
RSA-sig scheme.

More importantly, if a packet is lost while hash chaining is being used, 
the receivers cannot verify one or more packets and will drop it/them.  
If I understand your scheme correctly, if a recall packet is lost, 
receivers accept a potentially compromised packet as a legitimate packet.

regards,
Lakshminath

(on IPR issues, see Hugh's comments.  Other than that, I think if the 
I-D I am working on is generic enough, then any hash chaining scheme 
should be able to use it.  That might be difficult, but I think we 
should try).

On Rogue member detection, I think that's out of MSEC charter.  If you 
want to discuss rogue member detection w.r.t. message integrity attacks, 
and/or traitor tracing w.r.t members who might be leaking data to 
non-members, and other similar topics, you are welcome to bring your 
work to GSEC.   Please send Pete and I an email.  Thanks.

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 10 Aug 2004 17:21:26 -0700 (PDT)

Hi Atul,

Apologies for replying late - my current meeting location has no IP connection
for guests, so I have to wait until I get back to the hotel to do emails.

With regards to the openness of the MSEC to new schemes, seeing the quietness
of the group it is quite natural to think that MSEC (or other IETF WGs) has no
interest in other schemes.

Actually, some of the old-timers have been attending for the last 5 years (from
the SMuG days), so are probably exhausted with multicast security :-)  Also,
many people have less bandwidth today since their employers are burdening more
work on them.

BTW. he lack of questions or humming or hands-up is not any reliable indication
of interest in the audience.  The reverse is also true (eg. the PERM BOF). 
Many people in the audience usually have not read the drafts.

So, I'd like to encourage you to submit your work and get it discussed in the
mailing-list.

cheers,

thomas
------

		
New and Improved Yahoo! Mail - Send 10MB messages!