Thanks for the response. >> 2. It's certainly an option to add it. Maybe in the improved error >dialog we show, much like accepting self signed certificates. > >An improved error dialog - yes please, absolutely. An option to disable >that enforcement - probably yes (of course keeping it enabled by >default). Punishing normal users and forcing them to use other less >convenient clients (such as Gmail app from Google) because the >developer doesn’t like big vendor’s boneheaded server configuration >does not seem right to me. Yes, in this particular case the “vendor >argument” does not apply. But unfortunately it applies in most every >other case.
The problem with dialogs in all cases, for example for SSLv3 is that downgrade attacks are perfectly practical. If an attacker intercepts the requests and claims not to support the secure protocols so the user downgrades their connection to insecure protocols which can be broken. This is that security = availability thing :) I don't want to enable that possibility to fix one or two users issues. > >> 3. To an extent but I do think you blow off the perception issue too >easily. Positive appearance of security prevents people fixing it - >being forced to pick 'unencrypted' tells you something. > >Yes - it tells me that the developer of the software in question >probably is a fanatic. <half-smile only - in reality it is not funny> > >It’s not good when the developer believes that the only acceptable >solutions are iron gates, or empty doorways (to make sure the home >owner understands that a large gaping hole in the wall ain’t an iron >gate). Because those flimsy doors with toy locks that any serious >attacker can force open, don’t serve any purpose in his (developer’s) >view. > Look, today's DEFCON speech by Moxie is tommorow's weaponised Metasploit module and Monday's tool for controlling partners to monitor their spouse. This is how it works. If SSLv3 hadn't been outlawed by every browser and every server it would be part of this sort of thing by now. >> I want to support secure software in a way that encourages people >getting their providers to provide secure systems. So I want it to be >easy to be secure and a conscious choice to be insecure. > >First, there is no “secure” or “insecure” - only “secure (or insecure) >against what”. What are the assumptions? Secure against a casual >eavesdropper? Against a hacker (with what capabilities)? Against an >organized crime effort? Against BND? What’s the value of the protected >information vs. the expenses required to extract it? Which is why where necessary I'd like to see us use messages like Google do to indicate nation state attacks. As a developer I don't know the value of the email people write. Given until we started the work PGP/MIME was our most requested feature and S/MIME is fairly high on the list and we're mentioned these days as a recommended client by the Debian user list but not the Guardian I tend to think our audience has a technical focus. Given its still inordinately difficult to report bugs and yet we have hundreds of the things I reckon we're not currently aimed at mass market. That's not to say we shouldn't be trying to get there but for now I assume our audience is pretty security conscious. > >Since most of the email is provided free by giants such as Google, >Microsoft, Apple, Comcast, Verizon, etc. - I find the notion (in >general) that people can “get their providers to provide secure >systems” simply ridiculous, to put it mildly. In my experience (and >I’ve only been active in this field for 25 years) getting “provider” to >“provide” something that, e.g., would be more secure is 100% hopeless. >I remember my own dialogs several years ago with my broadband provider >about enabling SSL on their email server (it was plain http). To keep >this story short and civil - they refused to do so. Those giants deploy >security mechanisms they think would serve their purposes, which may or >may not be aligned with yours (or mine). If you think they would listen >to your demands and adjust accordingly - without being insulting, my >experience proves different. Which is why we actively support as many large providers as possible. There's an open issue to support XOAuth 2.0 which is only used by Gmail to improve user experience. It's also why I framed my response as I did. If he was on a random ISP email system I'd have not bothered trying to get him to persuade them to fix it. I'd have made the point it was less secure and then just said we'll fix it. This LogJam issue isn't an issue with any major provider. To my knowledge it's only been found by people on self hosting (I know of one or two other cases having searched for the error). That's s why the bar for doing something is at this place. > >> I'm aiming for a certain level of inconvenience to help the user >basically. > >If software implementation prevents the user from connecting to the >email server he uses, how does it help him? In your world perhaps that >user can call the owner of that server (for example, Google) and say >“your server does not allow the kind of security my software wants - so >fix it or I’m taking my free email elsewhere”. In my world that >approach didn’t seem to work. Which is why I plan to fix this specific case. Unable to use the system isn't okay, making them check a few boxes seems about right. >> Broken crypto becomes no crypto once any attacker can trivially >examine it with a tool widely available. It's not standard user level >to view unencrypted traffic anyway - you have to sniff WiFi data or put >yourself in the server path. So once it's as easy to decrypt as to >intercept it really is the same thing. > >First, it is not as easy to decrypt (even SSLv3, which we all agree is >hopelessly broken and shouldn’t be used unless the only other >alternative is plaintext) as it is to sniff. Second, it is not only >WiFi - it’s broadband (in some cases at least), aided by misconfigured >providers (again, try to convince providers to fix their stuff - and >let me know when you get frustrated enough to see my point). Third, in >any case, forcing the adversary to do more work is better than not to, >especially if that doesn’t cost you anything. > I covered this above with regard to availability of tooling vs deployment of weaker software. >> In this specific case he is his own provider so I felt it was worth >making the point. > >In this specific case you’re 100% correct. > >The problem I see is that people are trying to make this point >“globally”, and usually it is not applicable. Not many of us are our >own providers. Which is fortunate really because major providers are actually doing fairly well here. >-- >Mobile Mouse [email protected] Best regards, Philip Whitehouse -- -- You received this message because you are subscribed to the K-9 Mail Users List. To post to this group, send email to [email protected] To unsubscribe, email [email protected] To report an issue with K-9 Mail, visit http://code.google.com/p/k9mail/issues/list For more options, visit this group at http://groups.google.com/group/k-9-mail --- You received this message because you are subscribed to the Google Groups "K-9 Mail" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
pgpdu8LfLnnLt.pgp
Description: PGP signature
