Re: User interface, security, and "simplicity"

[Peter Gutmann]

"James A. Donald" <[EMAIL PROTECTED]> writes:

>In any program subject to attack, all strings should have known, documented,
>and enforced maximum length, a length large enough for all likely legitimate
>uses, and no larger.

Precisely.  An example of where dynamic strings can lead you is what happens
to old (very old) versions of Netscape when you feed them a cert with, say, an
MPEG of a cat in the X.500 DN.  Netscape happily accepts the cert but you then
have to reinstall the browser because while it'll quite readily accept
ridiculously long values it doesn't actually cope with them very well.  A
security component that's trivially taken out by a DoS isn't a security
component, it's a vulnerability.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Victor Duchovni]

On Wed, May 07, 2008 at 10:27:48AM +1000, James A. Donald wrote:

> Dynamic strings tempt people to forget about enforcing
> length limits and forget about correctly handling the
> case when the length limits are exceeded.

This too is dealt with. Message sizes are bounded, recipient counts
are bounded, duplicate elimination cache sizes are bounded, command
lengths are bounded, logical header lengths are bounded, body content
is processed 2K bytes at a time...

The requirement is stronger than just not running a single process out of
memory, the entire multi-process Postfix is designed to run in (realistic)
bounded memory (no "fork: out of memory").

-- 

 /"\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[James A. Donald]

> > The same is true in the source code, unsafe
> > practices are avoided globally, (e.g. both strcpy()
> > and strncpy() are absent together with fixed size
> > automatic buffers) rather than used with care
> > locally. I won't bore you with all the
> > implementation safety "habits", but there are many.

David Wagner wrote:
> It's too bad that today such elementary practices are
> something to brag about.  Perhaps one day we'll be
> lucky enough that the answer to these questions
> becomes more like "of course we use safe programming
> practices; what kind of incompetent amateurs do you
> take us for?".

Dynamic strings tempt people to forget about enforcing
length limits and forget about correctly handling the
case when the length limits are exceeded.

There is no such thing as a string with no maximum
length, merely strings of UNKNOWN maximum length.  If
one has dynamic buffers and fully dynamic strings, it is
always possible for an attacker to discover the
previously UNKNOWN maximum length, and exceed it,
causing the program to fail in a manner likely to be
useful to the attacker.

In any program subject to attack, all strings should
have known, documented, and enforced maximum length, a
length large enough for all likely legitimate uses, and
no larger.

If enforcing length limits, it is frequently advisable,
and often necessary, to use, not strcpy or strncpy, but
routines such as _mbscpy_s, string manipulation routines
which can, and frequently do, employ buffers of fixed
and known length, sometimes pre-allocated fixed length.

In C++, incomprehensibly obscure functions such as
_mbscpy_s should never be called directly, but rather
called through a template library that automatically
does the sensible thing when the destination parameter
is a fixed length buffer, and can be relied upon to
object when commanded to do the stupid thing.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Ian G]

David Wagner wrote:

...

This struck me as poor design, not good design.  Asking the user to
make these kinds of choices seems like the kind of thing that only a
cryptographer could consider sensible.  In this day and age, software
should not be asking users to choose ciphers.  Rather, the software
should just pick a sensible high-grade security level (e.g., AES-128,
RSA-1024 or RSA-2048) and go with that, and avoid bothering the user.
Why even offer "low" as an option?  (And this "export" business sounds
like a throwback to a decade ago; why is that still there?)

Good crypto is cheap.  Asking a user is expensive and risky.


So I think there should be a broad design bias towards *implicit* correct
behaviour in all system features, with rope available for advanced users
to *explicitly* craft more complex use-cases. Once you have that, practical
security is not too difficult.


Amen.  I know of quite a few software packages that could use more of
that philosophy.



I think we are all coming around to the view that any 
choices are practically messy and dangerous, no matter how 
nice they look on paper.


The way I put it, there is only one mode, and it is secure. 
 From there on, it only gets better.  Obligatory rant:


http://iang.org/ssl/h3_there_is_only_one_mode_and_it_is_secure.html

iang

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Victor Duchovni]

On Tue, May 06, 2008 at 11:40:53AM -0700, David Wagner wrote:

> >- With the upcoming EECDH support, users don't choose curves
> >directly, they again choose a security grade, and the correspnding
> >curves are configurable via parameters they are not expected to
> >ever look at or modify.
> 
> This struck me as poor design, not good design.  Asking the user to
> make these kinds of choices seems like the kind of thing that only a
> cryptographer could consider sensible.

They are not *asked* to make any cipher choices. The are able to make:

- no explicit choice, and get sensible default behaviour

- a high level choice ("secure verification" + "high grade cipher"
without having to spell out the gory details of what these mean.

- an exteremely detailed specification of all the details.

> In this day and age, software
> should not be asking users to choose ciphers.

The users in question are email administrators, not end users, and you
missed my point. They are not asked to choose ciphers, these are chosen
for them, and the default choice is even context dependent, so you get
sensible combinations of security properties:

- Opportunistic TLS allows SSLv2 and export ciphers

- Mandatory TLS, enforces SSLv3/TLSv1 and medium or high
ciphers.


> Rather, the software
> should just pick a sensible high-grade security level (e.g., AES-128,
> RSA-1024 or RSA-2048) and go with that

This is what is done (using OpenSSL's "HIGH", "MEDIUM", ... selectors).

> and avoid bothering the user.
> Why even offer "low" as an option?  (And this "export" business sounds
> like a throwback to a decade ago; why is that still there?)

You don't know how TLS is used with SMTP. Most TLS is opportunistic and
plain text is used if TLS is absent. In such an environment insisting
on 128 bits is silly, even 40 bits is better than plain-text.

> Good crypto is cheap.  Asking a user is expensive and risky.

Breaking interoperability by limiting cipher selection and causing mail
to queue is not cheap.

> >So I think there should be a broad design bias towards *implicit* correct
> >behaviour in all system features, with rope available for advanced users
> >to *explicitly* craft more complex use-cases. Once you have that, practical
> >security is not too difficult.
> 
> Amen.  I know of quite a few software packages that could use more of
> that philosophy.
> 
> >The same is true in the source code, unsafe practices are avoided
> >globally, (e.g. both strcpy() and strncpy() are absent together with fixed
> >size automatic buffers) rather than used with care locally. I won't bore
> >you with all the implementation safety "habits", but there are many.
> 
> It's too bad that today such elementary practices are something to brag
> about.  Perhaps one day we'll be lucky enough that the answer to these
> questions becomes more like "of course we use safe programming practices;
> what kind of incompetent amateurs do you take us for?".

Practices are "culture" not "technology", and it is difficult to displace
existing cultures with new ones :-(

-- 
Viktor.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Nicolas Williams]

On Tue, May 06, 2008 at 03:40:46PM +, Steven M. Bellovin wrote:
> Experiment part two: implement remote login (or remote IMAP, or remote
> Web with per-user privileges, etc.) under similar conditions.  Recall
> that being able to do this was a goal of the IPsec working group.
> 
> I think that part one is doable, though possibly the existing APIs are
> incomplete.  I don't think that part two is doable, and certainly not
> with high assurance.  In particular, with TLS the session key can be
> negotiated between two user contexts; with IPsec/IKE, it's negotiated
> between a user and a system.  (Yes, I'm oversimplifying here.)

"Connection latching" and "connection-oriented" IPsec APIs can address
this problem.

Solaris, and at least one other IPsec implementation (OpenSwan?  I
forget) makes sure that all packets for any one TCP connection (or UDP
"connection") are protected (or bypassed) the same way during their
lifetime.  "The same way" -> by similar SAs, that is, SAs with the same
algorithms, same peers, and various other parameters.

A WGLC is about to start in the IETF BTNS WG on an I-D that describes
this.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Jack Lloyd]

On Tue, May 06, 2008 at 03:40:46PM +, Steven M. Bellovin wrote:

> In particular, with TLS the session key can be negotiated between
> two user contexts; with IPsec/IKE, it's negotiated between a user
> and a system.  (Yes, I'm oversimplifying here.)

Is there any reason (in principle) that IPsec/IKE could not be done
entirely in userspace / application space, though?

-Jack

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Steven M. Bellovin]

On Sat, 03 May 2008 19:50:01 -0400
"Perry E. Metzger" <[EMAIL PROTECTED]> wrote:
 
> Almost exclusively the use for such things is nailing up a tunnel to
> bring someone inside a private network. For that, there is no need for
> per user auth -- the general assumption is that the remote box is a
> single user laptop or something similar anyway. You really just want
> to verify that the remote host has a particular private key, and if it
> does, you nail up a tunnel to it (possibly allocating it a local IP
> address in the process). That solves about 95% of the usage scenarios
> and it requires very little configuration. It also covers virtually
> all use of IPSec I see in the field.
> 
> Again, there are more complex usage scenarios, and it may be more
> complicated to set one of *those* up, but it is a shame that it is
> difficult to do the simple stuff.
> 
So here's an interesting experiment.  Part one: Take a common IPsec
implementation -- Linux, *BSD, Windows, what have you.  Assume this
common scenario: laptop connecting to a corporate server.  Assume a
user authentication credential.  (I'd prefer that that be a public/
private key pair, for many reasons, not the least of which is the bug
in IKEv1 with main mode and shared secrets.)  Do not assume a 1:1 ratio
between laptops and internal IP address, because such servers are
frequently underprovisioned.  Challenge: design -- and implement -- a
*simple* mechanism by which the client user can set up the VPN
connection, both on the client and on the server.  This part can
happen while the client is physically on the corporate net.  Variant A:
the VPN server is a similar box to which the client has login-grade
access. Variant B: the VPN server is something like a restricted-access
Cisco box, in which case a trusted proxy is probably needed.  User
setup should be something like 'configvpn cs.columbia.edu', where I
supply my username and authenticator.  User connection should be
'startvpn cs.columbia.edu' (or, of course, the GUI equivalent); all I
supply is some sort of authenticator.  Administrator setup should be a
list of authorized users, and probably an IP address range to use
(though having the VPN server look like a DHCP relay would be cool).

Experiment part two: implement remote login (or remote IMAP, or remote
Web with per-user privileges, etc.) under similar conditions.  Recall
that being able to do this was a goal of the IPsec working group.

I think that part one is doable, though possibly the existing APIs are
incomplete.  I don't think that part two is doable, and certainly not
with high assurance.  In particular, with TLS the session key can be
negotiated between two user contexts; with IPsec/IKE, it's negotiated
between a user and a system.  (Yes, I'm oversimplifying here.)

--Steve Bellovin, http://www.cs.columbia.edu/~smb

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Steven M. Bellovin]

On Sun, 04 May 2008 11:22:51 +0100
Ben Laurie <[EMAIL PROTECTED]> wrote:

> Steven M. Bellovin wrote:
> > On Sat, 03 May 2008 17:00:48 -0400
> > "Perry E. Metzger" <[EMAIL PROTECTED]> wrote:
> > 
> >> [EMAIL PROTECTED] (Peter Gutmann) writes:
>  I am left with the strong suspicion that SSL VPNs are "easier to
>  configure and use" because a large percentage of their user
>  population simply is not very sensitive to how much security is
>  actually provided.
> >>> They're "easier to configure and use" because most users don't
> >>> want to have to rebuild their entire world around PKI just to set
> >>> up a tunnel from A to B.
> >> I'm one of those people who uses OpenVPN instead of IPSEC, and I'm
> >> one of the people who helped create IPSEC.
> >>
> >> Right now, to use SSH to remotely connect to a machine using public
> >> keys, all I have to do is type "ssh-keygen" and copy the locally
> >> generated public key to a remote machine's authorized keys file.
> >> When there is an IPSEC system that is equally easy to use I'll
> >> switch to it.
> >>
> >> Until then, OpenVPN let me get started in about five minutes, and
> >> the fact that it is less than completely secure doesn't matter
> >> much to me as I'm running SSH under it anyway.
> >>
> > There's a technical/philosophical issue lurking here.  We tried to
> > solve it in IPsec; not only do I think we didn't succeed, I'm not at
> > all clear we could or should have succeeded.
> > 
> > IPsec operates at layer 3, where there are (generally) no user
> > contexts.  This makes it difficult to bind IPsec credentials to a
> > user, which means that it inherently can't be as simple to
> > configure as ssh.
> > 
> > Put another way, when you tell an sshd whom you wish to log in as,
> > it consults that user's home directory and finds an authorized_keys
> > file. How can IPsec -- or rather, any key management daemon for
> > IPsec -- do that?  Per-user SPDs?  Is this packet for port 80 for
> > user pat or user chris?
> > 
> > I can envision ways around this (especially if we have an IP address
> > per user of a system -- I've been writing about fine-grained IP
> > address assignment for years), but they're inherently a lot more
> > complex than ssh.
> 
> I don't see why.
> 
> The ssh server determines who the packets are for from information
> sent to it by the ssh client.
> 
> The ssh client knows on whose behalf it is acting by virtue of being 
> invoked by that user (I'll admit this is a simplification of the most 
> general case, but I assert my argument is unaffected), and thus is
> able to include the information when it talks to the server.
> 
> Similarly, the client end of an IPSEC connection knows who opened the 
> connection and could, similarly, convey that information. That data
> may not be available in some OSes by the time it gets to the IPSEC
> stack, but that's a deficiency of the OS, not a fundamental problem.
> 
The problem is more on the server end.




--Steve Bellovin, http://www.cs.columbia.edu/~smb

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Victor Duchovni]

On Sun, May 04, 2008 at 10:24:13PM -0400, Thor Lancelot Simon wrote:

> I believe that those who supply security products have a responsibility
> to consider the knowledge, experience, and tendencies of their likely
> users to the greatest extent to which they're able, and supply products
> which will function properly _as users are likely to apply them_.

The TLS support in Postfix tries to behave sensibly with "easy" setings.

- Cipher list selection is indirect, via grades: "export", "low",
"medium" and "high". The actual ciphers for each grade are buried
in parameters users are advised to not mess with.

- The cipher grade for opportunistic TLS is "export", but you single
out a destination for mandatory TLS, the grade rises to "medium".

- The "secure" peer cert validation level compares the peer's cert to
the nexthop domain (allowing a sub-domain match by default). Hostnames
derived from MX lookups are of course subject to DNS MITM and are not
trusted.  If you want to trust your DNS you can use "verify" instead.

http://www.postfix.org/TLS_README.html#client_tls_limits
http://www.postfix.org/TLS_README.html#client_tls_may
http://www.postfix.org/TLS_README.html#client_tls_encrypt
http://www.postfix.org/TLS_README.html#client_tls_verify
http://www.postfix.org/TLS_README.html#client_tls_secure

- With the upcoming EECDH support, users don't choose curves
directly, they again choose a security grade, and the correspnding
curves are configurable via parameters they are not expected to
ever look at or modify.

If you don't botch your CAfile, it is rather easy to provision
secure-channel connections to a select set of high-value peers.

If you don't trust any CAs:

http://www.postfix.org/TLS_README.html#client_tls_fingerprint

once you have a system designed in all its features to behave sensibly
by default (e.g. with an empty main.cf file), making security behave
sensibly by default is not that unnatural.

So I think there should be a broad design bias towards *implicit* correct
behaviour in all system features, with rope available for advanced users
to *explicitly* craft more complex use-cases. Once you have that, practical
security is not too difficult.

The same is true in the source code, unsafe practices are avoided
globally, (e.g. both strcpy() and strncpy() are absent together with fixed
size automatic buffers) rather than used with care locally. I won't bore
you with all the implementation safety "habits", but there are many.

-- 
Viktor.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Thor Lancelot Simon]

On Mon, May 05, 2008 at 11:46:49AM +1000, James A. Donald wrote:
> Thor Lancelot Simon wrote:
> >And, in fact, most VPN software of any type fails this test.  My concern
> >is that an excessive focus on "how hard is it to set this thing up?" can
> >seriously obscure the important second half of the question "and if you
> >set it up in the easiest possible way, is it safe?"
> 
> If there is a wrong way to do it, the end user will do it wrong.

No.  Your claim sounds plausible because it's a much, much stronger form
of a claim which almost always _is_ true:  "If there is a wrong way to
do it, _some_ end users will do it wrong."

But that is not the same claim as "If there is a wrong way to do it,
_most_ end users will do it wrong", a claim which usually seems to be
made because someone who understood cryptography but not human factors
just decided that the problem he didn't know how to solve wasn't
important because he didn't know how to solve it.

The fact that that mistake (in essence, assuming "it is necessary that
most users will get it wrong" instead of "it is possible that most users
will get it wrong) is not pointed out when it is, so often, made, is,
indeed, the typical excuse for security software not bothering to supply
a good user interface such that most of the time, most users get it
right.

That in no way means that such a user interface is not desirable, any
more than low standards in the area mean that it is not possible.

I believe that those who supply security products have a responsibility
to consider the knowledge, experience, and tendencies of their likely
users to the greatest extent to which they're able, and supply products
which will function properly _as users are likely to apply them_.  I
believe that not considering those questions at all is irresponsible
and in some cases much worse than that.  Pretending that the questions
don't exist is _definitely_ worse than irresponsible; I've quit jobs
when asked to behave that way, in the past, and I'd probably do so
again.

Thor

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[James A. Donald]

Thor Lancelot Simon wrote:

And, in fact, most VPN software of any type fails this test.  My concern
is that an excessive focus on "how hard is it to set this thing up?" can
seriously obscure the important second half of the question "and if you
set it up in the easiest possible way, is it safe?"


If there is a wrong way to do it, the end user will do it wrong.  Expert 
cryptographers frequently fail to act correctly on their understanding 
of cryptography.  The end user has no chance - and the chances are still 
not all that good even if your end user is highly qualified cryptographer.


What users comprehend, and are used to, is you that set up an account 
with username and password, and an admin blesses the account with 
appropriate privileges as a result of some out of band communication - 
which username and password has to be secured, invisibly to the user, 
against offline and phishing attacks, without requiring any thought or 
vigilance by the user - see my web page for 
 for attacks on the 
password model, and defenses against those attacks.


This comes naturally to humans, for humans have long relied on 
shibboleths for security against treachery by outsiders.  Thus the 
computer interface to our clever cryptographic algorithms must resemble 
as closely as possible the ancient human reliance on shibboleths for 
security.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Ed Gerck]

Ian G wrote: (on Kerckhoffs's rules)

=
6. Finally, it is necessary, given the circumstances that command its 
application, that the system be easy to use, requiring neither mental 
strain nor the knowledge of a long series of rules to observe.

=
...
PS:  Although his 6th is arguably the most important


Yes. Usability should be the #1 property of a secure system.

Conventional security thinking says that usability and security are 
like a seesaw; if usability goes up, security must go down, and 
vice-versa. This apparent antinomy actually works as a synergy: with 
more usability in a secure system, security increases. With less 
usability in a secure system, security decreases. A secure system that 
is not usable will be left aside by users.


Cheers,
Ed Gerck

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[James A. Donald]

Steven M. Bellovin wrote:
> IPsec operates at layer 3, where there are (generally)
> no user contexts.  This makes it difficult to bind
> IPsec credentials to a user, which means that it
> inherently can't be as simple to configure as ssh.
>
> Put another way, when you tell an sshd whom you wish
> to log in as, it consults that user's home directory
> and finds an authorized_keys file. How can IPsec -- or
> rather, any key management daemon for IPsec -- do
> that?  Per-user SPDs?  Is this packet for port 80 for
> user pat or user chris?
>
> I can envision ways around this (especially if we have
> an IP address per user of a system -- I've been
> writing about fine-grained IP address assignment for
> years), but they're inherently a lot more complex than
> ssh.

This is a particular case of the layer problem I have
been ranting about for years:  Private and authenticated
sessions at layer X do not in themselves correspond to
private and authenticated sessions at layer Y, and for
users to arrange their affairs so that layer X does
indeed secure layer Y generally requires users to stand
on their heads and stick their right big toe in their
left ear.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Perry E. Metzger]

Thor Lancelot Simon <[EMAIL PROTECTED]> writes:
> On Sat, May 03, 2008 at 07:50:01PM -0400, Perry E. Metzger wrote:
>> I disagree. Fundamentally, OpenVPN isn't doing anything IPSEC couldn't
>> do, and yet is is fairly easy to configure.
>
> And yet there's no underlying technical reason why it is any easier to
> configure than IPsec is;

Absolutely. There is no reason one couldn't build an easy to configure
IPSec. Indeed, OpenVPN could simply use IPSec if its authors wanted
to.

No one has created the easy to configure IPSec, however, so I don't
use IPSec for my own needs.

> I find it amusing (but somewhat sad) that in fact one can find basically
> the same set of flaws in each, but they're considered damning in IPsec
> while they're handwaved away or overlooked in SSL VPNs.

Myself, I don't handwave away said flaws. I don't recommend that
clients use OpenVPN, for example. On the other hand, most of my
clients can afford to pay admins to spend lots of time on this, and I
couldn't afford to spend the time myself.

> And, in fact, most VPN software of any type fails this test.  My concern
> is that an excessive focus on "how hard is it to set this thing up?" can
> seriously obscure the important second half of the question "and if you
> set it up in the easiest possible way, is it safe?"

Well, it is pretty easy to configure SSH safely. Set it to only use
public keys, copy your private key to the remote host in the
authorized_keys file, and you're more or less done. There is no reason
all the defaults can't be set up for a nice easy to use IPSec based
package in such a way that it requires a deliberate effort to make the
thing unsafe and it is more or less that easy to use.

Unfortunately, people just don't spend nearly the amount of time on
the UI for their IPSec systems that they do on the crypto, so they
spoil all the hard work they've done making the implementation sound
by making it impossible for ordinary people to understand.


-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Ian G]

Perry E. Metzger wrote:


It is obvious to anyone using modern IPSec implementations that their
configuration files are a major source of pain. In spite of this, the
designers don't seem to see any problem. The result has been that
people see IPSec as unpleasant and write things like OpenVPN when the
underlying IPSec protocol is just fine and it is the implementations
that are unpleasant.



Kerckhoffs' 6th, providing great entertainment for the 
security world, since 1883.


=
6. Finally, it is necessary, given the circumstances that 
command its application, that the system be easy to use, 
requiring neither mental strain nor the knowledge of a long 
series of rules to observe.

=



iang


PS:  Although his 6th is arguably the most important, his 
others are well worth considering:


https://www.financialcryptography.com/mt/archives/000195.html

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Thor Lancelot Simon]

On Sat, May 03, 2008 at 07:50:01PM -0400, Perry E. Metzger wrote:
> 
> "Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
> > There's a technical/philosophical issue lurking here.  We tried to
> > solve it in IPsec; not only do I think we didn't succeed, I'm not at
> > all clear we could or should have succeeded.
> >
> > IPsec operates at layer 3, where there are (generally) no user
> > contexts.  This makes it difficult to bind IPsec credentials to a user,
> > which means that it inherently can't be as simple to configure as ssh.
> 
> I disagree. Fundamentally, OpenVPN isn't doing anything IPSEC couldn't
> do, and yet is is fairly easy to configure.

And yet there's no underlying technical reason why it is any easier to
configure than IPsec is; it is all a matter of the configuration interface
provided by your chosen SSL VPN (in this case, OpenVPN) or IPsec
implementation.

I find it amusing (but somewhat sad) that in fact one can find basically
the same set of flaws in each, but they're considered damning in IPsec
while they're handwaved away or overlooked in SSL VPNs.  Of course you
(Perry) or I can configure either IPsec or OpenVPN in a safe and sane way;
and, of course, there are some VPN packages of either type (IPsec or SSL
VPN) which have configuration interfaces so bad that we _couldn't_, in
fact, set them up safely -- because they prevent safe, sane configuration.

The problem is that whether you or I _can_ set software X up safely isn't
the question that matters.  The question that matters is "_will_ a naive
user who does not understand the underlying security questions set software
X up securely".

And, in fact, most VPN software of any type fails this test.  My concern
is that an excessive focus on "how hard is it to set this thing up?" can
seriously obscure the important second half of the question "and if you
set it up in the easiest possible way, is it safe?"

Thor

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Perry E. Metzger]

Jacob Appelbaum <[EMAIL PROTECTED]> writes:
> Perry E. Metzger wrote:
>> Until then, OpenVPN let me get started in about five minutes, and the
>> fact that it is less than completely secure doesn't matter much to me
>> as I'm running SSH under it anyway.
[...]
> I'm always curious to hear what designers of protocols actually use on a
> daily basis. I'm also really curious how said designers evaluate their
> choices.
>
> I really like OpenVPN. It's really smooth to setup, it's very easy to
> use on the Big Three Platforms.
>
> Have you read the source to OpenVPN? Do you think that it's
> cryptographically sound? Is it properly implemented?
>
> I've found some stuff I wonder about and I'm curious if anyone else has?

I can't claim to like the innards, and it seems bizarre to me that the
designers didn't simply use IPSec encapsulated in UDP as the
underlying protocol. (Were I writing such a thing today, I might use
DTLS.)

That said, in my usage pattern, I don't care much about the possible
security flaws. I would not recommend the package to clients, however.

It is obvious to anyone using modern IPSec implementations that their
configuration files are a major source of pain. In spite of this, the
designers don't seem to see any problem. The result has been that
people see IPSec as unpleasant and write things like OpenVPN when the
underlying IPSec protocol is just fine and it is the implementations
that are unpleasant.

-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Ray Dillinger]

On Sat, 2008-05-03 at 23:35 +, Steven M. Bellovin wrote:

> There's a technical/philosophical issue lurking here.  We tried to
> solve it in IPsec; not only do I think we didn't succeed, I'm not at
> all clear we could or should have succeeded.
> 
> IPsec operates at layer 3, where there are (generally) no user
> contexts.  This makes it difficult to bind IPsec credentials to a user,
> which means that it inherently can't be as simple to configure as ssh.

Let me restate things just to make sure I understand the problem.
You're talking about "binding IPsec credentials to a user," but 
I want to look at it from the point of view of exactly what 
problems this causes, so is the following an accurate position?

The problem is that we're trying to have entities with different 
security needs share a common set of authentications.  When user 'pat' 
and user 'sandy' have different security needs (different authorized
or trustable communication partners, to start with) we can't give 
them IPSEC because IPSEC operates on channels between machines 
rather than on channels between trusting/trusted entities.   Even 
if 'pat' and 'sandy' both have a trusted/trusting entity on a given
remote machine from theirs, IPSEC fails them because it cannot
differentiate between the various entities (users, agents, services)
using that remote machine, when 'pat' and 'sandy' need it to.  
Similarly, it fails the entities on that remote machine because it 
cannot differentiate between 'pat', 'sandy' and any other entities 
using the local machine, when trust relationships might exist only
for some subset of those entities.

Bear


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Ben Laurie]

Steven M. Bellovin wrote:

On Sat, 03 May 2008 17:00:48 -0400
"Perry E. Metzger" <[EMAIL PROTECTED]> wrote:


[EMAIL PROTECTED] (Peter Gutmann) writes:

I am left with the strong suspicion that SSL VPNs are "easier to
configure and use" because a large percentage of their user
population simply is not very sensitive to how much security is
actually provided.

They're "easier to configure and use" because most users don't want
to have to rebuild their entire world around PKI just to set up a
tunnel from A to B.

I'm one of those people who uses OpenVPN instead of IPSEC, and I'm one
of the people who helped create IPSEC.

Right now, to use SSH to remotely connect to a machine using public
keys, all I have to do is type "ssh-keygen" and copy the locally
generated public key to a remote machine's authorized keys file.
When there is an IPSEC system that is equally easy to use I'll switch
to it.

Until then, OpenVPN let me get started in about five minutes, and the
fact that it is less than completely secure doesn't matter much to me
as I'm running SSH under it anyway.


There's a technical/philosophical issue lurking here.  We tried to
solve it in IPsec; not only do I think we didn't succeed, I'm not at
all clear we could or should have succeeded.

IPsec operates at layer 3, where there are (generally) no user
contexts.  This makes it difficult to bind IPsec credentials to a user,
which means that it inherently can't be as simple to configure as ssh.

Put another way, when you tell an sshd whom you wish to log in as, it
consults that user's home directory and finds an authorized_keys file.
How can IPsec -- or rather, any key management daemon for IPsec -- do
that?  Per-user SPDs?  Is this packet for port 80 for user pat or user
chris?

I can envision ways around this (especially if we have an IP address
per user of a system -- I've been writing about fine-grained IP address
assignment for years), but they're inherently a lot more complex than
ssh.


I don't see why.

The ssh server determines who the packets are for from information sent 
to it by the ssh client.


The ssh client knows on whose behalf it is acting by virtue of being 
invoked by that user (I'll admit this is a simplification of the most 
general case, but I assert my argument is unaffected), and thus is able 
to include the information when it talks to the server.


Similarly, the client end of an IPSEC connection knows who opened the 
connection and could, similarly, convey that information. That data may 
not be available in some OSes by the time it gets to the IPSEC stack, 
but that's a deficiency of the OS, not a fundamental problem.


It seems to me there's no real difference between the two cases.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Jacob Appelbaum]

Perry E. Metzger wrote:
> [EMAIL PROTECTED] (Peter Gutmann) writes:
>>> I am left with the strong suspicion that SSL VPNs are "easier to configure
>>> and use" because a large percentage of their user population simply is not
>>> very sensitive to how much security is actually provided.
>> They're "easier to configure and use" because most users don't want to have 
>> to
>> rebuild their entire world around PKI just to set up a tunnel from A to B.
> 
> I'm one of those people who uses OpenVPN instead of IPSEC, and I'm one
> of the people who helped create IPSEC.
> 
> Right now, to use SSH to remotely connect to a machine using public
> keys, all I have to do is type "ssh-keygen" and copy the locally
> generated public key to a remote machine's authorized keys file.
> When there is an IPSEC system that is equally easy to use I'll switch
> to it.
> 
> Until then, OpenVPN let me get started in about five minutes, and the
> fact that it is less than completely secure doesn't matter much to me
> as I'm running SSH under it anyway.
> 

(As a disclaimer, I've hacked a little on Tunnelblick (the mac os x GUI)
and I've talked at length with the creator of OpenVPN.)

I'm always curious to hear what designers of protocols actually use on a
daily basis. I'm also really curious how said designers evaluate their
choices.

I really like OpenVPN. It's really smooth to setup, it's very easy to
use on the Big Three Platforms.

Have you read the source to OpenVPN? Do you think that it's
cryptographically sound? Is it properly implemented?

I've found some stuff I wonder about and I'm curious if anyone else has?

Regards,
Jacob Appelbaum

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Perry E. Metzger]

"Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
> There's a technical/philosophical issue lurking here.  We tried to
> solve it in IPsec; not only do I think we didn't succeed, I'm not at
> all clear we could or should have succeeded.
>
> IPsec operates at layer 3, where there are (generally) no user
> contexts.  This makes it difficult to bind IPsec credentials to a user,
> which means that it inherently can't be as simple to configure as ssh.

I disagree. Fundamentally, OpenVPN isn't doing anything IPSEC couldn't
do, and yet is is fairly easy to configure. I believe that I could
easily come up with a simpler configuration still, but we have a
worked example, so I don't think we can claim it is impossible any
longer.

It is true that I can't make it easy to configure all possible
uses of IPSec easily, but it should be easy to do the easy things and
it isn't. If it was easy to do easy things and possible to do
complicated things, that would be a reasonable place to get to -- I
know of no IPSec configuration system that is like that.

> Put another way, when you tell an sshd whom you wish to log in as, it
> consults that user's home directory and finds an authorized_keys file.
> How can IPsec -- or rather, any key management daemon for IPsec -- do
> that?  Per-user SPDs?  Is this packet for port 80 for user pat or user
> chris?

Almost exclusively the use for such things is nailing up a tunnel to
bring someone inside a private network. For that, there is no need for
per user auth -- the general assumption is that the remote box is a
single user laptop or something similar anyway. You really just want
to verify that the remote host has a particular private key, and if it
does, you nail up a tunnel to it (possibly allocating it a local IP
address in the process). That solves about 95% of the usage scenarios
and it requires very little configuration. It also covers virtually
all use of IPSec I see in the field.

Again, there are more complex usage scenarios, and it may be more
complicated to set one of *those* up, but it is a shame that it is
difficult to do the simple stuff.

-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Steven M. Bellovin]

On Sat, 03 May 2008 17:00:48 -0400
"Perry E. Metzger" <[EMAIL PROTECTED]> wrote:

> 
> [EMAIL PROTECTED] (Peter Gutmann) writes:
> >>I am left with the strong suspicion that SSL VPNs are "easier to
> >>configure and use" because a large percentage of their user
> >>population simply is not very sensitive to how much security is
> >>actually provided.
> >
> > They're "easier to configure and use" because most users don't want
> > to have to rebuild their entire world around PKI just to set up a
> > tunnel from A to B.
> 
> I'm one of those people who uses OpenVPN instead of IPSEC, and I'm one
> of the people who helped create IPSEC.
> 
> Right now, to use SSH to remotely connect to a machine using public
> keys, all I have to do is type "ssh-keygen" and copy the locally
> generated public key to a remote machine's authorized keys file.
> When there is an IPSEC system that is equally easy to use I'll switch
> to it.
> 
> Until then, OpenVPN let me get started in about five minutes, and the
> fact that it is less than completely secure doesn't matter much to me
> as I'm running SSH under it anyway.
> 
There's a technical/philosophical issue lurking here.  We tried to
solve it in IPsec; not only do I think we didn't succeed, I'm not at
all clear we could or should have succeeded.

IPsec operates at layer 3, where there are (generally) no user
contexts.  This makes it difficult to bind IPsec credentials to a user,
which means that it inherently can't be as simple to configure as ssh.

Put another way, when you tell an sshd whom you wish to log in as, it
consults that user's home directory and finds an authorized_keys file.
How can IPsec -- or rather, any key management daemon for IPsec -- do
that?  Per-user SPDs?  Is this packet for port 80 for user pat or user
chris?

I can envision ways around this (especially if we have an IP address
per user of a system -- I've been writing about fine-grained IP address
assignment for years), but they're inherently a lot more complex than
ssh.

--Steve Bellovin, http://www.cs.columbia.edu/~smb

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Jeff Simmons]

On Saturday 03 May 2008 14:00, Perry E. Metzger wrote:
> Right now, to use SSH to remotely connect to a machine using public
> keys, all I have to do is type "ssh-keygen" and copy the locally
> generated public key to a remote machine's authorized keys file.
> When there is an IPSEC system that is equally easy to use I'll switch
> to it.

OpenBSD has recently added the ipsecctl command, which greatly simplifies 
setting up IPSEC VPNs, especially between OpenBSD machines. A config file can 
be as simple as (from the man page):

ike esp from 192.168.3.1 to 192.168.3.2
ike esp from 10.1.1.0/24 to 10.1.2.0/24 peer 192.168.3.2

And the file structure for storing certs, public/private keys, and shared 
secrets (which ipsecctl searches automatically) is equally simple.

-- 
Jeff Simmons   [EMAIL PROTECTED]
Simmons Consulting - Network Engineering, Administration, Security
"You guys, I don't hear any noise.  Are you sure you're doing it right?"
--  My Life With The Thrill Kill Kult

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Perry E. Metzger]

[EMAIL PROTECTED] (Peter Gutmann) writes:
>>I am left with the strong suspicion that SSL VPNs are "easier to configure
>>and use" because a large percentage of their user population simply is not
>>very sensitive to how much security is actually provided.
>
> They're "easier to configure and use" because most users don't want to have to
> rebuild their entire world around PKI just to set up a tunnel from A to B.

I'm one of those people who uses OpenVPN instead of IPSEC, and I'm one
of the people who helped create IPSEC.

Right now, to use SSH to remotely connect to a machine using public
keys, all I have to do is type "ssh-keygen" and copy the locally
generated public key to a remote machine's authorized keys file.
When there is an IPSEC system that is equally easy to use I'll switch
to it.

Until then, OpenVPN let me get started in about five minutes, and the
fact that it is less than completely secure doesn't matter much to me
as I'm running SSH under it anyway.

Perry

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[Peter Gutmann]

Thor Lancelot Simon <[EMAIL PROTECTED]> writes:

>The upshot is that, indeed, at least as shown here, this particular
>configuration frontend to OpenVPN is very easy to configure -- if you are
>willing to settle for much less security than OpenVPN was designed to
>provide,

I think you mean:

]... if you're willing to avoid a huge pile of pointless PKI cruft.

which is a major feature of OpenVPN.

>I am left with the strong suspicion that SSL VPNs are "easier to configure
>and use" because a large percentage of their user population simply is not
>very sensitive to how much security is actually provided.

They're "easier to configure and use" because most users don't want to have to
rebuild their entire world around PKI just to set up a tunnel from A to B.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: User interface, security, and "simplicity"

[James A. Donald]

Thor Lancelot Simon wrote:

It's fashionable in some circles (including, it seems, this one) to bash
IPsec (particularly IKE) and tout SSL VPNs (particularly OpenVPN) on what
are basically user interface grounds.

I cannot help repeatedly noting that -- I believe more so than with actual
IPsec deployments, whether with or without IKE -- OpenVPN deployments are
often configured in hideously insecure ways.  This is no more the fault of
OpenVPN's designers, of course, than the ghastly configuration interfaces
imposed by many IKE impledmentations are the fault of IPsec's designers.


We are dropping on end users, sysadmins and nno crypto programmers 
decisions that seasoned cryptographers tend to screw up, and that end 
users and sysadmins are never going to comprehend.


The way programmers approach modularity and code locality tends to leave 
the end user outside the cryptographic boundary.  The cryptography 
module is very carefully made entirely independent of the user 
interface, merely sending up arcane errors from time to time.


Consider, for example, the recent cookie stealing security failure in 
Wordpress, fixed just a few days ago.  It seems that for a very long 
time, there was very straightforward, indeed in retrospect glaringly 
obvious, security hole that allowed anyone on the internet to take 
control of any host running Wordpress - which most hosts do run.  You 
can take control from Nigeria, you don't need to tap any lines.  Anyone 
anywhere in the world could have exercised any power over one's server 
that one's Wordpress application can exercise, which is usually near 
total power.


The defenders of SSL will quite correctly point out that the security 
hole had absolutely nothing to do with SSL.  The hole exists whether one 
uses SSL or not, and almost no one uses SSL with Wordpress.  And that 
was exactly the problem.  The writers of Wordpress, like the writers of 
every other application, had to handroll their own authentication, and 
of course fucked up.  SSL sessions are not user sessions, thus SSL 
authentication does not authenticate that user "admin" is the same 
entity (or even has the same  IP address) as the entity that correctly 
logged in as user admin, does not, cannot, attempt to provide such 
authentication, that being a higher layer issue - indeed, SSL 
authentication is pretty much irrelevant to authenticating anything that 
the attackers or defenders are likely to care about, which is why user 
admin on a Wordpress application does not use SSL.  SSL is so 
wonderfully localized that attackers just stroll around it.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]