Re: [cryptography] preventing protocol failings

2011-07-22 Thread Zooko O'Whielacronx
On Tue, Jul 12, 2011 at 5:25 PM, Marsh Ray ma...@extendedsubset.com wrote: Everyone here knows about the inherent security-functionality tradeoff. I think it's such a law of nature that any control must present at least some cost to the legitimate user in order to provide any effective

Re: [cryptography] preventing protocol failings

2011-07-22 Thread James A. Donald
On 2011-07-23 7:29 AM, Marsh Ray wrote: What does the user see when they *are* under attack and the server authentication step fails? Then his task fails. How do the security properties change when the user clicks on a link in a phishing email? A phishing email is normally phishing for

Re: [cryptography] preventing protocol failings

2011-07-22 Thread James A. Donald
On 2011-07-23 7:29 AM, Marsh Ray wrote: How do the security properties change when the user clicks on a link in a phishing email? On 2011-07-23 2:06 PM, James A. Donald wrote: when someone contacts me on skype, they can never successfully pretend to be one of my existing contacts. Why

Re: [cryptography] preventing protocol failings

2011-07-13 Thread Ian G
On 13/07/11 9:25 AM, Marsh Ray wrote: On 07/12/2011 04:24 PM, Zooko O'Whielacronx wrote: On Tue, Jul 12, 2011 at 11:10 AM, Hill, Bradbh...@paypal-inc.com wrote: I have found that when H3 meets deployment and use, the reality too often becomes: Something's gotta give. We haven't yet found a

Re: [cryptography] preventing protocol failings

2011-07-13 Thread Ian G
On 13/07/11 3:10 AM, Hill, Brad wrote: Re: H3, There is one mode and it is secure I have found that when H3 meets deployment and use, the reality too often becomes: Something's gotta give. We haven't yet found a way to hide enough of the complexity of security to make it free, and this

Re: [cryptography] preventing protocol failings

2011-07-13 Thread Hill, Brad
I know it sounds good, but has it ever worked? Has any vendor ever been successfully attacked through a weak demo system, and then rolled out a new one *which happened to be prepared in time for this eventuality* ? Not a shining example of secure protocol design, but here's one example:

Re: [cryptography] preventing protocol failings

2011-07-13 Thread Marsh Ray
On 07/13/2011 01:01 AM, Ian G wrote: On 13/07/11 9:25 AM, Marsh Ray wrote: But the entire purpose of securing a system is to deny access to the protected resource. And that's why it doesn't work; we end up denying access to the protected resource. Denying to the attacker - good. Denying

Re: [cryptography] preventing protocol failings

2011-07-13 Thread Peter Gutmann
Ralph Holz h...@net.in.tum.de writes: The question, after all, is how often do you really read the SSH warnings? How often do you just type on or retry or press accept? What if you're the admin who encounters this maybe 2-3 times day? The August (I think) issue of ;login, the Usenix magazine (

Re: [cryptography] preventing protocol failings

2011-07-13 Thread Peter Gutmann
Andy Steingruebl a...@steingruebl.com writes: The way it for for everyone I knew that went through it was: 1. Sniffing was sort of a problem, but most people didn't care 2. Telnet was quite a bit of a pain, especially when using NAT, and wanting to do X11 forwarding 3. Typing in your password

Re: [cryptography] preventing protocol failings

2011-07-13 Thread James A. Donald
On 2011-07-13 8:43 PM, d...@geer.org wrote: I'll certainly agree that security cannot be made free, on the obvious grounds that security's costs are decision making under uncertainty plus enforcement of those decisions. Skype is an excellent example of free security. Skype has not one click

Re: [cryptography] preventing protocol failings

2011-07-13 Thread Peter Gutmann
Andy Steingruebl a...@steingruebl.com writes: Hmm, do you know that many sysadmins outside high-security conscious areas that really cared about typing the root password over telnet, especially back in 1997? I don't. Academia and banks cared, and often deployed things like securid or OPIE/SKEY

Re: [cryptography] preventing protocol failings

2011-07-13 Thread Andy Steingruebl
On Wed, Jul 13, 2011 at 8:40 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Maybe we travel in different circles, but both in sysadmin circles and in instances where it's come up in the past on security lists as an example of a successful security protocol, it reason for success has always

Re: [cryptography] preventing protocol failings

2011-07-13 Thread Kevin W. Wall
On Wed, Jul 13, 2011 at 11:39 AM, Andy Steingruebl a...@steingruebl.com wrote: On Wed, Jul 13, 2011 at 7:11 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Andy Steingruebl a...@steingruebl.com writes: The way it for for everyone I knew that went through it was: 1. Sniffing was sort of a

Re: [cryptography] preventing protocol failings

2011-07-12 Thread Hill, Brad
Re: H3, There is one mode and it is secure I have found that when H3 meets deployment and use, the reality too often becomes: Something's gotta give. We haven't yet found a way to hide enough of the complexity of security to make it free, and this inevitably causes conflicts with goals like

Re: [cryptography] preventing protocol failings

2011-07-12 Thread Nico Williams
On Tue, Jul 12, 2011 at 12:10 PM, Hill, Brad bh...@paypal-inc.com wrote: Re: H3, There is one mode and it is secure I have found that when H3 meets deployment and use, the reality too often becomes: Something's gotta give.  We haven't yet found a way to hide enough of the complexity of

Re: [cryptography] preventing protocol failings

2011-07-12 Thread Andy Steingruebl
On Tue, Jul 12, 2011 at 2:24 PM, Zooko O'Whielacronx zo...@zooko.com wrote: When systems come with good usability properties in the key management (SSH, and I modestly suggest ZRTP and Tahoe-LAFS) then we don't see this pattern. People are willing to use secure tools that have a good usable

Re: [cryptography] preventing protocol failings

2011-07-12 Thread Nico Williams
On Tue, Jul 12, 2011 at 5:36 PM, Andy Steingruebl a...@steingruebl.com wrote: I reject the SSH key management example though.  Especially if you've ever maintained a large number/variety of unix servers running SSH, where hardware failures, machine upgrades, etc. lead to frequent SSH key

Re: [cryptography] preventing protocol failings

2011-07-12 Thread Ian G
On 13/07/11 8:36 AM, Andy Steingruebl wrote: On Tue, Jul 12, 2011 at 2:24 PM, Zooko O'Whielacronxzo...@zooko.com wrote: When systems come with good usability properties in the key management (SSH, and I modestly suggest ZRTP and Tahoe-LAFS) then we don't see this pattern. People are willing

Re: [cryptography] preventing protocol failings

2011-07-12 Thread Andy Steingruebl
On Tue, Jul 12, 2011 at 3:56 PM, Ian G i...@iang.org wrote: The SSH-vs-telnet example was back in the mid-90s where there were two alternatives:  secure telnet and this new-fangled thing called SSH. The way it for for everyone I knew that went through it was: 1. Sniffing was sort of a

Re: [cryptography] preventing protocol failings

2011-07-12 Thread Marsh Ray
On 07/12/2011 04:24 PM, Zooko O'Whielacronx wrote: On Tue, Jul 12, 2011 at 11:10 AM, Hill, Bradbh...@paypal-inc.com wrote: I have found that when H3 meets deployment and use, the reality too often becomes: Something's gotta give. We haven't yet found a way to hide enough of the complexity of

Re: [cryptography] preventing protocol failings

2011-07-12 Thread James A. Donald
On 2011-07-13 7:24 AM, Zooko O'Whielacronx wrote: On Tue, Jul 12, 2011 at 11:10 AM, Hill, Bradbh...@paypal-inc.com wrote: I have found that when H3 meets deployment and use, the reality too often becomes: Something's gotta give. We haven't yet found a way to hide enough of the complexity

Re: [cryptography] preventing protocol failings

2011-07-12 Thread James A. Donald
On 2011-07-13 3:10 AM, Hill, Brad wrote: Recognize in advance that users will demand an insecure mode and give it to them. I don't see any demand for an insecure mode for tor hidden services, and though SSH provides an insecure mode, no one uses it. If users demand an insecure mode,

Re: [cryptography] preventing protocol failings

2011-07-12 Thread James A. Donald
On 2011-07-13 8:36 AM, Andy Steingruebl wrote: I reject the SSH key management example though. Especially if you've ever maintained a large number/variety of unix servers running SSH, where hardware failures, machine upgrades, etc. lead to frequent SSH key churn. In those cases the only

Re: [cryptography] preventing protocol failings

2011-07-12 Thread Hill, Brad
If users demand an insecure mode, it is because your secure mode has bad user interface. I'm actually thinking about things like web services where the user isn't someone sitting in front of a UI, but a programmer, or a team of programmers, testers, and operational personnel.It's easy to

Re: [cryptography] preventing protocol failings

2011-07-09 Thread Peter Gutmann
Zooko O'Whielacronx zo...@zooko.com writes: Hm, digging around in my keepsakes cabinet, I unfortunately do not find the original state transition diagram that I mentioned above, but I do find an artifact that I wrote a few months later=E2=80=94a sketch of a protocol that I called ZRTP lite which

Re: [cryptography] preventing protocol failings

2011-07-07 Thread Peter Gutmann
Sampo Syreeni de...@iki.fi writes: To my mind the difference seemed to be about shallow versus deep parsing. You can't really deep parse anything in BER with implicit tagging, You can deep-parse, you just need to apply some basic heuristics (e.g. if it's an octet string and the first byte is

Re: [cryptography] preventing protocol failings

2011-07-06 Thread Peter Gutmann
Nico Williams n...@cryptonector.com writes: On Wed, Jul 6, 2011 at 12:06 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: (The ASN.1 filter I mentioned earlier is a stripped-down version of dumpasn1. Remember that dataset of 400K broken certs that NISCC generated a few years ago and that

Re: [cryptography] preventing protocol failings

2011-07-06 Thread Peter Gutmann
I wrote: BER and DER are actually the safest encodings of the major security protocols I work with. Based on the following, which just appeared on another list: In contrast to RFC 5280, X.509 does not require DER encoding. It only requires that the signature is generated across a DER

Re: [cryptography] preventing protocol failings

2011-07-06 Thread Jeffrey Walton
On Wed, Jul 6, 2011 at 7:07 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: I wrote: BER and DER are actually the safest encodings of the major security protocols I work with. Based on the following, which just appeared on another list:  In contrast to RFC 5280,  X.509 does not require

Re: [cryptography] preventing protocol failings

2011-07-06 Thread Sampo Syreeni
On 2011-07-04, Jon Callas wrote: Let me be blunt here. The state of software security is so immature that worrying about crypto security or protocol security is like debating the options between hardened steel and titanium, when the thing holding the chain of links to the actual user

Re: [cryptography] preventing protocol failings

2011-07-05 Thread Jon Callas
On Jul 4, 2011, at 10:10 PM, coderman wrote: H3 should be Gospel: There is Only One Mode and it is Secure anything else is a failure waiting to happen… Yeah, sure. I agree completely. How could any sane person not agree? We could rephrase this as, The Nineties Called, and They Want Their

Re: [cryptography] preventing protocol failings

2011-07-05 Thread Peter Gutmann
coderman coder...@gmail.com writes: H3 should be Gospel: There is Only One Mode and it is Secure Also known as Grigg's Law. The corollary, for protocols where there *are* options, is There is one one cipher suite and that is Suite #1. Peter. ___

Re: [cryptography] preventing protocol failings

2011-07-05 Thread coderman
On Mon, Jul 4, 2011 at 11:31 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: ... The corollary, for protocols where there *are* options, is There is one one cipher suite and that is Suite #1. hey, removing all other options can be an option. uh oh, i just contradicted myself...

Re: [cryptography] preventing protocol failings

2011-07-05 Thread coderman
On Mon, Jul 4, 2011 at 11:11 PM, Jon Callas j...@callas.org wrote: ... Yeah, sure. I agree completely. no you don't ;) How can I use this principle as a touchstone to let me know the right thing to do. I suppose we could consider it a rule of thumb instead, but that flies in the face of

Re: [cryptography] preventing protocol failings

2011-07-05 Thread Jon Callas
On Jul 4, 2011, at 11:35 PM, coderman wrote: On Mon, Jul 4, 2011 at 11:11 PM, Jon Callas j...@callas.org wrote: ... Yeah, sure. I agree completely. no you don't ;) Actually I do. I also believe in truth and justice and beauty, too. And simplicity. I just value actionable, as well.

Re: [cryptography] preventing protocol failings

2011-07-05 Thread Peter Gutmann
Nico Williams n...@cryptonector.com writes: Why even have a tag?? The ASN.1 Packed Encoding Rules (think ONC XDR with 1- byte alignment instead of 4-byte alignment) doesn't use tags at all. Which makes them impossible to statically check, and leads to hellishly complex decoders. In

Re: [cryptography] preventing protocol failings

2011-07-05 Thread Steven Bellovin
there may be a pragmatic need for options dealing with existing systems or business requirements, however i have yet to hear a convincing argument for why options are necessary in any new system where you're able to apply lessons learned from past mistakes. You said it yourself: different

Re: [cryptography] preventing protocol failings

2011-07-05 Thread Arshad Noor
On 07/05/2011 09:09 AM, Steven Bellovin wrote: More importantly (and to pick a less extreme scenario), security isn't an absolute, it's a matter of economics. If the resource you're protecting isn't worth much, why should you spend a lot? And, one does not need to guess at how much a lot is;

Re: [cryptography] preventing protocol failings

2011-07-05 Thread Ian G
On 5/07/11 3:59 PM, Jon Callas wrote: There are plenty of people who agree with you that options are bad. I'm not one of them. Yeah, yeah, sure, it's always easy to make too many options. But just because you can have too many options that doesn't mean that zero is the right answer. That's

Re: [cryptography] preventing protocol failings

2011-07-05 Thread Peter Gutmann
Nico Williams n...@cryptonector.com writes: In other words, in ASN.1 as it's used you have to know the schema and message type in order to do a good job of parsing the message, No you don't. I give as a counterexample dumpasn1, which knows nothing about message types or schemas, but parses

[cryptography] preventing protocol failings

2011-07-04 Thread Sampo Syreeni
(I'm not sure whether I should write anything anytime soon, because of Len Sassaman's untimely demise. He was an idol of sorts to me, as a guy who Got Things Done, while being of comparable age to me. But perhaps it's equally valid to carry on the ideas, as a sort of a nerd eulogy?)

Re: [cryptography] preventing protocol failings

2011-07-04 Thread Steven Bellovin
On Jul 4, 2011, at 7:28 10PM, Sampo Syreeni wrote: (I'm not sure whether I should write anything anytime soon, because of Len Sassaman's untimely demise. He was an idol of sorts to me, as a guy who Got Things Done, while being of comparable age to me. But perhaps it's equally valid to

Re: [cryptography] preventing protocol failings

2011-07-04 Thread Nico Williams
On Mon, Jul 4, 2011 at 6:28 PM, Sampo Syreeni de...@iki.fi wrote: Personally I've slowly come to believe that options within crypto protocols are a *very* bad idea. Overall. I mean, it seems that pretty much all of the effective, real-life security breaches over the past decade have come from

Re: [cryptography] preventing protocol failings

2011-07-04 Thread Jon Callas
On Jul 4, 2011, at 4:28 PM, Sampo Syreeni wrote: (I'm not sure whether I should write anything anytime soon, because of Len Sassaman's untimely demise. He was an idol of sorts to me, as a guy who Got Things Done, while being of comparable age to me. But perhaps it's equally valid to carry