Subject: Re: [MSEC] MUST/MAY discard unverifiable (draft-ietf-msec-srtp-tesla- 02.txt)

From: Bob Briscoe <[email-masked]>
Date: Fri, 03 Dec 2004 17:37:49 +0000

Lakshminath,

At 16:23 30/11/2004, Dondeti, Lakshminath wrote:
>I would use - as you also mention - IPsec RFCs as a guideline.  RFC2402 
>says "MUST discard" if the ICV test fails.  In the same spirit, if 'TESLA 
>verifications' fail, the MSEC-SRTP-TESLA spec should say that the receiver 
>MUST discard packets.

I should have made it clearer that I am discussing the case concerning 
inability to verify, not failure of verification.

This condition doesn't arise in unicast IPsec, so I don't think we can turn 
to it for guidance.

>The other guideline I would cite is from Section 4.4 of RFC 2401,
>
>"compliant implementations need not match details of this model as 
>presented, but the external behavior of such implementations must be 
>mappable to the externally observable characteristics of this model."
>
>Given all that, and if the TESLA spec says "MAY" then some receivers might 
>end up with a different copy of the stream than others, with all 
>implementations being "RFC-compliant"; and that is unacceptable!

I am deliberately advocating that each receiver's verifier should be 
allowed to present different results to the next layer. In multicast this 
is the norm - eg different branches of a multicast tree see uncorrelated 
losses, and usually reliable multicast isn't used in RTP, so each receiver 
sees a different stream.

As I just explained to Elisabetta, receiver verification actually involves 
4 steps. I am only advocating "MAY discard" for one: the delay safety test. 
If that fails, TESLA cannot verify packets (ie nothing can be proved about 
verification, as opposed it can be proved a packet has failed 
verification). Even if we said "MUST discard" here, different delays on 
different branches could lead to each receiver discarding different sets of 
packets.

Different receivers should be able to choose whether they take a risk when 
the authentication mechanism can tell them nothing about authenticity. 
Unicast IPsec can't help us as it has deterministic verification. 
Indeterminate verification is a new situtation that TESLA introduces. So we 
have to go back to first principles and think what various applications 
might want.

Bob

>regards,
>Lakshminath
>
>Bob Briscoe wrote:
>
>>Mark, Elisabetta,
>>
>>Returning to this subject after a long break (purely my fault)...
>>
>>At 19:24 14/09/2004, Mark Baugher wrote:
>>
>> >On Sep 14, 2004, at 11:55 AM, Mark Baugher wrote:
>> >
>> >>On Sep 14, 2004, at 9:58 AM, Bob Briscoe wrote:
>> >>>>5/ Discard if a packet cannot be authenticated should be optional
>> >>>= Agreed
>> >>
>> >>I did not sign up for this one - or at least I did not mean to.  I'd
>> >>like to discuss this some more.  Personally, I want to limit options
>> >>wherever possible and this is the second option (including making the
>> >>group [MAC] optional)
>> >>that you have proposed.  I don't think we necessarily want to add this
>> >>particular option and would like to hear what others have to say on
>> >>the matter.
>> >>
>> >>thanks, Mark
>>
>>If a packet cannot be authenticated, whether to drop it or not can be
>>chosen unilaterally by the receiver. It isn't a *protocol* option. It is a
>>receiver choice. If it cannot be verified, it doesn't complicate the
>>protocol to say the receiver MAY rather than MUST drop a packet.
>>
>>My view remains that it is over-prescriptive to tell a receiver it MUST
>>drop a packet. Indeed, whatever we say in the RFC, applications will be
>>free to do what they like. The balance between the value of
>>rendering-quality and authenticity is up to the application, not us.
>>
>>Quoting the RFC Editor's policy:
>>"...Imperatives ... MUST only be used where it is actually required for
>>interoperation or to limit behavior which has potential for causing harm
>>(e.g., limiting retransmissions). For example, they must not be used to try
>>to impose a particular method on implementors where the method is not
>>required for interoperability."
>>
>>                                  ---
>>
>>But there *is* a potential protocol issue here (which applies to all
>>authentication protocols, IPsec as much as TESLA). Application(s) 'above'
>>verification in the stack (e.g. rendering, congestion control, intrustion
>>detection) may need to distinguish the difference between discard due to:
>>- congestion/corruption
>>- proven malicious attack
>>- indeterminate authentication (in TESLA due to network delay *or* an attack)
>>
>>For intrustion detection, these can be distinguished by logging different
>>types of security event, as specified in the srtp-tesla draft.
>>
>>But, congestion control usually works purely on packet delivery (I don't
>>think SRTP says anything about whether verification is done before or after
>>congestion control).
>>
>>Yes, proven attack packets should be discarded (after logging), because
>>they aren't part of the stream sent by the genuine sender. But if packets
>>can't be verified they shouldn't necessarily just be discarded:
>>- If they were genuine packets, congestion control will respond wrongly if
>>they *are* discarded
>>- If they were attack packets, congestion control will respond wrongly if
>>they *aren't* discarded.
>>
>>Of course, the same is true of rendering:
>>- If they were genuine packets, rendering will respond wrongly if they
>>*are* discarded
>>- If they were attack packets, rendering will respond wrongly if they
>>*aren't* discarded.
>>
>>So, in order not to complicate the spec, I still maintain we should say (in
>>section 4.4)
>>
>>
>>"...If the safe condition does not hold, the packet MAY [not MUST] be
>>     discarded, and the event SHOULD be logged."
>>
>>
>>
>>In these cases, it is up to the receiving system to decide whether such
>>packets are more likely to be genuine or malicious, choosing whether to use
>>or discard the packet. With consequent consistent effects on congestion
>>control, rendering etc.
>>
>>There is a natural tendency for security people to be conservative under
>>uncertainty. But we have to remember security must be balanced by usability.
>>
>>Bob
>>
>>____________________________________________________________________________
>>Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
>>B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.   +44 1473 645196
>>
>>
>>_______________________________________________
>>msec mailing list
>>[email-masked]
>>http://six.pairlist.net/mailman/listinfo/msec
>
>____________________________________________________________________________
>Notice: This contribution is the personal view of the author and does not 
>necessarily reflect the technical nor commercial direction of BT plc.
>____________________________________________________________________________
>Bob Briscoe,                           Networks Research Centre, BT Research
>B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.   +44 1473 645196 

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

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Fri, 03 Dec 2004 14:20:28 -0500

Bob,

Many thanks for your comments.  Yes, indeed multicast receivers may in 
fact have different copies of a stream.  However, if we follow strict 
guidelines in verifying their integrity, we know for sure that each 
receiver's stream was in fact sent by the claimed sender. 

However, if we suggest the "MAY" guideline, it is plausible that some 
receivers (or may be all) have a copy that is (in part) bogus.

Perhaps, we should just write that "receivers must (not MUST, since as 
you note correctly that this is a local matter) drop packets if they 
fail TESLA verifications."  Or better yet, I would ask the chairs and 
the AD/Adviser for guidance here.  We have been arguing this forever.

regards,
Lakshminath

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 07 Dec 2004 03:51:38 +0000

Lakshminath,

>receivers (or may be all) have a copy that is (in part) bogus.

But if I don't know for sure whether some packets in a stream were sent by 
the claimed sender, do you have the right to tell me to discard them?
I may have a job to do. Authenticity is but one of my considerations.

The closest everyday analogy I can think of is accessing a Web page through 
SSL, and being warned by the browser that the certificate has expired. 
Would it have been correct for the SSL spec to say packets MUST be 
discarded if they are protected by an expired key?

But the analogy isn't perfect, because in TESLA the unsafe condition gives 
no protection at all...

>Perhaps, we should just write that "receivers must (not MUST, since as you 
>note correctly that this is a local matter) drop packets if they fail 
>TESLA verifications."

This doesn't seem to solve anything. I don't quite see why we say they must 
then?

>Or better yet, I would ask the chairs and the AD/Adviser for guidance 
>here.  We have been arguing this forever.

Please do. I'm repeating the same arguments, over.

The only reason I'm continuing, is because originally, I deliberately 
designed TESLA along open architecture principles, which can be closed if 
required (whereas the reverse isn't true). If you define a protocol for 
receivers to be loosely coupled, an application can be defined that tightly 
couples them, but not the other way round. So I'm loathe to see (perfectly 
legitimate) interest in tightly coupled design closing off what I consider 
as elegant protocol design - one which allows both styles to co-exist.

If the w-g chairs consider it necessary to go to the AD/Adviser, here's as 
brief and precise a statement as I can muster of what I believe is the problem:

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
TESLA provides a robust, lightweight solution to what is considered a hard 
problem: multicast source authentication. However, the typical TESLA 
verification mechanism cannot verify any packet that is delayed beyond a 
predefined disclosure delay. Packet delay may be caused by an attacker, but 
it can also be quite common on the Internet. So a receiver cannot be 
certain whether delay is routine or suspicious. Therefore, if packets have 
been delayed beyond a threshold, they effectively have to be treated as if 
authentication hadn't been applied. Even though the sender considered TESLA 
source authentication necessary.

In the process of standardising TESLA for use in secure multicast RTP, some 
in the working group believe we should mandate that packets delayed beyond 
this threshold MUST be discarded. Others believe we should recommend that 
they SHOULD be discarded, but that the receiver may choose to use them at 
its own risk.

The "MUST discard" position is justified on protocol safety grounds, making 
the meaning of packet delivery unambiguous, with no packets being delivered 
unless they are positively verified. The "SHOULD discard" position is 
justified on the grounds of receiver autonomy: so that some may choose to 
use unverifiable packets if their need outweighs the risk, but that usually 
they shouldn't.

Is there guidance on which of these two concerns is paramount? Or is there 
another textual device to reconcile these two positions?
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Cheers

Bob