Re: Security scenarios and basic functions
Rex Buddenberg <[email protected]>
| Newsgroups | gmane.ietf.rmt |
|---|---|
| Message-ID | <[email protected]> |
> 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