Subject: Re: [TLS] PSK in 1.3?

From: Sven Schäge <[email-masked]>
Date: Thu, 19 Feb 2015 16:41:14 +0100

I was just reading through the TLS-PSK related discussions so far and came
across your post...

2014-10-20 14:13 GMT+02:00 Dan Harkins <[email-masked]>:

>
> On Sun, October 19, 2014 7:35 am, Yoav Nir wrote:
> >
> > I also understand that in practice, PSK ciphersuites are used only by
> > small devices, whereas the web and SMTP and other things never went for
> > it. But the standards donâ€™t say that. They donâ€™t say that PSK
> > ciphersuites are especially for constrained devices. So if we insist that
> > the same TLS 1.3 be used for both, and we donâ€™t want to say that PSK is
> > for weak security, then we should have a good story of why PFS is not
> > needed for PSK uses, whereas itâ€™s essential for all RSA uses.  If I
> > understand the mechanism correctly, PSKs tend to be long-lived, and a
> > subsequent compromise of a PSK (even if it is expired at the time of
> > compromise) allows an attacker to decrypt the content of a TLS session.
>
>   The non-PFS PSK ciphersuites are no different than the widely
> discredited, and easily cracked, WPA-PSK mode of WiFi security. It would
> be a really bad idea to continue with these ciphersuites in TLS 1.3. But
> the
> issue is not just PFS (or the lack of it), it's that PSK ciphersuites are
> susceptible to dictionary attack.
>
> > So either we believe that PSK compromise is unlikely, or we believe that
> > the data in a connection with a PSK ciphersuite is not future-sensitive.
> > If we donâ€™t, weâ€™re saying that weâ€™re just piling on security
> > nice-to-haves because we think the users can handle them.
>
>   There's no way that the protocol can be defined to justify that belief.
> What you're talking about is how people end up using the protocol and
> that is entirely out of the power of this WG. What we can do is to make
> TLS be as _misuse resistant_ as possible. And to do that we should not
> allow PSKs in TLS 1.3 unless they are used in a PAKE.
>
>   By the way, I'm surprised that no one is expressing outrageous outrage
> at the lack of a security proof for PSK ciphersuites.
>

Perhaps you might find

http://eprint.iacr.org/2014/037

useful.

>   regards,
>
>   Dan.
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

Many greetings,
Sven

---

From: "Christian Kahlo" <[email-masked]>
Date: Thu, 19 Feb 2015 17:21:34 +0100

BTW: We're using TLS_ECDHE_RSA_PSK_WITH_AES_256_CBC_SHA384 on a

custom code point for a couple of years now. Works well - even in customer

infrastructure with SPI firewalls.

BSI TR-03116-4 requires TLS1.2, EtM (RFC7366) and PFS. For some cases PSK is

needed as a three-party cryptographic binding. When I saw how lazy RFC7366

standardization was in this WG I just skipped talking about and we decided to

fulfill the requirements out-of-IETF-standard. It's sufficient if we rely on the

basics such as versions, record format, supported minimum, interoperable

cipher suites for non-internal infrastructure communication.

But maybe this is a pointer how to support PSK-PFS in TLS1.3+. I could provide

pseudo code from the key exchanger part. We would really appreciate PSK-PFS

as a public standard.

(No, we don't reveal source code of those projects. But we could add it to

i.e. BouncyCastle.)

Best regards,

Christian

Von: TLS [mailto:[email-masked]] Im Auftrag von Sven Schäge
Gesendet: Donnerstag, 19. Februar 2015 16:41
An: Dan Harkins; [email-masked]
Betreff: Re: [TLS] PSK in 1.3?

I was just reading through the TLS-PSK related discussions so far and came across your post...

be a really bad idea to continue with these ciphersuites in TLS 1.3. But the

 

Perhaps you might find 

useful.

  regards,

  Dan.

Many greetings,
Sven

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 21 Feb 2015 00:03:00 -0800 (PST)

Hi Sven,

On Thu, February 19, 2015 7:41 am, Sven SchÃ¤ge wrote:
>> > it. But the standards donÃ¢â‚¬â„¢t say that. They donÃ¢â‚¬â„¢t say
>> that PSK
>> > the same TLS 1.3 be used for both, and we donÃ¢â‚¬â„¢t want to say
>> that PSK is
>> > needed for PSK uses, whereas itÃ¢â‚¬â„¢s essential for all RSA uses.
>> If I
>> > If we donÃ¢â‚¬â„¢t, weÃ¢â‚¬â„¢re saying that weÃ¢â‚¬â„¢re just piling
>> on security

  No, I don't find that particularly useful. It doesn't assume a powerful
active attacker that is able to enumerate, off-line, from a database of
secrets that the PSK is likely drawn from. It's saying that if only the
client
and server know the PSK then the resulting secret will be known only to
them too which is not useful at all. It places the security of the protocol
in the hands of the people using it and that means the protocol can be
really secure or not secure at all. And therefore it's not secure at all.

  It's model is basically, "in an ideal world where no one misuses
anything and does nothing wrong and there are no active adversaries
trying to subvert anything…." which is not particularly useful.

  Protocols that use a shared symmetric key/code/word/phrase as a
credential should be judged by the criteria set forth here:

http://www.iacr.org/archive/eurocrypt2000/1807/18070140-new.pdf

Namely, "In a protocol we deem 'good' the adversary's chance to defeat
protocol goals will depend on how much she interacts with protocol
participants-- it won't significantly depend on her off-line computing
time." By that criteria, TLS-PSK is not good.

  regards,

  Dan.

---

From: John Mattsson <[email-masked]>
Date: Mon, 23 Feb 2015 14:55:34 +0000

Hi,
PSK cipher suites are not only used by small devices. They are well used (by e.g. 3GPP) for both terminal <-> server as well as server <-> server communication.
Seems to be confusion about PSK and passwords in the discussion. Passwords are generated by humans, offer low entropy and are weak. PSKs are not generated by humans, offers good entropy and are not weak.
Any PSK or RSA implementation that correctly used a good PRNG would not be susceptible to dictionary attacks. E.g. TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 is a perfectly fine cipher suite.
Non-PSF PSK has the same weaknesses as Non-PSF RSA. I think the authentication and key agreement discussions should be separated.
/John

On 21 Feb 2015, at 09:03, Dan Harkins <[email-masked]<mailto:[email-masked]>> wrote:

 Hi Sven,

2014-10-20 14:13 GMT+02:00 Dan Harkins <[email-masked]<mailto:[email-masked]>>:

I also understand that in practice, PSK ciphersuites are used only by
small devices, whereas the web and SMTP and other things never went
for
it. But the standards donÃ¢â,¬â"¢t say that. They donÃ¢â,¬â"¢t say
that PSK
ciphersuites are especially for constrained devices. So if we insist
that
the same TLS 1.3 be used for both, and we donÃ¢â,¬â"¢t want to say
that PSK is
for weak security, then we should have a good story of why PFS is not
needed for PSK uses, whereas itÃ¢â,¬â"¢s essential for all RSA uses.
If I
understand the mechanism correctly, PSKs tend to be long-lived, and a
subsequent compromise of a PSK (even if it is expired at the time of
compromise) allows an attacker to decrypt the content of a TLS
session.

issue is not just PFS (or the lack of it), it's that PSK ciphersuites
are

So either we believe that PSK compromise is unlikely, or we believe
that
the data in a connection with a PSK ciphersuite is not
future-sensitive.
If we donÃ¢â,¬â"¢t, weÃ¢â,¬â"¢re saying that weÃ¢â,¬â"¢re just piling
on security
nice-to-haves because we think the users can handle them.

 There's no way that the protocol can be defined to justify that
belief.

Perhaps you might find

useful.

 It's model is basically, "in an ideal world where no one misuses
anything and does nothing wrong and there are no active adversaries
trying to subvert anything.." which is not particularly useful.

 regards,

 Dan.

---

From: Alex Elsayed <[email-masked]>
Date: Sat, 21 Feb 2015 00:45:45 -0800

Dan Harkins wrote:

>>> > it. But the standards donÃ¢â¬â¢t say that. They donÃ¢â¬â¢t say
>>> that PSK
>>> > the same TLS 1.3 be used for both, and we donÃ¢â¬â¢t want to say
>>> that PSK is
>>> > needed for PSK uses, whereas itÃ¢â¬â¢s essential for all RSA uses.
>>> If I
>>> > If we donÃ¢â¬â¢t, weÃ¢â¬â¢re saying that weÃ¢â¬â¢re just piling
>>> on security
> secrets that the PSK is likely drawn from.

Sure, if they draw them from a database. Which would be about as stupid as 
choosing an RSA key from the Debian weak-keys bug, or doing ECDSA signatures 
with the same nonce every time, or similar boneheaded maneuvers that 
invalidate the protocol guarantees.

It's not the "pre-shared password" protocol, or even "pre-shared 
passphrase." It's "pre-shared key," and as such it should be used with a 
_proper key_ - that is to say, a string chosen uniformly at random from 
{0,1}^n where 'n' is the key size.

> It's saying that if only the client and server know the PSK then the 
> resulting secret will be known only to them too

Yes. That is the guarantee the protocol gives.

> which is not useful at all. It places the security of the
> protocol in the hands of the people using it and that means the protocol
> can be really secure or not secure at all.

But this is specious, because it's just as true of any number of other 
protocols - ECDSA's nonces being a particularly notable example. Reuse them, 
and you're leaking key bits like a firehose full of porcupines. Sony learned 
that the hard way.

Sure, I think easily-misused APIs are better avoided - but I also feel you 
are drastically overstating your case, and weakening it by doing so. When 
faced with people having said multiple times that 'drawing from a database' 
is user error and an invalid use of the protocol, it comes across as either 
obtuse or intellectually dishonest - neither of which I believe you are.

> And therefore it's not secure at all.

Then we really ought to stop using ECDSA... pretty much anywhere, since its 
nonces require much the same care.

> trying to subvert anything." which is not particularly useful.

No, its model is "For shared keys drawn uniformly from {0,1}^n, this is 
secure".

Active adversaries have nothing to do with it, so long as the user fulfils 
their side of the API contract.

> time." By that criteria, TLS-PSK is not good.

...no, if the user isn't screwing up in much the same kind of way as would 
lead them to horrific misuse of ECDSA, TLS-PSK is just fine.

I'm not saying PSK is ideal - it's patently not. A misuse-resistant protocol 
*that meets the needs of the people using PSK* would be wonderful to have.

But claiming it's worse than it is just makes people who see it as their 
only option feel more pressed to defend it, rather than actually helping to 
move the discussion forward on finding a viable alternative.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 23 Feb 2015 08:35:41 -0800 (PST)

Hi John,

On Mon, February 23, 2015 6:55 am, John Mattsson wrote:
> Hi,
> PSK cipher suites are not only used by small devices. They are well used
> (by e.g. 3GPP) for both terminal <-> server as well as server <-> server
> communication.
> Seems to be confusion about PSK and passwords in the discussion. Passwords
> are generated by humans, offer low entropy and are weak. PSKs are not
> generated by humans, offers good entropy and are not weak.
> Any PSK or RSA implementation that correctly used a good PRNG would not be
> susceptible to dictionary attacks. E.g.
> TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 is a perfectly fine cipher suite.

  There is no confusion (at least on my part). I think the confusion is that
you think that merely by naming ("this is a password", "this is a PSK") the
credential used you can make "a perfectly fine cipher suite."

  A dictionary attack is one in which the advantage gained by the adversary
is a function of computation and not interaction. It says nothing about the
size, or make up, of the pool from which the shared credential was drawn.
A good PRNG just ensures that each credential in the pool has an equally
good chance of being chosen. If the protocol you use the shared credential
with is susceptible to an attack whose success depends on computation
and not interaction with protocol participants than it's susceptible to a
dictionary attack.

  Now, granted, a pool that consisted of words from Webster's starting
with the letter "a" would be much smaller than a pool consisting of numbers
between 0 and 2^128 and a dictionary attack against the former would,
with high probability, return success faster than a dictionary attack against
the latter but the attack is identical.

  Increasing the size of the pool from which the credential was drawn
makes a dictionary attack take longer (and possibly prohibitively so) but
it doesn't magically make the protocol somehow resistant to dictionary
attack.

> Non-PSF PSK has the same weaknesses as Non-PSF RSA. I think the
> authentication and key agreement discussions should be separated.

  Key establishment and authentication go hand-in-hand. They have
to.

  And the issue is not key establishment versus authentication, it's
misuse resistance. PSKs are not misuse resistant, PAKEs are. And that
is because, regardless of the size of the pool from which the shared
credential was drawn, a dictionary attack (as defined above) is not
possible.

  Dan.

> /John
>
> On 21 Feb 2015, at 09:03, Dan Harkins
> <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>  Hi Sven,
>
> 2014-10-20 14:13 GMT+02:00 Dan Harkins
> <[email-masked]<mailto:[email-masked]>>:
>
>

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 23 Feb 2015 09:34:08 -0800 (PST)

Hi Alex,

> {0,1}^n where 'n' is the key size.

  Then your "database" is all numbers between 0 and 2^n. And you
randomly draw from that database.

> and you're leaking key bits like a firehose full of porcupines. Sony

  Yes, ECDSA has a misuse-resistance problem. Happily, that can be
hidden from "Joe Random, user of TLS" in a fashion that the PSK problem
cannot.

> obtuse or intellectually dishonest - neither of which I believe you are.

  Thanks. But by equating misuse resistance problems with a PSK with
misuse resistance problems with ECDSA you are "drastically overstating
your case and weakening it by doing so".

  "Drawing from a database" is not user error. Every PSK is drawn from
a database. You are just playing a semantic game by saying that if
n is less than some arbitrary number (which you don't define) then it's
a "dictionary" or "database" and if n is larger than some other arbitrary
number (which you also don't define) then it's not.

> nonces require much the same care.

  Uhm, no. The nonce in ECDSA needs to be unique per signature. The
user has no ability to influence this in a general purpose TLS library.
Whereas the PSK has to be plumbed, by the user, into the TLS library,
thereby opening up the misuse resistance can.

> No, its model is "For shared keys drawn uniformly from {0,1}^n, this is

  No, it's not. If n=8 then the attack is trivial and succeeds almost
instantaneously. If n=128 then with high probability a dictionary attack
will not be successful. But in neither case is that "secure".

> their side of the API contract.

  Active adversaries are the ones launching the attack. They have very
much to do with it!

> *that meets the needs of the people using PSK* would be wonderful to have.

  And those needs are what? Plumbing the PSK into TLS via some API call or
some UI. Which can be easily handled by a misuse-resistant PAKE. In fact,
the change from PSK cipher suite to PAKE cipher suite would not be apparent
from the point-of-view of "the needs of people using PSK."

> move the discussion forward on finding a viable alternative.

  A viable alternative is TLS-SRP. Or TLS-pwd. Since there is no augmentation
involved in the latter, it could be swapped in place of your favorite PSK
cipher
suite and you'd be none the wiser-- plumb the key, hey it works!

  regards,

  Dan.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Feb 2015 19:16:06 +0000

> number (which you also don't define) then it's not.

Every AES-128 key is drawn from a database: [0, 2^128-1]
Every AES-256 key is drawn from a database: [0, 2^256-1]

> will not be successful. But in neither case is that "secure".

The PSK is secure once the search cost for the PSK exceeds the cost
of brute-forcing the key of the agreed TLS symmetric algorithm.

One time pads aside, there are no absolutely "secure" crypto-systems,
all practical cryptography assumes a resource-bounded adversary.
So a 128-bit (uniformly randomly chosen) PSK used to negotiate an
AES-128 key is "secure".

So the argument seems to boil down to whether TLS should banish a
key management approach that can be fragile in the hands of naive
users, but can in fact be used "securely" when practiced properly.

Whether misuse of PSK is particularly more likely than various
other lapses (say unwitting deployment of MiTM root CAs) is not
obvious.  Far too few products get the security scrutiny they
deserve.

Device vendors will always find a way to ship gear with weak factory
security settings, whether PAKE, PSK, SSH keys, stock RSA keys, ...

I am very much sympathetic to the advantages of PAKE over PSK when
one of the key stores is a human brain, or people are involved in
the process of generating and distributing the shared secrets.  I
am not sure that this is sufficient grounds to rule out PSK, or
that doing so substantially addresses poor key management practices.

-- 
	Viktor.

---

From: Stephen Checkoway <[email-masked]>
Date: Mon, 23 Feb 2015 15:55:42 -0500

> will not be successful. But in neither case is that "secure".

What is your definition of secure then?

If drawing uniformly at random from {0,1}^n is not secure for any n, then doesn't that say that there is no way to use TLS securely? The master secret is merely a number in {0,1}^384, after all. And common (EC)DHE key exchanges involve a secret in {0,1}^n for n in [160, 256].

-- 
Stephen Checkoway

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 23 Feb 2015 16:06:52 -0800 (PST)

> What is your definition of secure then?

  I meant _the protocol_ is not secure in either case. The protocol doesn't
magically become secure because it gets used differently. I gave a
definition in this thread already.

  Dan.

---

From: Stephen Checkoway <[email-masked]>
Date: Mon, 23 Feb 2015 20:15:43 -0500

> definition in this thread already.

I must be missing something here. You're saying that since an adversary can, in theory, enumerate 2^n possible pre-shared keys for any n, the protocol is insecure.

I don't see how to square that with Bellare-Pointcheval-Rogaway's definitions (which I think is what you're using as your definition of security). You write,

> time." By that criteria, TLS-PSK is not good.

But that seems to misunderstand the quoted sentence. It's the adversaries chance to defeat the protocol goals which is deemed to be good, not the protocol itself. More to the point, the security of a protocol is defined in terms of an adversary running in time t and making q queries. If the passwords are drawn from a space of size N, then the fact that an adversary which runs in time N or makes N queries can have advantage 1 doesn't really tell us anything. See, for example, Theorem 1 of the BPR paper. If q_se = N, then the advantage is bounded by 1, but of course it is. That doesn't make the protocol under consideration insecure due to dictionary attacks. Indeed, see remark 9 just below noting that making N larger makes dictionary attacks moot.

-- 
Stephen Checkoway

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 23 Feb 2015 18:33:30 -0800 (PST)

On Mon, February 23, 2015 5:15 pm, Stephen Checkoway wrote:
> I must be missing something here. You're saying that since an adversary
> can, in theory, enumerate 2^n possible pre-shared keys for any n, the
> protocol is insecure.

  I'm saying that since the security of the protocol depends on it being
used right, _the protocol_ cannot be said to be secure.

> I don't see how to square that with Bellare-Pointcheval-Rogaway's
> definitions (which I think is what you're using as your definition of
> security). You write,
>
> But that seems to misunderstand the quoted sentence. It's the adversaries
> chance to defeat the protocol goals which is deemed to be good, not the
> protocol itself. More to the point, the security of a protocol is defined
> in terms of an adversary running in time t and making q queries. If the
> passwords are drawn from a space of size N, then the fact that an
> adversary which runs in time N or makes N queries can have advantage 1
> doesn't really tell us anything. See, for example, Theorem 1 of the BPR
> paper. If q_se = N, then the advantage is bounded by 1, but of course it
> is. That doesn't make the protocol under consideration insecure due to
> dictionary attacks. Indeed, see remark 9 just below noting that making N
> larger makes dictionary attacks moot.

  No, I don't think you understand the quoted sentence.  Note how they say,
"In a protocol we deem 'good'…" That right there means they're talking about
the protocol being good or not, and not the adversary's chance to defeat
protocol goals. The adversary's chance of defeating protocol goals will grow
(by exploiting the flaw in all protocols that authenticate using a symmetric
key/code/word/phrase), it's a matter of how. The _protocol_ is deemed
"good" if the adversary's advantage grows as a function of computing, not
as a function of interaction with protocol participants.

  As Remark 8 notes, "The resistance to dictionary attacks is captured
by the first term which is the number of send queries divided by the size
of the password space." Making q_se = N means that the number of
interactions is equal to the size of the password space and that does
not capture resistance to dictionary attack.

 It is obvious that a making n large enough can make a dictionary attack
moot. I have not said otherwise. It just doesn't make _the protocol_
resistant to dictionary attack.

  Dan.

---

From: Stephen Checkoway <[email-masked]>
Date: Mon, 23 Feb 2015 22:08:16 -0500

> used right, _the protocol_ cannot be said to be secure.

Every security protocol's security depends on it being used correctly. That doesn't seem like a useful metric here.

> protocol goals.

You may be right. I was mentally inserting a comma after "in a protocol" whereas you are inserting one after "good." But my reading doesn't fit with the rest of the sentence. My mistake.

> The adversary's chance of defeating protocol goals will grow
> key/code/word/phrase), it's a matter of how.

I don't think this is a matter of using a symmetric key/code/word/phrase at all. You have exactly the same problem using DHE. I can enumerate (in theory) the space of secret keys until I find one with a corresponding public key that appears in the TLS handshake. Now I've recovered the shared secret and I've done it with zero interaction with the protocol, purely offline computation.

> The _protocol_ is deemed

Wait, now you're saying something different. Before, you were saying that the advantage should grow as a function of interactions and quoted "the adversary's chance to defeat protocol goals will depend on how much she interacts with protocol participants--it won't significantly depend on her off-line computing time." But of course, it depends on both computation (time) and interactions and both are captured in the formal definitions given in the paper.

> not capture resistance to dictionary attack.

In your brute force attack, you're either making N connections to the server or you're watching a connection passively and computing N possible master secrets and seeing which enable to you decrypt. Either takes time at least N and both are captured in the notion of advantage. So if Adv(t,q) is the maximum advantage of an adversary running in time t, making q queries (similar to the definition of Adv_G^{dh} on page 149), we have either Adv(N,N) = 1 or Adv(N,0) = 1. Neither result is particularly meaningful and certainly doesn't tell us that TLS-PSK is insecure.

> resistant to dictionary attack.

This isn't a useful distinction then since no mode of TLS is resistant to dictionary attacks by what I take to be your definition.

-- 
Stephen Checkoway

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 24 Feb 2015 03:40:43 +0000

> This isn't a useful distinction then since no mode of TLS is resistant to dictionary attacks by what I take to be your definition.

I'd like to suggest that this thread is going nowhere at present.

I don't think any of the below are controversial.

    * PSK is vulnerable to dictionary attacks when poor key management
      leads to a reduced key space.

    * PAKE protocols offer greater resistance to off-line dictionary
      attacks.

    * PSK *with properly selected keys* is secure in practice, once
      the brute force search is at least as expensive as brute-forcing
      the symmetric-algorithm keyspace.

    * No key management approach is perfect.

At which point it makes sense to step back and decide whether the
risk of reduced key-space with PSK warrants dropping support, even
though other approaches that are staying also have potential flaws.

Is there a suitable PAKE that is ready to replace all applications
of PSK?  Is it practical in all the environments that would otherwise
opt to use PSK?  If PSK is simply an obsolete needlessly weaker
shared secret system, then good riddance.  If not, then the discussion
should be about why PSK is more practical despite its limitations.

-- 
	Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 23 Feb 2015 21:36:53 -0800

> Every security protocol's security depends on it being used correctly. That doesn't seem like a useful metric here.

As far as I can tell, neither of you actually are arguing about what
you're actually arguing about. The question isn't whether PSK mode
satisfies the Bellare-Pointcheval-Rogaway definitions. Instead, it's
about using in TLS 1.3 vs replacing it with a mode that uses a PAKE
instead. The stated argument is that PSK is getting deployed with
passwords instead of keys in many places: that's completely orthogonal
to the discussion that's been taking place.

As far as how much PAKEs cost, SPAKE2 is 2.5 exponentiations per side.
Elligator is 2, but slightly harder to implement. On 32-bit arm
processors I think these exponentiations cost around 2 million cycles
according to SUPERCOP.  So not a completely trivial cost, but most
processors will do better, and I think the measurement was borked due
to compiler issues.

(Elligator might even be possible on genus 2: let me think about that
for a while. Certainly on hyper-and-elliptic. )

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin