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

From: "Gary Kenward" <[email-masked]>
Date: Tue, 5 Jun 2001 11:19:09 -0400

> -----Original Message-----
> From: Kulwinder Atwal [mailto:[email-masked]]
> Sent: Monday, June 04, 2001 6:44 PM
> To: 'Michael Thomas'; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'
> Subject: RE: Comments Re: [seamoby] ct problem statement
> 
> 
> 
> 
> > -----Original Message-----
> > From: Michael Thomas [mailto:[email-masked]]
> > Sent: Monday, June 04, 2001 1:16 PM
> > To: Gary Kenward
> > 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
> > 
> 
> What if it is a private wireless network where there is no 
> competition?
> 
> What if the private operator is an employer/government 
> agency, or other
> entity where the wireless service is provided as a way to 
> delivery content
> that is only available from a single 
> employer/company/government agency?
> 
> Does the user find another job to work at, or another country 
> to live in?

I guess so. What if the CIA decides to record all your email and pass
it through their supercomputers for a week. Would you feel your privacy is
safe? 

I willing to bet that none of the security experts would
be willing to state that any protocol solution is going to protect you
if the operator is unwilling or against supporting it, particularly if 
they are the government. 

The IETF does not, can not force compliance, it can only recommend.
And as you have identified, there is no one who has the authority to
force compliance.

The truth is out there ;^}

Gary

> - Kulwinder.

---

From: Mark Smith <[email-masked]>
Date: Tue, 05 Jun 2001 09:01:56 -0700

> it through their supercomputers for a week. Would you feel your privacy is

If I believe in the system and the underlying encryption, yes.  Do I 
believe that the NSA (to whom the CIA would pass the data for 
processing) has solved the NP-Complete problem yet?  If they have, 
they've mannaged to keep their hats on probably one of the biggest 
mathimatical advancements in history.  I don't think it's likely at this 
point, so I trust RSA (with a large enough key.)

> if the operator is unwilling or against supporting it, particularly if

If the government is the operator, you're correct.  However, I don't 
think the government (at least, not the US goverment.  Maybe this 
argument is more applicable elsewhere) is in the wireless, mobile IP 
business, last I checked.

> And as you have identified, there is no one who has the authority to

This is true.  But the IETF _CAN_ force a good security model for 
compliance.  If you build a good security model(*) into the protocol, 
and require it, then anyone who doesn't use that good security model is 
not complient with the protocol.  If someone is going to release a 
non-standards-compliant product, there's nothing I can do about that, 
but they haven't released a CTP product.

(As an example, this is a personal beef I have with the FreeS/WAN folks. 
  Their product is _NOT_ IPSec.  It looks like IPSec, it smells like 
IPSec, it provides much of the same functionality as IPSec, but it 
doesn't (by design) support SingleDES which is a requirement of the 
IPSec protocol.  It is therefor _NOT_ IPSec compliant.)

My point to this post is to say that I believe it is our duity to treat 
the customer's content as if it were sensitive, whether they want it to 
be or not.  We, at the requirements stage, have no idea whether a 
particular MN would care whether its authentication information is 
protected or not, so we have to assume that it should be.

Just my $0.02 worth.

-Mark

(*) Where "good security model" is defined as "sufficient for the 
purpose."  Keep in mind that the idea behind security in a situation 
like this is just to make sure it's not the weakest link.  There's 
always Rubber Hose Cryptanalysis, where the Cryptanalysist beats the 
target over the head and shoulders with a rubber hose until they give up 
the information they're after.  _MUCH_ more effective than attacking the 
system or the encryption algorythm in a number of cases.

---

From: Mark Smith <[email-masked]>
Date: Tue, 05 Jun 2001 09:45:18 -0700

Not to reply to my own email, but...

> IPSec protocol.  It is therefor _NOT_ IPSec compliant.)

Just to clarify here, the FreeS/WAN folks don't impliment SingleDES, not 
because it's a Good security model, but because they believe it to be a 
Bad security model.  They believe that SingleDES is trivially breakable, 
in realtime, by readily available hardware, and is therefor no better 
than clear text.  In addition, it gives the user a false sense of 
security and is therefor WORSE than clear text.  While this is arguable 
either way, my point was that FreeS/WAN is not standards compliant 
because of this decision, not that it's a bad security model.  They're 
actually doing it because its a better security model (ITheirHO).

I just didn't want people thinking that I thought FreeS/WAN used a bad 
security model.  :)

-Mark

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 05 Jun 2001 10:52:09 -0700

Mark Smith wrote:

>                    .........                             Do I
> mathimatical advancements in history. 

Until I read this, I never thought that the strength of typical
cryptographic algorithms was dependent on the NP-completeness
problem.  Can you say more about the relationship of the two?

Regards,
Charlie P.

---

From: Mark Smith <[email-masked]>
Date: Tue, 05 Jun 2001 11:27:52 -0700

This is where I really need my reference books to confirm I'm not 
talking out of my rear-end.  Unfortunatly, I don't have them handy, so 
if this smells a bit funny, you know why.  :)

It was pointed out to me that factoring (RSA) is not related directly to 
the NP-Complete problem set.  However, it has not been proven to be NOT 
as difficult as the NP-Complete problem yet, so for the time being, its 
as good.

I guess it would be more correct to say that factoring is thought to be 
as difficult as the NP-Complete problem, which is different than saying 
that solving the NP-Complete problem would solve the Factoring problem, 
thus breaking RSA.

So, my statement was incorrect.  Even if the NSA had solved the 
NP-Complete problem, that still wouldn't necessarily break RSA.

Although, solving the factoring problem would still be pretty darn tough 
to keep a cover on.

As an aside, I'm talking about public key crypto-systems when talking 
about order of difficulty, and specifically RSA when talking about 
factoring.  Things like DES are a totally different design and are 
broken differently.

-Mark

ps:  If anyone has any other questions about this, I'd be happy to 
discuss it, but lets take it off the list.  I only posted this here to 
correct my earlier statements.  -mts

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Jun 2001 16:52:54 -0700 (PDT)

> And as you have identified, there is no one who has the authority to

And we might get hit by an asteriod in 15 minutes
too. We are only talking about protocol
requirements. There is no reason for the protocol
or its requirements to specify how an operator can
cut corners. There is a requirement that the
protocol must meet the security requirements of
authentication, authorization, privacy, DoS
resilience, etc, etc, and that those mechanisms
MUST be implemented. What goes on beyond that is
completely out of scope of IETF.

	       Mike