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

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

So, instead, we want to develop solutions for the "good of the operator",
whether they are willing to pay for it or not?

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.

Gary

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, June 04, 2001 12:39 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Michael Thomas'; [email-masked]'; 'seamoby'; 'Pat Calhoun';
> [email-masked]
> Subject: RE: Comments Re: [seamoby] ct problem statement
> 
> 
> Gary Kenward writes:
>  > Well, to begin with, "at the operators option" would include
>  > the option to provide privacy or not to the service users. In
>  > a competitive environment, the user could then decide whether to
>  > subscribe to the service or not, if that privacy was not provided.
> 
>    The problem is that a user has no way of knowing.
> 
>  > As for securing "keys" (which is necessary to maintain the 
> committed
>  > level of security that operator has chosen to support), as 
> been discussed
>  > repeatedly on this list, no one has suggesting 
> transferring keys openly.
>  > What I stated was that I do not understand where the 
> requirements for CT
>  > differ from any other secure data transfer between peers.
> 
>    Stating in the problem statement, requirements,
>    or the protocol itself that an operator can
>    administratively turn off security _at all_
>    sends a very bad message. As in, vendors won't
>    bother implementing it since it's not required,
>    and operators won't bother turning it on since
>    it's a hassle and RFC nnnn says that's OK. 
>    
>    We really do not need to go there.
> 
> 	Mike
>  > 
>  > Gary
>  > 
>  > > -----Original Message-----
>  > > From: Michael Thomas [mailto:[email-masked]]
>  > > Sent: Monday, June 04, 2001 11:33 AM
>  > > To: Kenward, Gary [WDLN2:AN10:EXCH]
>  > > Cc: [email-masked]'; 'seamoby'; 'Pat Calhoun'; [email-masked]
>  > > Subject: RE: Comments Re: [seamoby] ct problem statement
>  > > 
>  > > 
>  > > Gary Kenward writes:
>  > >  >   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? 
>  > >  > 
>  > >  >   I personally don't see any new vulnerabilities; based 
>  > > upon my superficial
>  > >  > understanding of security, I read the examples you have 
>  > > provided as specific
>  > >  > instances of general security problems which I understood 
>  > > to have been
>  > >  > addressed. In other words, how are these scenarios not 
>  > > already addressed by
>  > >  > the existing security solutions?
>  > >  > 
>  > >  >   I am not against providing security for ct - not at all. 
>  > > However, I do
>  > >  > want to ensure that security remains an option to the 
>  > > operator (and is not
>  > >  > build into the protocol), the overhead imparted the ct can 
>  > > be minimized, and
>  > >  > the performance goals attained.
>  > > 
>  > >    Anything that transfers keys of any kind cannot be
>  > >    done "at the operator's option". There are also
>  > >    privacy issues which must be preserved for the MN
>  > >    as well. At a base level, any transfer of context
>  > >    must be at least as secure the mechanisms the
>  > >    MN and AR used to create the original context. 
>  > >    Anything less is a breach to the MN.
>  > > 
>  > > 	    Mike
>  > > 
>  > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
>  > <HTML>
>  > <HEAD>
>  > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; 
> charset=ISO-8859-1">
>  > <META NAME="Generator" CONTENT="MS Exchange Server version 
> 5.5.2654.59">
>  > <TITLE>RE: Comments Re: [seamoby] ct problem statement</TITLE>
>  > </HEAD>
>  > <BODY>
>  > 
>  > <P><FONT SIZE=2>Well, to begin with, &quot;at the 
> operators option&quot; would include</FONT>
>  > <BR><FONT SIZE=2>the option to provide privacy or not to 
> the service users. In</FONT>
>  > <BR><FONT SIZE=2>a competitive environment, the user could 
> then decide whether to</FONT>
>  > <BR><FONT SIZE=2>subscribe to the service or not, if that 
> privacy was not provided.</FONT>
>  > </P>
>  > 
>  > <P><FONT SIZE=2>As for securing &quot;keys&quot; (which is 
> necessary to maintain the committed</FONT>
>  > <BR><FONT SIZE=2>level of security that operator has 
> chosen to support), as been discussed repeatedly on this 
> list, no one has suggesting transferring keys openly. What I 
> stated was that I do not understand where the requirements 
> for CT differ from any other secure data transfer between 
> peers.</FONT></P>
>  > 
>  > <P><FONT SIZE=2>Gary</FONT>
>  > </P>
>  > 
>  > <P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
>  > <BR><FONT SIZE=2>&gt; From: Michael Thomas [<A 
> HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
>  > <BR><FONT SIZE=2>&gt; Sent: Monday, June 04, 2001 11:33 AM</FONT>
>  > <BR><FONT SIZE=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
>  > <BR><FONT SIZE=2>&gt; Cc: [email-masked]'; 'seamoby'; 
> 'Pat Calhoun'; [email-masked]</FONT>
>  > <BR><FONT SIZE=2>&gt; Subject: RE: Comments Re: [seamoby] 
> ct problem statement</FONT>
>  > <BR><FONT SIZE=2>&gt; </FONT>
>  > <BR><FONT SIZE=2>&gt; </FONT>
>  > <BR><FONT SIZE=2>&gt; Gary Kenward writes:</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp; &gt;&nbsp;&nbsp; The second 
> point troubles me somewhat: ct is essentially </FONT>
>  > <BR><FONT SIZE=2>&gt; an information</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp; &gt; transfer operation. I do 
> not understand (and I can only </FONT>
>  > <BR><FONT SIZE=2>&gt; state this as my</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp; &gt; being confusion) why it 
> is not enough to say that this </FONT>
>  > <BR><FONT SIZE=2>&gt; information transfer</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp; &gt; must be secure. Why would 
> a ct be any different from any </FONT>
>  > <BR><FONT SIZE=2>&gt; other data transfer</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp; &gt; that needs to be secured? </FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp; &gt; </FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp; &gt;&nbsp;&nbsp; I personally 
> don't see any new vulnerabilities; based </FONT>
>  > <BR><FONT SIZE=2>&gt; upon my superficial</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp; &gt; understanding of 
> security, I read the examples you have </FONT>
>  > <BR><FONT SIZE=2>&gt; provided as specific</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp; &gt; instances of general 
> security problems which I understood </FONT>
>  > <BR><FONT SIZE=2>&gt; to have been</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp; &gt; addressed. In other 
> words, how are these scenarios not </FONT>
>  > <BR><FONT SIZE=2>&gt; already addressed by</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp; &gt; the existing security 
> solutions?</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp; &gt; </FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp; &gt;&nbsp;&nbsp; I am not 
> against providing security for ct - not at all. </FONT>
>  > <BR><FONT SIZE=2>&gt; However, I do</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp; &gt; want to ensure that 
> security remains an option to the </FONT>
>  > <BR><FONT SIZE=2>&gt; operator (and is not</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp; &gt; build into the protocol), 
> the overhead imparted the ct can </FONT>
>  > <BR><FONT SIZE=2>&gt; be minimized, and</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp; &gt; the performance goals 
> attained.</FONT>
>  > <BR><FONT SIZE=2>&gt; </FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Anything that 
> transfers keys of any kind cannot be</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; done &quot;at the 
> operator's option&quot;. There are also</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; privacy issues 
> which must be preserved for the MN</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; as well. At a base 
> level, any transfer of context</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; must be at least 
> as secure the mechanisms the</FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; MN and AR used to 
> create the original context. </FONT>
>  > <BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Anything less is a 
> breach to the MN.</FONT>
>  > <BR><FONT SIZE=2>&gt; </FONT>
>  > <BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
> &nbsp;&nbsp;&nbsp; Mike</FONT>
>  > <BR><FONT SIZE=2>&gt; </FONT>
>  > </P>
>  > 
>  > </BODY>
>  > </HTML>
>

---

From: Michael Thomas <[email-masked]>
Date: Mon, 4 Jun 2001 10:16:14 -0700 (PDT)

> 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.

 > simply have to find a manufacturer who is willing to provide the capability

   No, let's not. The *user* figures in here too, and the
   resulting RFC's should not allow for equivocation on this.

	     Mike