Re: Security scenarios and basic functions

Hi Rex,

I can well appreciate your advocating end-to-end security at the highest
layer possible, especially for the high assurance applications that your
organization likely has in operation.

OTOH, I think you've exposed one of the dilemmas facing the IETF security
community. There have been numerous security protocols developed in the
IETF, but arguely only TLS is widely used and could be labeled successful.
SMIME, which you cited as an example of good end to end security, has
failed to acquire a significant widescale market acceptance.  Training the
end user populace and cost of operating a PKI being among the reasons it
is not used. The IPsec-based VPNs are widely deployed but as you have
pointed out, they are operated by the technical "insiders".  That said, it
still comes down to local security policy to say what is "good enough".

Awhile back I attended the SAG meeting at the San Diego IETF. There was
alot of discussion about how almost all of the IETF security protocols
fail the infamous "grandmother test". The conclusion at that SAG was that
security usually isn't transparent to the end user or at least it isn't
*very easy* to use except by experts. So security does not generally get
used. TLS passed the grandmother test. SMIME and IPsec don't.

Given the above, I could endorse an effort to standardize a "RMTLS" only
if we were confident that it could pass the grandmother test. Also, the
combined RMT and MSEC community has to get energized enough to invest the
3 years effort (the typical time it takes to get an RFC) to develop
transport layer security for the RMT protocols. I happen to think we're
closer than 3 years effort for an MSEC IPsec-based solution.

It would be valuable to get the RMT consensus one way or the other on this
question: IPsec at network layer or RMT transport layer security?

br,
	George


 On Fri, 30 Jun 2006, Rex Buddenberg wrote:

> > I also wonder if there has been any analysis work done from
> performance perspective for layer 3 solution v.s. layer 4/7 solutions.
>
> The 'analysis' I do when I teach the class is to sketch box/wires
> solutions on the board and then have the students count the insiders.
> While reminding them that 'insider' is the first word in the term
> 'insider attack'.  (I replay the Walker case in the process of this
> analysis).
>
> One of the other case studies to analyze is the 'credit card loss'
> scenario.  And it doesn't seem to matter which specific one you choose.
> None of them seem to trace back to SSL breakage; a good share of them
> trace to unauthorized access to the database or outright theft of the
> drive.  Where the data is stored as plaintext.  SSL is end to end _only_
> in the network, not the total information system.  (S/MIME
> implementations, btw, are true end-to-end -- an encrypted body part will
> be stored on the recipients hard drive in the same form that it was
> transmitted.  You can check your UA by sending yourself encrypted
> e-mail, storing it, and then retrieving it -- the UA should ask for your
> private key again).
>
>
> There are two easily discerned trends here:
> 	- the lower in the ISO model that you attack a security problem the
> poorer your interoperability quotient will be.
> 	- the higher in the model that you attack a security problem the fewer
> the number of non-essential insiders there are.
>
> On Fri, 2006-06-30 at 16:38 -0400, Baoqing Ye wrote:
> > my 2 cents:
> >
> > On 6/30/06, Rex Buddenberg <[email protected]> wrote:
> >         On Fri, 2006-06-30 at 07:11 -0400, George Gross wrote:
> >         > > 3. Confidentiality, i.e. the possibility to prevent
> >         someone not
> >         > > authorized to see what is transported within the protocol,
> >         and in some
> >         > > case even seeing what is happening within the protocol
> >         itself.
> >         >
> >
> > -- I'd suggest to leave confidentiality as optional, or at least to be
> > really careful about the algorithms to be proposed, considering the
> > overhead the encryption of all payload it brings to the picture which
> > will inevitably reduce overall performance (significantly).
> >
> >         IPsec is not a complete solution.  It applies to layer 3 which
> >         means you
> >         are protecting infrastructure ... only indirectly protecting
> >         the data.
> >         The practical implication is that you have technician-based
> >         insiders in
> >         the enclaves.  (I've no objection whatever to reusing IPsec
> >         building
> >         blocks at layers 4 and 7).
> >
> > -- I agree with the statement above. I also wonder if there has
> > been any analysis work done from performance perspective for layer 3
> > solution v.s. layer 4/7 solutions.
> >
> > -Baoqing Ye-
> > Verizon Lab, LAOMS59, 40 Sylvan Road, Waltham, MA 02451, USA
>