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

From: <[email-masked]>
Date: Tue, 10 Aug 2004 13:01:02 -0400

Lakshminath,

You are not correct in stating that per packet ovehead of Recall Packet
Scheme will be that of RSA-Sig scheme. May be you are confusing that with
Delegated Authentication, the other scheme I presented, where the per-packet
overhead can approach that of RSA-Sig scheme. Recall packet scheme does not
incur such overheads.

You are right though, a loss of Recall packet in Recall Packet scheme would
mean an illegitimate packet being accepted. Basically packet loss will be
manifested as a different symptom for different schemes. It will be tough
to argue which symptom is acceptable and which symptom is not.

BR,
Atul

> -----Original Message-----
> From: ext Dondeti, Lakshminath [mailto:[email-masked]]
> Sent: Tuesday, August 10, 2004 12:27 PM
> To: Sharma Atul (Nokia-ES/Boston)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [MSEC] WG Last Call for RSA-signatures draft
> (closingdateFriday20 August 2004)
> 
> 
> 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.
> [email-masked] wrote:
> 
> >
> > 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
> >
> 
> 
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

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

Clarification: per-packet overhead in some hash chaining schemes, e.g., 
EMSS is about the same as (e.g., 6-degree hash chain would amount to 
120B of overhead) RSA-sig.  I don't know the overhead of your recall 
packet scheme.

Please clarify this: do you mean that it is ok in some cases to accept 
unverifiable packets as legitimate?  Apologies if that's not what you meant.

regards,
Lakshminath