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

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 01 Jun 2005 17:33:11 -0400

Hi Adrian,

Mark's suggestion sounds good to me.  I can't say there is any consensus 
on this one way or another, but we need to close this ASAP.

All,

We need opinions on this to reach consensus.

regards,
Lakshminath

Mark Baugher wrote:

> 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:
>
>> 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
>>
>>> 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:
>>>
>>>> Lakshminath,
>>>>    I don't see any value to altering the disclosure delay.
>>>>
>>>> Mark
>>>> On May 27, 2005, at 7:02 AM, Lakshminath Dondeti wrote:
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>> Adrian Perrig wrote:
>>>>>
>>>>>> 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: Tue, 07 Jun 2005 13:00:59 -0400

Hi Adrian/Dawn/Bob/Doug/Ran,

I saw several OoO messages in response to my emails last week, with back 
in office time as this week.  Let us please close discussion on this 
I-D/RFC and make the necessary changes so the RFC Editor can publish it.

I strongly think it does not hurt to keep the content of Section 3.7 
(revised of course).  If you feel that section must be deleted, please 
include a few sentences in the security considerations on this topic.  I 
think that is a fair compromise so we can move forward.

Please respond to this email on your decision and send your changes to 
the RFC Editor.  If 3.7 is to be deleted, please make sure -- as Bob 
noted -- that all references to 3.7 are also deleted.

Many thanks for your work on this and also for your thorough reviews.

best regards,
Lakshminath

PS:  I am going to be taking time-off on Wed and Thu, so might not be 
able to hold an email conversation.

Lakshminath Dondeti wrote:

> Hi Adrian,
>
> Mark's suggestion sounds good to me.  I can't say there is any 
> consensus on this one way or another, but we need to close this ASAP.
>
> All,
>
>>> implementation errors," we would need to add a lot of other 
>>> potential errors as well. Best,
>>>   Adrian
>>>
>>>> Mark,
>>>> 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).
>>>> 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,
>>>>>> 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?
>>>>>>
>>>>>> 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 
>>>>>>> Allowing a sender to dynamically alter the disclosure schedule 
>>>>>>> of keys

---

From: Adrian Perrig <[email-masked]>
Date: Fri, 10 Jun 2005 09:50:48 -0400 (EDT)

Hi,

Sorry for the delay with this, I have been traveling. Given the
consensus of the MSEC community, we have worked out the following
changes to the draft, for completeness, I also add my earlier changes
and the second round of changes that Bob Briscoe suggested. Best
wishes,
  Adrian

Section 5 (Security Considerations), add the following as second
paragraph.
NEW:

It should be noted that a change to the key disclosure schedule for a
message stream should never be declared within the message stream
itself. This would introduce a vulnerability, because a receiver that
did not receive the notification of the change would still believe in
the old key disclosure schedule.

>Section 2, last line of the bullet list:
>OLD:
>         others later.
>
>NEW:
>         a third party.
>
>Section 2.2, first sentence of first item.
>OLD:
>         1.  The sender and the receiver must be
>         able to synchronize loosely.
>
>NEW:
>         1.  The sender and the receiver must be
>         loosely time synchronized.
>         ^^^^^^^^^^^^^^^^^^^^^^^^^
>
>Section 2.2, final item (unitemize).
>OLD:
>       4.  We would like to emphasize that the security of TESLA does
NOT
>           rely on any assumptions about network propagation delay.
>NEW:
>    We would like to emphasize that the security of TESLA does NOT
>    rely on any assumptions about network propagation delay.
>
>Section 3.2, 4th paragraph
>OLD:
>         It is stressed that the scheme remains secure for any
>         values of T_int and d.
>NEW:
>         It is stressed that the scheme remains secure for any
>         values of T_int and d>0.
>                              ^^
>Section 3.3, last sentence of 2nd bullet
>OLD:
>         signature against the public key of the signer.)
>NEW:
>         signature with the public key of the signer.)
>                   ^^^^
>Section 3.3, 3rd bullet
>OLD:
>         - T_0, the start time of interval 1.
>NEW:
>         - T_0, the start time of interval 0.
>                                           ^
>Section 3.7:
>         The entire section must be deleted. Dynamically changing
time
> resilience to packet loss property.

Table of Contents

OLD:
       3.7. An Alternative Delay Description Method ...................13
       3.8. Denial of Service Protection ..............................14
            3.8.1. Additional Group Authentication ....................15
            3.8.2. Not Re-using Keys ..................................15
            3.8.3. Sender Buffering ...................................18

NEW (page numbering will also need altering):
       3.7. Denial of Service Protection ..............................14
            3.7.1. Additional Group Authentication ....................15
            3.7.2. Not Re-using Keys ..................................15
            3.7.3. Sender Buffering ...................................18

Section 3.6 penultimate paragraph. (Delete last sentence)

OLD:
                                                       If such
    authentication delay is too pessimistic, the adaptive approach of
    Section 3.7 may be an alternative, with the expense of extra
packet
    overhead.

NEW: (sentence deleted)

Section 3.7.2 (renumber to section 3.7.2)

OLD:
                              The rule of thumb for calculating d, the
    key disclosure delay, remains unchanged from that given in Section
    3.6; or the explicit disclosure delay method in Section 3.7 can
also
    be used.

NEW: (last clause deleted)
                              The rule of thumb for calculating d, the
    key disclosure delay, remains unchanged from that given in Section
    3.6.
       ^

>Section 7
>
>OLD:
>         [6]  P. Rohatgi, "A hybrid signature scheme for multicast
source
>         authentication", Work in Progress, June 1999.
>
>NEW (drop reference as it is redundant with reference [5]: