Subject: [MSEC] Re: Please comment on changes to TESLA-INTRO: (Section 3.7 to be deleted)

From: Adrian Perrig <[email-masked]>
Date: Fri, 27 May 2005 09:15:05 -0400 (EDT)

Hi,

Allowing a sender to dynamically alter the disclosure schedule of keys
is very dangerous, and removes the property of TESLA to be robust to
packet loss. Consider the following example. In packet P_i, a sender
would announce that K_j that was supposed to be published after time
T_j is now going to be published earlier. If a receiver misses this
packet, the receiver will still believe that K_j is published after
time T_j, so an attacker can forge packets for that receiver when
obtaining K_j before time T_j.

This example illustrates that it is dangerous to alter a disclosure
schedule and that is why I suggested removing Section 3.7. This
section was supposed to be removed earlier, but maybe due to version
control issues it has somehow survived.
  Adrian

> Hi all, >
> **Please note that this document is in RFC Editor Auth-48 stage, so
> please respond as soon as you can.**
>
> Adrian suggests that Section 3.7 from
> http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-intro-04.txt
> be deleted (please see Adrian's note below).
>
> I have several requests:
>
> * I-D authors referring to this document:  please check to see if this
> impacts your documents.
> * All WG members:    please comment on whether you are ok with removing
> Section 3.7.
> * Adrian:   please elaborate on the vulnerability (or post a link to a
> reference that does).
>
> Note: This is to be an informational RFC.
>
> thanks and regards,
> Lakshminath
>
>
> Russ Housley wrote:
>
> > Adrian:
> >
> > This is a fairly large change at this stage.  Since this is a MSEC WG
> > document, it should be coordinated with the WG.
> >
> > MSEC WG Chairs:
> >
> > Please confirm that this change does not impact consensus.
> >
> > Russ
> >
> > At 07:27 PM 5/23/2005, Adrian Perrig wrote:
> >
> >> Section 3.7:
> >>         The entire section must be deleted. Dynamically changing time
> >> intervals introduces a security vulnerability and TESLA loses the
> >> resilience to packet loss property.
> >
> >
> >
>
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 27 May 2005 10:02:20 -0400

Adrian,

Thanks.  As Steffen notes, if the receiver receives any legitimate 
packet after the disclosure delay change, then it would know that the 
delay has changed, right?  (Of course there is the threat of an 
adversary acting as a MiTM after a disclosure delay reduction and modify 
all pertinent information to continue to fool the victim).   
Furthermore, isn't increasing the disclosure delay ok?

I am thinking perhaps Section 3.7 could remain but with appropriate 
modifications to reflect your notes below and perhaps answering some of 
the questions above.  (As a side note, that will allow all references to 
Section 3.7 to remain, and the reader -- this is an Informational RFC -- 
would have information on whether or not dynamically changing disclosure 
delay is ok).

Thoughts?

regards,
Lakshminath
NOT as co-chair of the group

---

From: Mark Baugher <[email-masked]>
Date: Fri, 27 May 2005 10:54:39 -0700

Lakshminath,
    I don't see any value to altering the disclosure delay.

Mark
On May 27, 2005, at 7:02 AM, Lakshminath Dondeti wrote:

> adversary acting as a MiTM after a disclosure delay reduction and  
> modify all pertinent information to continue to fool the victim).    
> modifications to reflect your notes below and perhaps answering some  
> of the questions above.  (As a side note, that will allow all  
> references to Section 3.7 to remain, and the reader -- this is an  
> Informational RFC -- would have information on whether or not  
> dynamically changing disclosure delay is ok).
>
> Thoughts?
>
> regards,
> Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 27 May 2005 14:05:08 -0400

Mark,

Thanks for sharing your thoughts on this.

I don't have a specific use case in mind for this feature.  However, 
given where we are in the process, and also considering that this is an 
informational RFC, my inclination is to suggest providing information on 
the proverbial "what happens if we do this vs. that" in the soon to be 
RFC.  Deleting the section and all references to that section is 
certainly an option too.  I am proposing that providing that information 
would be useful (a record of the discussion so to speak).

When it comes to TESLA-SPEC, perhaps I will agree with a SHOULD NOT for 
changing the disclosure delay within a TESLA session.  Of course that 
goes along with a security considerations section that contains a 
summary of this discussion on what happens if the disclosure delay were 
to be changed.

best regards,
Lakshminath
(NOT as MSEC co-chair)

Mark Baugher wrote:

>> packet after the disclosure delay change, then it would know that 
>> the  delay has changed, right?  (Of course there is the threat of an

---

From: Adrian Perrig <[email-masked]>
Date: Mon, 30 May 2005 06:13:44 -0700

Hi,

Given the limited usefulness of dynamically altering the disclosure 
delay and the security vulnerability that is created by dynamically 
shortening the disclosure delay, I vote to remove this section.
For the argument that "it's good to keep it to discuss potential 
implementation errors," we would need to add a lot of other potential 
errors as well. Best,
   Adrian

---

From: Mark Baugher <[email-masked]>
Date: Tue, 31 May 2005 07:17:16 -0700

Adrian
   We might want to summarize this discussion in a sentence or two in 
the I-D in order to document what is known.

Mark
On May 30, 2005, at 6:13 AM, Adrian Perrig wrote:

>> given where we are in the process, and also considering that this is 
>> an informational RFC, my inclination is to suggest providing 
>> information on the proverbial "what happens if we do this vs. that" 
>> in the soon to be RFC.  Deleting the section and all references to 
>> that section is certainly an option too.  I am proposing that 
>> providing that information would be useful (a record of the 
>> discussion so to speak).
>> When it comes to TESLA-SPEC, perhaps I will agree with a SHOULD NOT 
>> for changing the disclosure delay within a TESLA session.  Of course 
>> that goes along with a security considerations section that contains 
>> a summary of this discussion on what happens if the disclosure delay 
>> were to be changed.
>> best regards,
>> Lakshminath
>> (NOT as MSEC co-chair)
>> Mark Baugher wrote:
>>> Lakshminath,
>>>> the  delay has changed, right?  (Of course there is the threat of 
>>>> an  adversary acting as a MiTM after a disclosure delay reduction 
>>>> and  modify all pertinent information to continue to fool the 
>>>> victim).    Furthermore, isn't increasing the disclosure delay ok?
>>>>
>>>>  modifications to reflect your notes below and perhaps answering 
>>>> some  of the questions above.  (As a side note, that will allow all