Subject: RE: Comments Re: [seamoby] ct problem statement

From: "Gary Kenward" <[email-masked]>
Date: Mon, 4 Jun 2001 13:49:01 -0400

The user must be considered, but while you consider an operator
that does not provide privacy as "shoddy", I (and others), consider
efficient and responsive to their customers. I do not want to pay
for a service that I do not need.

Gary

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, June 04, 2001 1:16 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Michael Thomas'; 'seamoby'
> Subject: RE: Comments Re: [seamoby] ct problem statement
> 
> 
> Gary Kenward writes:
>  > So, instead, we want to develop solutions for the "good of 
> the operator",
>  > whether they are willing to pay for it or not?
> 
>    There are any number of ways that a shoddy operator
>    can find to provide shoddy service. The IETF doesn't
>    need to provide helpful hints.
> 
>  > A moot point, really, for if an operator does not want a 
> feature, they
>  > simply have to find a manufacturer who is willing to 
> provide the capability
>  > to the feature off.
>  > 
>  > Let's move on.
> 
>    No, let's not. The *user* figures in here too, and the
>    resulting RFC's should not allow for equivocation on this.
> 
> 	     Mike
>

---

From: Allison Mankin <[email-masked]>
Date: Fri, 08 Jun 2001 09:26:03 -0400

All,

I've been reading carefully the thread caused by my request to enhance 
the security considerations in the CT problem statement.  My
request reflects the view that IESG will take.  In the past, an AD
might have worked quietly with the editor and chair and then given the WG
a last look, but the TSV area is trying to do the AD jobs as much as possible
in the open now.  

We've gained by seeing the wide range of the WG's understandings of 
security in seamoby protocols.

A few overall points, also made by others, that I want to underline:

IETF security technologies are generally expressed as mandatory-to-
implement but optional to deploy.  Although vendors can elect to
speed or price-cut their product by ignoring the mandatory-to-implement,
they are nort then honest if they say they comply with the IETF standard.
That's their choice, absolutely.

Security considerations in a draft express risks that a user or
operator may encounter, to help guide the decision about whether to
deploy the available technology (and also whether to deploy a compliant 
product rather than one that lacks security protections).

Going all the way back to Monday, Gary asked:

>   The second point troubles me somewhat: ct is essentially an information 
> transfer operation. I do not understand (and I can only state this as my 
> being confusion) why it is not enough to say that this information transfer 
> must be secure. Why would a ct be any different from any other data transfer 
> that needs to be secured?  

Besides the content transferred being given appropriate data confidentiality
and integrity, the authority given to a CT arriving needs protection.  
Unlike an arbitrary user message, CT information quite possible can change
what happens to the flow - unauthorized CT information that is accepted
could alter characteristics the user paid or could disrupt the operator
(service could be stolen).  Note, both user and _operator_ have risks.

All risks won't be identified and some won't have solutionss - as 
a number of people in the thread noted,  some of the risks, such as 
general denial of service, are very hard to remedy.  

I would like to recommend that the requirements documents for each
seamoby protocol include a section on a threat model.  This
should be the threats specific to the protocol, not all aspects of
securing a (wireless) internet.  As with all IETF work, the goal is
not to try for perfection, but to add to everyone's technical 
depth in a best effort.

Another recommendation I'll make is for more security experts
to be involved in the seamoby protocol designs early on.  I'm working
on pointing some folks who haven't been involved into the requirements
document work now.   A goal will be able to state requirements and
not have to create new technology to serve them.  

There'll be plenty of chance to complain, like I need to offer this ;>.

Allison