Re: Gutmann Soundwave Therapy

2008-02-13 Thread Peter Gutmann
Daniel Carosone [EMAIL PROTECTED] writes:
On Mon, Feb 04, 2008 at 02:48:08PM -0700, Martin James Cochran wrote:
 Additionally, in order to conserve bandwidth you might want to make a
 trade-off where some packets may be forged with small probability (in the
 VOIP case, that means an attacker gets to select a fraction of a second of
 sound, which is probably harmless)

This is ok, if you consider the only threat to be against the final endpoint:
a human listening to a short-term, disposable conversation. I can think of
some counter-examples where these assumptions don't hold:

- A data-driven exploit against an implementation vulnerability in your codec
  of choice.  Always a possibility, but a risk you might rate differently (or
  a patch you might deploy on a different schedule) for conversations with
  known and trusted peers than you would for arbitrary peers, let alone
  maliciously-inserted traffic. How many image decoding vulnerabilities have
  we seen lately, again?
[...]
Particularly for the first point, early validation for packet integrity in
general can be a useful defensive tool against unknown potential
implementation vulnerabilities.

This is an example of what psychologists call own-side bias (everyone thinks
like us), in this case the assumption that after a peer has authenticated
itself it'd never dream of sending a malformed packet and so we don't need to
do any checking after the handshake has completed.  Why would you trust data
coming from a remote system just because they've jumped through a few hoops
before sending it?  I can steal the remote system's credentials or hijack the
session and then send you anything I want, it's no safer to blindly accept the
data if there's a MAC attached or not.

More scarily, and specifically for the case of VoIP, the security of many SIP
devices is absolutely appalling (for German speakers there's a paper on this
at the DFN-Cert workshop in a few days,
https://www.dfn-cert.de/events/ws/2008/programm.html).  So the obvious attack
vector is to 0wn the peer's SIP device and ensure that it creates malformed
data packets well before the security layer ever takes effect.  As a result
your secured tunnel is pouring out carefully authenticated attack packets as
fast as it can send them.  The bad guys have been exploiting this for years,
spamming their malware out to trusted friends on contact lists, and it's
proven quite successful.

Hostile data inside a secure tunnel or wrapper is still hostile data.  As the
OP said, as long as you can deterministically detect attacks (which a 1-of-n
packet MAC will do) you're not giving up much security by not MAC'ing all
packets.

Peter.

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


Re: Gutmann Soundwave Therapy

2008-02-13 Thread Daniel Carosone
On Mon, Feb 11, 2008 at 07:01:07PM +1300, Peter Gutmann wrote:
 Daniel Carosone [EMAIL PROTECTED] writes:
 [...]
 Particularly for the first point, early validation for packet integrity in
 general can be a useful defensive tool against unknown potential
 implementation vulnerabilities.
 
 This is an example of what psychologists call own-side bias (everyone thinks
 like us), in this case the assumption that after a peer has authenticated
 itself it'd never dream of sending a malformed packet and so we don't need to
 do any checking after the handshake has completed.  Why would you trust data
 coming from a remote system just because they've jumped through a few hoops
 before sending it?  I can steal the remote system's credentials or hijack the
 session and then send you anything I want, it's no safer to blindly accept the
 data if there's a MAC attached or not.

Point taken, but I respectfully disagree with the relevance in the
present context, though of course I agree entirely in the wider
philosophical sense.

Remember that we're also talking about practical deployment decisions:
 - if someone steals credentials, they can do all sorts of mischief
   and damage; the incremental risk in the present discussion is that
   doing 'lossy'/partial validation may allow additional injection and
   MITM attacks beyond those.
 - especially for the other cases I gave (SNMP and NTP), the
   alternative mitigating controls are such strong things as IP
   address based ACLs (on UDP packets). I'll take the stronger tool if
   it's on offer.

The fact this kind of authentication is applied before the packet gets
to more complex and potentially vulnerable parsing and processing code
gives me a valuable opportunity to be defensive, especially as an end
customer deploying some random vendor's kit.

In those cases, I don't have visibility of the implementation, but I
do have some assurance about the order of operations and can put that
structural knowledge to good use.  Much the same is true in this
discussion about protocol design; we're making no specifications about
processing of the data once the transport hands it off, but we're
starting to make assumptions about the risks therein, and the reliance
those layers may be placing on the transport, for better or worse.

Your criticism would be fair if I was advocating blindly accepting the
data or not doing any checking after the initial handshake.  It would
be fair criticism of a codec vendor who took such a stance, relying
overly on transport authentication (or forcing me to). I am most
certainly not advocating that, merely recognising that sometimes such
checking may be deficient or vulnerable, or just simply uncertain. 

Good defensive protocol design lets me validate the blob before
inspecting the fields; poor defensive programming conflates frame
validation with more detailed syntactic and semantic validation later.

If there are authentication-hijacking vulnerabilities in the endpoints
(like your SIP gateway), sure, I'm screwed in a number of ways.
That's sad, but a given regardless of whatever variant and detail of
keying and MACing mechanism this discussion comes up with.

 Hostile data inside a secure tunnel or wrapper is still hostile data. 

If cryptography can come up with some way to ensure robustness against
hostile data all the way down an implementation stack, regardless of
layering, we'll all be surprised.  Some of us might even be very rich.

Otherwise, it's a risk mitigation tool, subject to constraints we need
to understand.  If the constraints are ones of key management and
endpoint security, I can use the mechanism in my toolkit.  If the
constrains mean that every fourth SNMP request or routing update will
be unauthenticated, it's much less use to me as a structural security
layer; the bar isn't raised in any practical sense.

 As the OP said, as long as you can deterministically detect attacks
 (which a 1-of-n packet MAC will do) you're not giving up much
 security by not MAC'ing all packets.

I attempted to illustrate, with some counterexamples, threat models
where even one unauthenticated packet could lose you more than not
much security.  Threats where detection of the attack wasn't enough,
or was too late, or was itself the point.

Robust implementation behind that MAC is essential, and helps realise
and provide assurance around not much, as well as addressing broader
threats that are more likely in the overall economic argument we
acknowledged at the outset, but is outside what I saw as the OP's
scope, and not part of the incremental risk I was highlighting.

--
Dan.

pgpHBm0jjURiV.pgp
Description: PGP signature


Re: Gutmann Soundwave Therapy

2008-02-09 Thread Daniel Carosone
Others have made similar points and suggestions, not picking on this
instance in particular:

On Mon, Feb 04, 2008 at 02:48:08PM -0700, Martin James Cochran wrote:
 Additionally, in order to conserve bandwidth you might want to make a 
 trade-off where some packets may be forged with small probability (in the 
 VOIP case, that means an attacker gets to select a fraction of a second of 
 sound, which is probably harmless)

This is ok, if you consider the only threat to be against the final
endpoint: a human listening to a short-term, disposable conversation.
I can think of some counter-examples where these assumptions don't
hold:

 - A data-driven exploit against an implementation vulnerability in
   your codec of choice.  Always a possibility, but a risk you might
   rate differently (or a patch you might deploy on a different
   schedule) for conversations with known and trusted peers than you
   would for arbitrary peers, let alone maliciously-inserted traffic.
   How many image decoding vulnerabilities have we seen lately, again?

 - People have invented and do use such horribly-wrong things as
   fax-over-voip; while they seem to have some belief in their own
   business case, I may not have as much faith in their implementation
   robustness.
   
 - Where it's audio, but the audience is different such that the
   impact of short bursts of malicious sound is different: larger
   teleconferences, live interviews or reporting by journalists, and
   other occasions, particularly where the credibility of the speaker
   is important.  Fractions of seconds of sound is all I might need to
   insert to .. er .. emulate tourette's syndrome. Fractions of
   seconds of soundwave therapy could still be highly unpleasant or
   embarassing.

Particularly for the first point, early validation for packet
integrity in general can be a useful defensive tool against unknown
potential implementation vulnerabilities.  I've used similar arguments
before around the use of keyed authentication of other protocols, such
as SNMPv3 and NTP.

It also reminds me of examples where cryptographic protections have
only covered certain fields in a header or message.  Attackers may
find novel ways to use the unprotected space, plus it just makes the
whole job of risk analysis at deployment orders of magnitude more
complex.

Without dismissing the rest of the economic arguments, when it comes
to these kinds of vulnerabilities, be very wary of giving an attacker
this inch, they may take a mile.  

--
Dan.


pgpP4RjLsu7PD.pgp
Description: PGP signature


Re: Gutmann Soundwave Therapy

2008-02-09 Thread Leichter, Jerry
|  - Truncate the MAC to, say, 4 bytes.  Yes, a simple brute
|  force attack lets one forge so short a MAC - but
|  is such an attack practically mountable in real
|  time by attackers who concern you?
| 
| In fact, 32-bit authentication tags are a feature of
| SRTP (RFC 3711). 
Great minds run in the same ruts.  :-)

|  - Even simpler, send only one MAC every second - i.e.,
|  every 50 packets, for the assumed parameters.
|  Yes, an attacker can insert a second's worth
|  of false audio - after which he's caught.  I
|  suppose one could come up with scenarios in
|  which that matters - but they are very specialized.
|  VOIP is for talking to human beings, and for
|  human beings in all but extraordinary circumstances
|  a second is a very short time.
| 
| Not sending a MAC on every packet has difficult interactions with
| packet loss. If you do the naive thing and every N packets send a MAC
| covering the previous N packets, then if you lose even one of those
| packets you can't verify the MAC. But since some packet loss is
| normal, an attacker can cover their tracks simply by removing one out
| of every N packets.
*Blush*.  Talk about running in the same ruts.  I was specifically
talking about dealing with lossy datagram connections, but when I came
to making a suggestion, suggested one I'd previously considered for
non-lossy stream connections.  Streams are so much easier to reason
about - it's easy to get caught.  (It's also all too easy to forget
that no stream implementation really implements the abstract semantics
of a reliable stream - which is irrelevant in some cases, but very
significant in others.)

| Since (by definition) you don't have a copy of the packet you've lost,
| you need a MAC that survives that--and is still compact. This makes
| life rather more complicated. I'm not up on the most recent lossy
| MACing literature, but I'm unaware of any computationally efficient
| technique which has a MAC of the same size with a similar security
| level. (There's an inefficient technique of having the MAC cover all
| 2^50 combinations of packet loss, but that's both prohibitively
| expensive and loses you significant security.)
My suggestion for a quick fix:  There's some bound on the packet loss
rate beyond which your protocol will fail for other reasons.  If you
maintain separate MAC's for each k'th packet sent, and then deliver k
checksums periodically - with the collection of checksums itself MAC'ed,
a receiver should be able to check most of the checksums, and can reset
itself for the others (assuming you use a checksum with some kind of
prefix-extension property; you may have to send redundant information
to allow that, or allow the receiver to ask for more info to recover).

Obviously, if you *really* use every k'th packet to define what is in
fact a substream, an attacker can arrange to knock out the substream he
has chosen to attack.  So you use your encryptor to permute the
substreams, so there's no way to tell from the outside which packet is
part of which substream.  Also, you want to make sure that a packet
containing checksums is externally indistinguishable from one containing
data.  Finally, the checksum packet inherently has higher - and much
longer-lived - semantic value, so you want to be able to request that
*it* be resent.  Presumably protocols that are willing to survive data
loss still have some mechanism for control information and such that
*must* be delivered, even if delayed.

Tons of hand-waving there; at the least, you have to adjust k and
perhaps other parameters to trade off security and overhead.  I'm
pretty sure something along these lines could be done, but it's
certainly not off-the-shelf.
-- Jerry

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


Re: Gutmann Soundwave Therapy

2008-02-09 Thread dan

  Amateurs talk about algorithms.  Professionals talk about economics.


That would be


  Amateurs study cryptography; professionals study economics.
  -- Allan Schiffman, 2 July 04


Quotationally yours,

--dan

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


Re: Gutmann Soundwave Therapy

2008-02-09 Thread Richard Salz
 Thus unlike with bridges, you fundamentally can't 
 evaluate the quality of a security system you built if you're unfamiliar 

 with the state of the art of _attacks_ against security systems, and you 

 can't become familiar with those unless you realize that these attacks 
 have each brought down a system previously considered impregnable.

I don't see how this invalidates my analogy.

In 1940 they didn't know understand about wind-induced vibration and yet 
it brought down the Tacoma Narrows bridge.  A few years ago we didn't know 
much about hash collisions, yet since then the field has brought down MD5.

If the field isn't codified, all the more reason to spread knowledge 
rather than encourage a priesthood.

/r$

--
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/

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


Re: Gutmann Soundwave Therapy

2008-02-09 Thread Eric Rescorla
At Thu, 7 Feb 2008 10:34:42 -0500 (EST),
Leichter, Jerry wrote:
 | Since (by definition) you don't have a copy of the packet you've lost,
 | you need a MAC that survives that--and is still compact. This makes
 | life rather more complicated. I'm not up on the most recent lossy
 | MACing literature, but I'm unaware of any computationally efficient
 | technique which has a MAC of the same size with a similar security
 | level. (There's an inefficient technique of having the MAC cover all
 | 2^50 combinations of packet loss, but that's both prohibitively
 | expensive and loses you significant security.)
 My suggestion for a quick fix:  There's some bound on the packet loss
 rate beyond which your protocol will fail for other reasons.  If you
 maintain separate MAC's for each k'th packet sent, and then deliver k
 checksums periodically - with the collection of checksums itself MAC'ed,
 a receiver should be able to check most of the checksums, and can reset
 itself for the others (assuming you use a checksum with some kind of
 prefix-extension property; you may have to send redundant information
 to allow that, or allow the receiver to ask for more info to recover).

So, this issue has been addressed in the broadcast signature context
where you do a two-stage hash-and-sign reduction (cf. [PG01]), but
when this only really works because hashes are a lot more efficient
than signatures. I don't see why it helps with MACs.


 Obviously, if you *really* use every k'th packet to define what is in
 fact a substream, an attacker can arrange to knock out the substream he
 has chosen to attack.  So you use your encryptor to permute the
 substreams, so there's no way to tell from the outside which packet is
 part of which substream.  Also, you want to make sure that a packet
 containing checksums is externally indistinguishable from one containing
 data.  Finally, the checksum packet inherently has higher - and much
 longer-lived - semantic value, so you want to be able to request that
 *it* be resent.  Presumably protocols that are willing to survive data
 loss still have some mechanism for control information and such that
 *must* be delivered, even if delayed.

This basically doesn't work for VoIP, where latency is a real issue.


-Ekr

[PG01] Philippe Golle, Nagendra Modadugu: Authenticating Streamed Data in the 
Presence of
Random Packet Loss. NDSS 2001

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


Re: Gutmann Soundwave Therapy

2008-02-09 Thread Leichter, Jerry
| So, this issue has been addressed in the broadcast signature context
| where you do a two-stage hash-and-sign reduction (cf. [PG01]), but
| when this only really works because hashes are a lot more efficient
| than signatures. I don't see why it helps with MACs.
Thanks for the reference.

|  Obviously, if you *really* use every k'th packet to define what is in
|  fact a substream, an attacker can arrange to knock out the substream he
|  has chosen to attack.  So you use your encryptor to permute the
|  substreams, so there's no way to tell from the outside which packet is
|  part of which substream.  Also, you want to make sure that a packet
|  containing checksums is externally indistinguishable from one containing
|  data.  Finally, the checksum packet inherently has higher - and much
|  longer-lived - semantic value, so you want to be able to request that
|  *it* be resent.  Presumably protocols that are willing to survive data
|  loss still have some mechanism for control information and such that
|  *must* be delivered, even if delayed.
| 
| This basically doesn't work for VoIP, where latency is a real issue.
It lets the receiver to make a choice:  Deliver the data immediately,
avoiding the latency at the cost of possibly releasing bogus data (which
we'll find out about, and report, later); or hold off on releasing the
data until you know it's good, at the cost of introducing audible
artifacts.  In non-latency-sensitive designs, the prudent approach is to
never allow data out of the cryptographic envelope until you've
authenticated it.  Here, you should probably be willing to do that, on
the assumption that the application layer - a human being - will know
how to react if you tell him authentication has failed, please
disregard what you heard in the last 10 seconds.  (If you record the
data, the human being doesn't have to rely on memory - you can tell him
exactly where things went south.)  There are certainly situation where
this isn't good enough - e.g., if you're telling a fighter pilot to fire
a missile, a fake command may be impossible to countermand in time to
avoid damage - but that's pretty rare.
-- Jerry

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


RE: Gutmann Soundwave Therapy

2008-02-09 Thread Crawford Nathan-HMGT87
 humans are not going to carry around large strong secrets every time
either end of the connection restarts

Which is what makes good crypto challenging.  I think, though, that
because people can understand the concept of physical locks and keys,
that this should be carried forward...

Good security is based on something you have, something you know, and
something you are.  While the third case would be rather difficult to
reliably implement on a mass-market scale, the former two are not
difficult at all.  Especially now that USB drives and CDROMs are the
defacto media standard.

Passwords do have known weaknesses - people tend to pick easily
remembered (and easily guessed) passwords.  However, when used in
combination with an external key, the security damage is at least
partially mitigated.  A system which relied on both would probably be
more secure than one which simply relied on the user entering their
password.

I've been floating the idea of selling keys on removable media.  The
core idea would be that if you get the user to use crypto keys in a
manner similar to the way they use physical keys, that you could avoid a
substantial amount of confusion, and would keep them from doing insecure
things.  You know, the typical weak password kind of thing.  If the user
has to physically plug in a USB stick for every secure session:

1.) It mitigates to a small degree the danger of key leakage because the
keys are only present on the system for small periods of time.
2.) It makes it easier for the user to use crypto - a weak password to
access the key database does not carry forward to a weak password for
session purposes.  That is, the user can have a weak key database
password without compromising the security of the underlying crypto used
for the session.

The problem is not that strong crypto is elusive, but rather, that using
it is often non-intuitive for the average user.  An unusable, or
error-prone crypto system is often worse than having none at all.


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


Re: Gutmann Soundwave Therapy

2008-02-09 Thread Eric Rescorla
At Thu, 7 Feb 2008 14:42:36 -0500 (EST),
Leichter, Jerry wrote:
 |  Obviously, if you *really* use every k'th packet to define what is in
 |  fact a substream, an attacker can arrange to knock out the substream he
 |  has chosen to attack.  So you use your encryptor to permute the
 |  substreams, so there's no way to tell from the outside which packet is
 |  part of which substream.  Also, you want to make sure that a packet
 |  containing checksums is externally indistinguishable from one containing
 |  data.  Finally, the checksum packet inherently has higher - and much
 |  longer-lived - semantic value, so you want to be able to request that
 |  *it* be resent.  Presumably protocols that are willing to survive data
 |  loss still have some mechanism for control information and such that
 |  *must* be delivered, even if delayed.
 | 
 | This basically doesn't work for VoIP, where latency is a real issue.
 It lets the receiver to make a choice:  Deliver the data immediately,
 avoiding the latency at the cost of possibly releasing bogus data (which
 we'll find out about, and report, later); or hold off on releasing the
 data until you know it's good, at the cost of introducing audible
 artifacts.  In non-latency-sensitive designs, the prudent approach is to
 never allow data out of the cryptographic envelope until you've
 authenticated it.  Here, you should probably be willing to do that, on
 the assumption that the application layer - a human being - will know
 how to react if you tell him authentication has failed, please
 disregard what you heard in the last 10 seconds.

Well, since there's a much simpler procedure accept ~5-10% overhead, this 
doesn't seem like a particularly attractive design.

-Ekr

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


Re: Gutmann Soundwave Therapy

2008-02-09 Thread Peter Gutmann
Leichter, Jerry [EMAIL PROTECTED] writes:

All of this ignores a significant issue:  Are keying and encryption (and
authentication) mechanisms really independent of each other? I'm not aware of
much work in this direction.

Is there much work to be done here?  If you view the keyex mechanism as a
producer of an authenticated blob of shared secrecy and the post-keyex
portions (data transfer or whatever you're doing) as a consumer of said blob,
with a PRF as impedance-matcher (as is done by SSL/TLS, SSH, IPsec, ..., with
varying degrees of aplomb, and in a more limited store-and-forward context
PGP, S/MIME, ...), is there much more to consider?

Peter.

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


Re: Gutmann Soundwave Therapy

2008-02-09 Thread Leichter, Jerry
| All of this ignores a significant issue:  Are keying and encryption
| (and authentication) mechanisms really independent of each other? I'm
| not aware of much work in this direction.
| 
| Is there much work to be done here?  If you view the keyex mechanism
| as a producer of an authenticated blob of shared secrecy and the
| post-keyex portions (data transfer or whatever you're doing) as a
| consumer of said blob, with a PRF as impedance-matcher (as is done by
| SSL/TLS, SSH, IPsec, ..., with varying degrees of aplomb, and in a
| more limited store-and-forward context PGP, S/MIME, ...), is there
| much more to consider?
I don't know.  Can you prove that your way of looking at it is valid?
After all, I can look at encryption as applying a PRF to a data
stream, and authentication as computing a keyed one-way function (or
something) - so is there anything to prove about whether I can choose
and combine them independently?  About whether Encrypt-then-MAC and
MAC-then-Encrypt are equivalent?

I should think by now that we've learned how delicate our cryptographic
primitives can be - and how difficult it can be to compose them in a
way that retains all their individual guarantees.

-- Jerry

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


Re: Gutmann Soundwave Therapy

2008-02-06 Thread James A. Donald

James A. Donald wrote:
 I have figured out a solution, which I may post here
 if you are interested.

Ian G wrote:
 I'm interested.  FTR, zooko and I worked on part of
 the problem, documented briefly here:
 http://www.webfunds.org/guide/sdp/index.html

I have posted How to do VPNs right at
http://jim.com/security/how_to_do_VPNs.html

It covers somewhat different ground to that which your
page covers, focusing primarily on the problem of
establishing the connection.

humans are not going to carry around large
strong secrets every time either end of the
connection restarts.  In fact they are not going
to transport large strong secrets any time ever,
which is the flaw in SSL and its successors such
as IPSec and DTLS

What humans are going to do, and what the user
interface must support, and the cryptography
somehow make secure, is set up a username and a
rather short password, and enter that password
on request - rather too easily enter it on
request without necessarily checking who they
are giving it to.  Our security has to work with
humans as they are, and make what humans are
naturally inclined to do secure, rather than try
to change what humans are naturally inclined to
do.

It covers the cryptography of packets only to the depth
needed to establish the required properties of sessions:
each packet within a session must have its own
unique IV (nonce), and each session must have
its own symmetric encryption secret and
authentication secret.  We have to have a new
session every client restart, every server
restart, and every 2^64 bytes.  At the beginning
of each new session, new strong secrets, large
truly random numbers, have to be negotiated for
symmetric encryption and authentication.

My page completely ignores the routing issue, another
hard problem which existing VPNs frequently do wrongly,
or not at all.  It presupposes the existence of good
random number sources.

It does not address the question of denial of service
attacks against the session establishment protocol,
though I have written that up elsewhere, and will
publish that shortly.

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


Re: Gutmann Soundwave Therapy

2008-02-06 Thread Peter Gutmann
Guus Sliepen [EMAIL PROTECTED] writes:

Peter sent us his write-up up via private email a few days before he posted
it to this list (which got it on Slashdot). I had little time to think about
the issues he mentioned before his write-up became public.

I should provide some background for the writeup, it started when someone sent
me a link to some VPN software they were using and asked whether it was
actually secure.  I looked at it, found that it was, well, pretty awful, and
told them so.

So they sent me a link to another VPN app.  I had a look at it and it was just
as bad.

By this time it'd turned into an ongoing discussion/attempt to track down some
sort of decent easy-to-use secure-VPN app.  The more we found, the more
discouraged I became.  Initially we'd tried to contact developers but didn't
get much (if any) response, so that towards the end (after getting to the n-th
broken VPN app), to quote the VAX assembler manual, little sympathy was
extended.  After the initial writeup ended up on Slashdot I did a bit more
googling and found out that some of the problems had been pointed out by
others years before I noted them with no action from the application authors
to fix anything.  This, again, didn't inspire much confidence.

In terms of problems, it wasn't just the homebrew crypto mechanisms, there
were also numerous problems with careless implementations.  One thing that was
very common was to find very little error- or sanity-checking.  Function
return calls weren't checked, critical errors like crypto failures were logged
but the app continued anyway (!!), operations were assumed to have succeeded
at all times, even minor things like checking for an error return with a check
for '== -1' when the function could also fail with a return status of zero (so
only some failures were caught and the code could continue with ininitialised
crypto), the list just went on and on.

When tinc 2.0 will ever come out (unfortunately I don't have a lot of time to
work on it these days), it will probably use the GnuTLS library and
authenticate and connect daemons with TLS. For performance reasons, you want
to tunnel network packets via UDP instead of TCP, so hopefully there is a
working DTLS implementation as well then.

I think OpenVPN took the right approach here, they took the part of IPsec that
works well (the ESP transport mechanism) and bolted on the TLS handshake to
replace IKE (DTLS has only appeared quite recently).  They didn't have to
invent their own mechanisms for anything, but took tried-and-tested crypto
mechanisms and code and just went with that.

Peter.

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


Re: Gutmann Soundwave Therapy

2008-02-06 Thread Peter Gutmann
Ian G [EMAIL PROTECTED] writes:
James A. Donald wrote:
 I have been considering the problem of encrypted channels over UDP or
 IP.  TLS will not work for this, since it assumes and provides a
 reliable, and therefore non timely channel, whereas what one wishes to
 provide is a channel where timeliness may be required at the expense of
 reliability.

This is what Guus was getting at:

- We needed to tunnel data over UDP, with UDP semantics. SSL requires a
  reliable stream. Therefore, we had to use something other that SSL to
  tunnel data.

This is where the OpenVPN developers got it right: Use TLS for the handshake
and IPsec's ESP for the transport.  It's been a solved problem for some years
now.

Peter.

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


Re: Gutmann Soundwave Therapy

2008-02-06 Thread Peter Gutmann
Eric Rescorla [EMAIL PROTECTED] writes:

I don't propose to get into an extended debate about whether it is better to
use SRTP or to use generic DTLS. That debate has already happened in IETF and
SRTP is what the VoIP vendors are doing. However, the good news here is that
you can use DTLS to key SRTP (draft-ietf-avt-dtls-srtp), so there's no need
to invent a new key management scheme.

Hmm, given this X-to-key-Y pattern (your DTLS-for-SRTP example, as well as
OpenVPN using ESP with TLS keying), I wonder if it's worth unbundling the key
exchange from the transport?  At the moment there's (at least):

  TLS-keying --+-- TLS transport
   |
   +-- DTLS transport
   |
   +-- IPsec (ESP) transport
   |
   +-- SRTP transport
   |
   +-- Heck, SSH transport if you really want

Is the TLS handshake the universal impedance-matcher of secure-session
mechanisms?

Peter.

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


Re: Gutmann Soundwave Therapy

2008-02-06 Thread Ivan Krstić

On Jan 31, 2008, at 10:32 PM, Richard Salz wrote:
Developers working in almost any field should know the history and  
best
practices -- is PGP's original bass o matic any more important  
than the
code in a defibrillator? -- but this is not the way our field works  
right

now.  Compare it to something like civil engineering or architecture.



I think this misses the point. Security is different.

In 2008, I can learn to build pretty good suspension bridges by  
learning the state of the art of bridge-building. After that, as long  
as I live, I run almost no risk of Newtonian mechanics being shown to  
be wrong for any value of wrong that would make me go well, wow, I no  
longer understand how to build bridges.


In other words, people who build bridges these days can give you a  
convincing presentation, based on solid physics and a highly-complete  
threat model (soil erosion, material failure, etc) that their bridge  
will do its job. They can say this bridge will work because it  
satisfies well-understood and reasonably immutable laws of nature.


People who attempt to build secure systems have no ultimately well- 
understood (let alone immutable!) requirements to design against. A  
good approximation is a secure system is one that survives all  
relevant attacks that people in our field have come up with thus far,  
but it's clear that a system successfully meeting that goal can simply  
cease to meet it any given day. Thus unlike with bridges, you  
fundamentally can't evaluate the quality of a security system you  
built if you're unfamiliar with the state of the art of _attacks_  
against security systems, and you can't become familiar with those  
unless you realize that these attacks have each brought down a system  
previously considered impregnable. And if by the time you've gone  
through dozens of broken systems and their corresponding attacks you  
still think you're smart enough to write a new system by yourself,  
you're either very brave or very daft.


Neither of those mean you're a bad person, but both mean you shouldn't  
be designing security systems.


--
Ivan Krstić [EMAIL PROTECTED] | http://radian.org

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


Re: Gutmann Soundwave Therapy

2008-02-06 Thread Leichter, Jerry
Commenting on just one portion:
| 2. VoIP over DTLS
| As Perry indicated in another message, you can certainly run VoIP
| over DTLS, which removes the buffering and retransmit issues 
| James is alluding to. Similarly, you could run VoIP over IPsec
| (AH/ESP). However, for performance reasons, this is not the favored
| approach inside IETF.
| 
| The relevant issue here is packet size. Say you're running a 
| low bandwidth codec like G.729 at 8 kbps. If you're operating at
| the commonly used 50 pps, then each packet is 160 bits == 20 bytes.
| The total overhead of the IP, UDP, and RTP headers is 40 bytes,
| so you're sending 60 byte packets. 
| 
| - If you use DTLS with AES in CBC mode, you have the 4 byte DTLS
|   header, plus a 16 byte IV, plus 10 bytes of MAC (in truncated MAC
|   mode), plus 2 bytes of padding to bring you up to the AES block
|   boundary: DTLS adds 32 bytes of overhead, increasing packet
|   size by over 50%. The IPsec situation is similar.
| 
| - If you use CTR mode and use the RTP header to form the initial
|   CTR state, you can remove all the overhead but the MAC itself,
|   reducing the overhead down to 10 bytes with only 17% packet
|   expansion (this is how SRTP works)
If efficiency is your goal - and realistically it has to be *a* goal -
then you need to think about the semantics of what you're securing.  By
the nature of VOIP, there's very little semantic content in any given
packet, and because VOIP by its nature is a real-time protocol, that
semantic content loses all value in a very short time.  Is it really
worth 17% overhead to provide this level of authentication for data that
isn't, in and of itself, so significant?  At least two alternative
approach suggest themselves:

- Truncate the MAC to, say, 4 bytes.  Yes, a simple brute
force attack lets one forge so short a MAC - but
is such an attack practically mountable in real
time by attackers who concern you?

- Even simpler, send only one MAC every second - i.e.,
every 50 packets, for the assumed parameters.
Yes, an attacker can insert a second's worth
of false audio - after which he's caught.  I
suppose one could come up with scenarios in
which that matters - but they are very specialized.
VOIP is for talking to human beings, and for
human beings in all but extraordinary circumstances
a second is a very short time.

  If you don't like 1 second, make this configurable.  Even
dropping it to 1/10 second and sticking to DTLS
(with a modification, of course) drops your overhead
to 5% - and 1/10 second isn't even enough time to
insert a no into the stream.  For many purposes,
a value of 10 seconds - which reduces the overhead to
an insignificant level - is probably acceptable.

It's great to build generic encrypted tunnels that provide strong
security guarantees regardless of what you send through them - just as
it's great to provide generic stream protocols like TCP that don't care
what you use them for.  The whole point of this discussion has been
that, in some cases, the generic protocols aren't really what you need:
They don't provide quite the guarantees you need, and they impose
overhead that may be unacceptable in some cases.  The same argument
applies to cryptographic algorithms.  Yes, there is a greater danger if
cryptographic algorithms are misused:  Using TCP where it's inappropri-
ate *usually* just screws up your performance, while an inappropriate
cryptographic primitive may compromise your security.  Of course, if you
rely on TCP's reliablity in an inappropriate way, you can also get
into serious trouble - but that's more subtle and rare.  Then again,
actually mounting real attacks against some of the cryptographic
weaknesses we sometimes worry about is also pretty subtle and rare.

The NSA quote someone - Steve Bellovin? - has repeated comes to mind:
Amateurs talk about algorithms.  Professionals talk about economics.
Using DTLS for VOIP provides you with an extremely high level of
security, but costs you 50% packet overhead.  Is that worth it to you?
It really depends - and making an intelligent choice requires that
various alternatives along the cost/safety curve actually be available.

-- Jerry

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


Re: Gutmann Soundwave Therapy

2008-02-06 Thread Eric Rescorla
At Mon, 4 Feb 2008 09:33:37 -0500 (EST),
Leichter, Jerry wrote:
 
 Commenting on just one portion:
 | 2. VoIP over DTLS
 | As Perry indicated in another message, you can certainly run VoIP
 | over DTLS, which removes the buffering and retransmit issues 
 | James is alluding to. Similarly, you could run VoIP over IPsec
 | (AH/ESP). However, for performance reasons, this is not the favored
 | approach inside IETF.
 | 
 | The relevant issue here is packet size. Say you're running a 
 | low bandwidth codec like G.729 at 8 kbps. If you're operating at
 | the commonly used 50 pps, then each packet is 160 bits == 20 bytes.
 | The total overhead of the IP, UDP, and RTP headers is 40 bytes,
 | so you're sending 60 byte packets. 
 | 
 | - If you use DTLS with AES in CBC mode, you have the 4 byte DTLS
 |   header, plus a 16 byte IV, plus 10 bytes of MAC (in truncated MAC
 |   mode), plus 2 bytes of padding to bring you up to the AES block
 |   boundary: DTLS adds 32 bytes of overhead, increasing packet
 |   size by over 50%. The IPsec situation is similar.
 | 
 | - If you use CTR mode and use the RTP header to form the initial
 |   CTR state, you can remove all the overhead but the MAC itself,
 |   reducing the overhead down to 10 bytes with only 17% packet
 |   expansion (this is how SRTP works)
 If efficiency is your goal - and realistically it has to be *a* goal -
 then you need to think about the semantics of what you're securing.  By
 the nature of VOIP, there's very little semantic content in any given
 packet, and because VOIP by its nature is a real-time protocol, that
 semantic content loses all value in a very short time.  Is it really
 worth 17% overhead to provide this level of authentication for data that
 isn't, in and of itself, so significant?  At least two alternative
 approach suggest themselves:

   - Truncate the MAC to, say, 4 bytes.  Yes, a simple brute
   force attack lets one forge so short a MAC - but
   is such an attack practically mountable in real
   time by attackers who concern you?

In fact, 32-bit authentication tags are a feature of
SRTP (RFC 3711). 



   - Even simpler, send only one MAC every second - i.e.,
   every 50 packets, for the assumed parameters.
   Yes, an attacker can insert a second's worth
   of false audio - after which he's caught.  I
   suppose one could come up with scenarios in
   which that matters - but they are very specialized.
   VOIP is for talking to human beings, and for
   human beings in all but extraordinary circumstances
   a second is a very short time.

Not sending a MAC on every packet has difficult interactions with
packet loss. If you do the naive thing and every N packets send a MAC
covering the previous N packets, then if you lose even one of those
packets you can't verify the MAC. But since some packet loss is
normal, an attacker can cover their tracks simply by removing one out
of every N packets.

Since (by definition) you don't have a copy of the packet you've lost,
you need a MAC that survives that--and is still compact. This makes
life rather more complicated. I'm not up on the most recent lossy
MACing literature, but I'm unaware of any computationally efficient
technique which has a MAC of the same size with a similar security
level. (There's an inefficient technique of having the MAC cover
all 2^50 combinations of packet loss, but that's both prohibitively
expensive and loses you significant security.)


 The NSA quote someone - Steve Bellovin? - has repeated comes to mind:
 Amateurs talk about algorithms.  Professionals talk about economics.
 Using DTLS for VOIP provides you with an extremely high level of
 security, but costs you 50% packet overhead.  Is that worth it to you?
 It really depends - and making an intelligent choice requires that
 various alternatives along the cost/safety curve actually be available.

Which there are, as indicated above and in my previous message. 

-Ekr



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


Re: Gutmann Soundwave Therapy

2008-02-06 Thread Martin James Cochran

Comments inline.

On Feb 3, 2008, at 5:56 PM, Eric Rescorla wrote:



- If you use DTLS with AES in CBC mode, you have the 4 byte DTLS
header, plus a 16 byte IV, plus 10 bytes of MAC (in truncated MAC
mode), plus 2 bytes of padding to bring you up to the AES block
boundary: DTLS adds 32 bytes of overhead, increasing packet
size by over 50%. The IPsec situation is similar.

- If you use CTR mode and use the RTP header to form the initial
CTR state, you can remove all the overhead but the MAC itself,
reducing the overhead down to 10 bytes with only 17% packet
expansion (this is how SRTP works)



Depending on the lifetime of the keys involved, you can probably  
truncate the MAC tags much more than this.  Using the RTP counter for  
use in some appropriate stateful MAC may mean a 3- or 4-byte tag is  
enough security.  Additionally, in order to conserve bandwidth you  
might want to make a trade-off where some packets may be forged with  
small probability (in the VOIP case, that means an attacker gets to  
select a fraction of a second of sound, which is probably harmless),  
but it is hard to forge many packets.


In (http://eprint.iacr.org/2006/095), John Black and I treat this  
model in depth, and suggest a MAC scheme which may be most appropriate  
for this scenario.  A stateful, highly-truncated HMAC will also work  
fine, but is slower than the scheme we propose.


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


Re: Gutmann Soundwave Therapy

2008-02-06 Thread Steven M. Bellovin
On Mon, 4 Feb 2008 09:33:37 -0500 (EST)
Leichter, Jerry [EMAIL PROTECTED] wrote:

 The NSA quote someone - Steve Bellovin? - has repeated comes to mind:
 Amateurs talk about algorithms.  Professionals talk about economics.
 Using DTLS for VOIP provides you with an extremely high level of
 security, but costs you 50% packet overhead.  Is that worth it to you?
 It really depends - and making an intelligent choice requires that
 various alternatives along the cost/safety curve actually be
 available.

Precisely.

Some years ago, I did a crypto design for a potential product.  As best
we could figure it, the extra overhead for a standard mechanism versus
a custom one was greater than the profit margin for this product.


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

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


Re: Gutmann Soundwave Therapy

2008-02-06 Thread Eric Rescorla
At Mon, 04 Feb 2008 14:29:50 +1000,
James A. Donald wrote:
 
 James A. Donald wrote:
   I have figured out a solution, which I may post here
   if you are interested.
 
 Ian G wrote:
   I'm interested.  FTR, zooko and I worked on part of
   the problem, documented briefly here:
   http://www.webfunds.org/guide/sdp/index.html
 
 I have posted How to do VPNs right at
 http://jim.com/security/how_to_do_VPNs.html
 
 It covers somewhat different ground to that which your
 page covers, focusing primarily on the problem of
 establishing the connection.
 
   humans are not going to carry around large
   strong secrets every time either end of the
   connection restarts.  In fact they are not going
   to transport large strong secrets any time ever,
   which is the flaw in SSL and its successors such
   as IPSec and DTLS

This paragraph sure is confused.

1. IPsec most certainly is not a successor to SSL. On
   the contrary, IPsec predates SSL.

2. TLS doesn't require you to carry around strong secrets.
   I refer you to TLS-SRP [RFC 5054]

3. For that matter, even if you ignore SRP, TLS supports
   usage models which never require you to carry around
   strong secrets: you preconfigure the server's public
   key and send a password over the TLS channel. Since
   this is the interface SSH uses, the claim that humans
   won't do it is manifestly untrue.


-Ekr

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


Re: Gutmann Soundwave Therapy

2008-02-06 Thread Bill Frantz
[EMAIL PROTECTED] (Peter Gutmann) on Monday, February 4, 2008 wrote:

Eric Rescorla [EMAIL PROTECTED] writes:

I don't propose to get into an extended debate about whether it is better to
use SRTP or to use generic DTLS. That debate has already happened in IETF and
SRTP is what the VoIP vendors are doing. However, the good news here is that
you can use DTLS to key SRTP (draft-ietf-avt-dtls-srtp), so there's no need
to invent a new key management scheme.

Hmm, given this X-to-key-Y pattern (your DTLS-for-SRTP example, as well as
OpenVPN using ESP with TLS keying), I wonder if it's worth unbundling the key
exchange from the transport?  At the moment there's (at least):

  TLS-keying --+-- TLS transport
   |
   +-- DTLS transport
   |
   +-- IPsec (ESP) transport
   |
   +-- SRTP transport
   |
   +-- Heck, SSH transport if you really want

Is the TLS handshake the universal impedance-matcher of secure-session
mechanisms?

If there had been a separation between the key exchange and
validation part of SSL (early TLS) and the transport part, the E
language protocol[1] almost certainly would have used the transport
part of the protocol.  The reasons at the time for not using SSL are
described in [2].  They are all associated with the connection and
cryptograph setup.

Simplified overview:

When an E program needs to contact a remote E program, it starts
with a hash of the other program's public key and large random
number, the Swiss number.  It gets the IP and port of the remote
program from a well-known network service called the Process Location
Service.  It then contacts that IP and port, sends its public key,
receives the remote public key, performs a Diffie Hellman exchange
for forward secrecy, checks the hash of the remote public key, and
sends a signature over the exchange.  It checks the remote programs
signature over the exchange, and if all the checks pass, sends the
encrypted Swiss number to identify the specific remote resource.

I couldn't see any way to take this self-authenticating key exchange
and jam it into a x.509 structure.  Perhaps I wasn't inventive
enough, but I ended up rolling my own transport protocol, at certain
extra cost in development and testing, and a significant risk of
security errors.

Cheers - Bill

[1] http://www.erights.org/elib/distrib/vattp/index.html

[2] http://www.erights.org/elib/distrib/vattp/SSLvsDataComm.html

---
Bill Frantz| gets() remains as a monument | Periwinkle
(408)356-8506  | to C's continuing support of | 16345 Englewood Ave
www.pwpconsult.com | buffer overruns. | Los Gatos, CA 95032

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


Re: Gutmann Soundwave Therapy

2008-02-03 Thread James A. Donald

--
Ivan Krstic' wrote:
 The wider point of Peter's writeup -- and of the
 therapy -- is that developers working on security
 tools should _know_ they're working in a notoriously,
 infamously hard field where the odds are
 _overwhelmingly_ against them if they choose to
 engineer new solutions.

That point is of course true.  But the developers wanted
to transport IP and UDP.  Peter should have known that
SSL is incapable of transporting IP and UDP, because it
will introduce large, unpredictable, and variable
delays.

If, for example, VOIP goes over SSL, the speakers would
become entirely unintelligible.

So yes, the developers were incompetent in that they
badly underestimated the difficulty of the task.  And
Peter was incompetent in thinking that one layer of a
solution for a particular problem can be plucked out of
that environment, an environment where it works very
badly, and plonked into another, very different,
environment.

Not only do new solutions generally not work, but
existing solutions generally work badly, and are
commonly inapplicable outside their particular special
environment.

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


Re: Gutmann Soundwave Therapy

2008-02-03 Thread Eric Rescorla
At Sun, 03 Feb 2008 12:51:25 +1000,
James A. Donald wrote:
 
  --
 Ivan Krstic' wrote:
   The wider point of Peter's writeup -- and of the
   therapy -- is that developers working on security
   tools should _know_ they're working in a notoriously,
   infamously hard field where the odds are
   _overwhelmingly_ against them if they choose to
   engineer new solutions.
 
 That point is of course true.  But the developers wanted
 to transport IP and UDP.  Peter should have known that
 SSL is incapable of transporting IP and UDP, because it
 will introduce large, unpredictable, and variable
 delays.
 
 If, for example, VOIP goes over SSL, the speakers would
 become entirely unintelligible.

For those who haven't already made up their minds, the situation with
VoIP and TCP (SSL doesn't really change the situation) is actually a
bit more complicated than this.

1. VoIP over TCP
If you have a reasonably fast loss-free channel (this isn't that
uncommon) then it doesn't actually make an enormous amount of
difference whether you're running TCP or UDP, especially if you're
running a high-bandwidth codec like G.711. It helps to turn off the
Nagle algorithm, of course, since it reduces the amount of buffering
in the sending TCP stack.

That said, any significant amount of packet loss does tend to create
some pretty significant artifacts, since you need to stall the
receiving TCP while you wait for the retransmit.  So, as a practical
matter nearly all interactive VoIP systems use UDP and some kind of
packet loss concealment (interpolation, etc.).

That's not to say that SSL/TLS is totally innocent here. The designers
of SSL/TLS *could* have chosen to design a protocol which would work
over datagram transport as well as stream transport, but they didn't.
DTLS (RFC 4347) is such a protocol. That said, if you compare DTLS to
TLS, there is a small amount of additional complexity in DTLS, so it's
arguable that it was a good design choice to go for the sweet spot of
stream transport, since that's what SSL was really intended for.


2. VoIP over DTLS
As Perry indicated in another message, you can certainly run VoIP
over DTLS, which removes the buffering and retransmit issues 
James is alluding to. Similarly, you could run VoIP over IPsec
(AH/ESP). However, for performance reasons, this is not the favored
approach inside IETF.

The relevant issue here is packet size. Say you're running a 
low bandwidth codec like G.729 at 8 kbps. If you're operating at
the commonly used 50 pps, then each packet is 160 bits == 20 bytes.
The total overhead of the IP, UDP, and RTP headers is 40 bytes,
so you're sending 60 byte packets. 

- If you use DTLS with AES in CBC mode, you have the 4 byte DTLS
  header, plus a 16 byte IV, plus 10 bytes of MAC (in truncated MAC
  mode), plus 2 bytes of padding to bring you up to the AES block
  boundary: DTLS adds 32 bytes of overhead, increasing packet
  size by over 50%. The IPsec situation is similar.

- If you use CTR mode and use the RTP header to form the initial
  CTR state, you can remove all the overhead but the MAC itself,
  reducing the overhead down to 10 bytes with only 17% packet
  expansion (this is how SRTP works)

Note that some (but not all) of the gain from SRTP can be obtained
by swapping CTR for CBC. But you're still getting an advantage
from being willing to overload the RTP header and that's harder
to optimize out (though Nagendra Modadugu and I spent some time
thinking about this).

I don't propose to get into an extended debate about whether it is
better to use SRTP or to use generic DTLS. That debate has already
happened in IETF and SRTP is what the VoIP vendors are doing. However,
the good news here is that you can use DTLS to key SRTP
(draft-ietf-avt-dtls-srtp), so there's no need to invent a new
key management scheme.

-Ekr















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


Re: Gutmann Soundwave Therapy

2008-02-01 Thread Perry E. Metzger

Sandy Harris [EMAIL PROTECTED] writes:
 What I don't understand is why you think tinc is necessary,
 or even worth the trouble.

 IPsec is readily available -- built into Windows, Mac OS
 and various routers, and with implementations for Linux
 and all the *BSDs -- has had quite a bit of expert
 security analysis, and handles VPNs just fine.

 Does tinc do something that IPsec cannot?

I use a VPN system other than IPSec on a regular basis. The reason is
simple: it is easy to configure for my application and my OS native
IPsec tools are very difficult to configure.

There is a lesson in this, I think.

Perry

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


Re: Gutmann Soundwave Therapy

2008-02-01 Thread James A. Donald

Guus Sliepen wrote:

Peter's write-up was the reason I subscribed to this cryptography
mailing list. After a while the anger/hurt feelings I had disappeared.
I knew then that Peter was right in his arguments. Nowadays I can look
at Peter's write-up more objectively and I can see that it is not as
ad-hominem as it felt back then, although the whole soundwave paragraph
still sounds very childish ;)

When tinc 2.0 will ever come out (unfortunately I don't have a lot of
time to work on it these days), it will probably use the GnuTLS library
and authenticate and connect daemons with TLS. For performance reasons,
you want to tunnel network packets via UDP instead of TCP, so hopefully
there is a working DTLS implementation as well then.


I have been considering the problem of encrypted channels over UDP or 
IP.  TLS will not work for this, since it assumes and provides a 
reliable, and therefore non timely channel, whereas what one wishes to 
provide is a channel where timeliness may be required at the expense of 
reliability.


I have figured out a solution, which I may post here if you are interested.

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


Re: Gutmann Soundwave Therapy

2008-02-01 Thread Richard Salz
 The wider point of Peter's writeup -- and of the therapy -- is that 
 developers working on security tools should _know_ they're working in 
 a notoriously, infamously hard field where the odds are 
 _overwhelmingly_ against them if they choose to engineer new solutions.

Developers working in almost any field should know the history and best 
practices -- is PGP's original bass o matic any more important than the 
code in a defibrillator? -- but this is not the way our field works right 
now.  Compare it to something like civil engineering or architecture.

Until we get to that point -- and we may never got there, nor want to -- 
it is probably better to act as mentors than, say, pricks. :)  I thought 
Peter's soundwave idea was kinda funny, and hopefully lessened the sting. 
Guus's note should recommended reading on a regular basis.

If we want to spread the use of crypto, perhaps we should be nicer to 
those who are also trying to do the same thing albeit poorly.

/r$

--
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/

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


Re: Gutmann Soundwave Therapy

2008-02-01 Thread Sandy Harris
What I don't understand is why you think tinc is necessary,
or even worth the trouble.

IPsec is readily available -- built into Windows, Mac OS
and various routers, and with implementations for Linux
and all the *BSDs -- has had quite a bit of expert
security analysis, and handles VPNs just fine.

Does tinc do something that IPsec cannot?

-- 
Sandy Harris,
Nanjing, China

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


Re: Gutmann Soundwave Therapy

2008-02-01 Thread Eric Rescorla
At Fri, 01 Feb 2008 18:42:03 +1000,
James A. Donald wrote:
 
 Guus Sliepen wrote:
  Peter's write-up was the reason I subscribed to this cryptography
  mailing list. After a while the anger/hurt feelings I had disappeared.
  I knew then that Peter was right in his arguments. Nowadays I can look
  at Peter's write-up more objectively and I can see that it is not as
  ad-hominem as it felt back then, although the whole soundwave paragraph
  still sounds very childish ;)
  
  When tinc 2.0 will ever come out (unfortunately I don't have a lot of
  time to work on it these days), it will probably use the GnuTLS library
  and authenticate and connect daemons with TLS. For performance reasons,
  you want to tunnel network packets via UDP instead of TCP, so hopefully
  there is a working DTLS implementation as well then.
 
 I have been considering the problem of encrypted channels over UDP or 
 IP.  TLS will not work for this, since it assumes and provides a 
 reliable, and therefore non timely channel, whereas what one wishes to 
 provide is a channel where timeliness may be required at the expense of 
 reliability.

DTLS: RFC 4347.

-Ekr

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


Re: Gutmann Soundwave Therapy

2008-02-01 Thread Perry E. Metzger

James A. Donald [EMAIL PROTECTED] writes:
 When tinc 2.0 will ever come out (unfortunately I don't have a lot of
 time to work on it these days), it will probably use the GnuTLS library
 and authenticate and connect daemons with TLS. For performance reasons,
 you want to tunnel network packets via UDP instead of TCP, so hopefully
 there is a working DTLS implementation as well then.

 I have been considering the problem of encrypted channels over UDP or
 IP.  TLS will not work for this, since it assumes and provides a
 reliable, and therefore non timely channel, whereas what one wishes to
 provide is a channel where timeliness may be required at the expense
 of reliability.

DTLS does not assume a reliable channel -- it is designed for
applications that use UDP. Perhaps you are not familiar with it.

 I have figured out a solution, which I may post here if you are interested.

With respect, James, I think they'd be better off using DTLS. It was
designed by experts and it shares the same security properties as TLS.


-- 
Perry E. Metzger[EMAIL PROTECTED]

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


Re: Gutmann Soundwave Therapy

2008-02-01 Thread Thor Lancelot Simon
On Thu, Jan 31, 2008 at 04:07:03PM +0100, Guus Sliepen wrote:
 
 Peter sent us his write-up up via private email a few days before he
 posted it to this list (which got it on Slashdot). I had little time to
 think about the issues he mentioned before his write-up became public.
 When it did, I (and others too) felt attacked in a cruel way. Peter
 ignored all the reasons *why* we used the kind of crypto we did at
 that moment, compared it to a very high standard, and made it feel like
 every thing we didn't do or didn't do as well as SSL made our crypto
 worthless. 

There is no valid reason to ship snake oil cryptography (at any moment).

There is no standard but a high standard which is appropriate for
comparison.

Since SSL was already available, there was no excuse to do anything
worse.

It seems that you still don't understand those things, or you would not
complain about them even at this far removed date.  How unfortunate.

Thor

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


Re: Gutmann Soundwave Therapy

2008-02-01 Thread Guus Sliepen
On Thu, Jan 31, 2008 at 03:46:47PM -0500, Thor Lancelot Simon wrote:

 On Thu, Jan 31, 2008 at 04:07:03PM +0100, Guus Sliepen wrote:
  
  Peter sent us his write-up up via private email a few days before he
  posted it to this list (which got it on Slashdot). I had little time to
  think about the issues he mentioned before his write-up became public.
  When it did, I (and others too) felt attacked in a cruel way. Peter
  ignored all the reasons *why* we used the kind of crypto we did at
  that moment, compared it to a very high standard, and made it feel like
  every thing we didn't do or didn't do as well as SSL made our crypto
  worthless. 
 
 There is no valid reason to ship snake oil cryptography (at any moment).
 
 There is no standard but a high standard which is appropriate for
 comparison.
 
 Since SSL was already available, there was no excuse to do anything
 worse.

Please understand the following:

I am not defending the use of our less-than-SSL crypto in tinc. But
there are reasons why we implemented it the way we did at that time. It
doesn't matter whether these reasons were bad or good. The result of
ignoring the why, and attacking others by pointing out everything they
do wrong in your perspective (even though your perspective is perfectly
right), and then finishing off the way Peter did, which is easily
perceived as an insult if you are on the receiving end of it, does not
encourage others to fix the problems, but rather puts others in
defensive mode.

Are you out to help others, or just to look down on them? If it's the
first, then please make others accept your help by just formulating
things in a more friendly way (although a patch with a fix would soften
up things as well). If it's the latter, please continue just as you are
doing now.

Now some (good and/or bad) reasons why we ended up with our
lesser-than-SSL crypto, in no particular order:

- SSL was not perceived at that time as a solution for our problem.
- We were application writers, not security specialists. We had to
  encrypt traffic, we did the best to our knowledge at that time.
- I had read Schneier's Applied Cryptography from front to end a few
  times. It made me feel I knew everything about crypto. Even Bruce
  admits he thought at that time he had put everything a programmer
  needed to know about crypto in that book. It doesn't mention SSL.
- We needed to tunnel data over UDP, with UDP semantics. SSL requires a
  reliable stream. Therefore, we had to use something other that SSL to
  tunnel data.
- It was fun to come up with a full duplex authentication scheme using
  RSA. More fun than using someone elses stuff.
- Because we could.
- We were Free Software developers who did it in our spare time for fun,
  we were not a company that sells it as one of its products.

 It seems that you still don't understand those things, or you would not
 complain about them even at this far removed date.  How unfortunate.

It seems that you haven't read the rest of my email, or you would not
have written that sentence. I am enlightened now :)

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen [EMAIL PROTECTED]


signature.asc
Description: Digital signature


Re: Gutmann Soundwave Therapy

2008-02-01 Thread Ian G

James A. Donald wrote:

I have been considering the problem of encrypted channels over UDP or 
IP.  TLS will not work for this, since it assumes and provides a 
reliable, and therefore non timely channel, whereas what one wishes to 
provide is a channel where timeliness may be required at the expense of 
reliability.



This is what Guus was getting at:


- We needed to tunnel data over UDP, with UDP semantics.
  SSL requires a reliable stream. Therefore, we had to
  use something other that SSL to tunnel data.


To put it in more fundamental terms, TLS assumes that what 
you want is a stream.  If you want packets, then TLS is a 
millstone around your neck.  It's not that it can't deliver 
packets, but that it forces all your application to think in 
stream-mode, which results in messes up and down the stack 
(including the human).


The vast majority of applications are not pure stream.  The 
vast majority are not pure packet, either ... so they are 
all somewhere in between.


The selection of where your app is on the spectrum and what 
tools you need is the job of the protocol architect; 
unfortunately, the prevailing wisdom is that as we only have 
a widely deployed stream protocol (TLS) then that should be 
used for everything.  This has resulted in some easy wins 
and some intractable messes as well the current thread 
(repeated into the past and will be repeated into the future).


Advising TLS for a packet delivery requirement is simply 
wrong.  You might be wise to give that advice, if you 
can show some other factors, but that requires ... more 
subtlety than simply repeating that TLS has to be used for 
everything.




I have figured out a solution, which I may post here if you are interested.



I'm interested.  FTR, zooko and I worked on part of the 
problem, documented briefly here: 
http://www.webfunds.org/guide/sdp/index.html


I've successfully got that going in 3 UDP transport 
scenarios, with different key exchange scenarios and 
languages.  (I was never able to deploy it tho, for business 
reasons.)  For the most part, the requirements include no 
relationship between packets, but an expectation of a return 
path  ... a.k.a. connections, but without the streaming 
assumption ... which means having to relearn how to do 
context over UDP.


One can compare that approach to the DTLS, which has the 
benefit of leveraging SSL technology and history.  My 
impression was that it assumed too much of the nature of SSL 
at the core, so it didn't cover enough of the territory to 
satisfy me.  But if it becomes widely deployed, that may be 
the better bet than designing another one or a home-brew. 
Deployment counts over elegance, most times.


iang

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


Re: Gutmann Soundwave Therapy

2008-02-01 Thread Nicolas Williams
On Fri, Feb 01, 2008 at 09:24:10AM -0500, Perry E. Metzger wrote:
  Does tinc do something that IPsec cannot?
 
 I use a VPN system other than IPSec on a regular basis. The reason is
 simple: it is easy to configure for my application and my OS native
 IPsec tools are very difficult to configure.
 
 There is a lesson in this, I think.

I agree wholeheartedly.  I'm trying to fix this too.  But for web stuff,
IPsec won't have a chance for a long time, maybe never.

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


Re: Gutmann Soundwave Therapy

2008-02-01 Thread Perry E. Metzger

Ian G [EMAIL PROTECTED] writes:
 This is what Guus was getting at:


 - We needed to tunnel data over UDP, with UDP semantics.
   SSL requires a reliable stream. Therefore, we had to
   use something other that SSL to tunnel data.

The version of SSL (which is officially called TLS) that does this is
called DTLS. It has already existed for some time now.

 To put it in more fundamental terms, TLS assumes that what you want is
 a stream.  If you want packets, then TLS is a millstone around your
 neck.

That's why you use Datagram TLS, aka TLS if your app needs UDP
instead of TCP.

If you want to learn more about DTLS, this Wikipedia page:
http://en.wikipedia.org/wiki/DTLS
points at the RFC, which is here:
http://tools.ietf.org/html/rfc4347

OpenSSL has had DTLS support for a while, so there is unencumbered
code for you to roll into your app for the purpose any time you like.

 Advising TLS for a packet delivery requirement is simply wrong.

DTLS is there for packet delivery.


-- 
Perry E. Metzger[EMAIL PROTECTED]

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


Re: Gutmann Soundwave Therapy

2008-01-31 Thread Hayden Stainsby


On 30 Jan 2008, at 04:26, Perry E. Metzger wrote:



Clearly, more people need to know about Gutmann Soundwave Therapy.



To this end, I would like to introduce the Gutmann Sound Wave Therapy  
Mobile Enlightenment Unit.

http://occasionallyhuman.net/gutmann/
(NSFW if depictions of phallic audio waves are an issue)


Do you know a programmer who believes they can write a replacement for  
SSL in the time it takes to finish their coffee?


Tell tale signs are phrases such as 'proprietary crypto' and 'secret  
algorithm'.


Simply apply the Gutmann Sound Wave Therapy Mobile Enlightenment Unit,  
stand back, wait and breath a sigh of relief - you've just made the  
world a better place.



I'll begin taking pre-orders shortly.

--
Hayden

PS: I don't care that the audio wave can't be produced. It's 'artistic'.


#!/usr/bin/perl
chop($_=);@s=split/ /;foreach$m(@s){if($m=='*')[EMAIL PROTECTED];$x=
[EMAIL PROTECTED];$a=eval$x$m$z;[EMAIL PROTECTED],$a;[EMAIL 
PROTECTED],$m;}}print$a\n;
# http://occasionallyhuman.net/


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


Re: Gutmann Soundwave Therapy

2008-01-31 Thread Guus Sliepen
On Tue, Jan 29, 2008 at 12:26:21PM -0500, Perry E. Metzger wrote:

 Clearly, more people need to know about Gutmann Soundwave Therapy.
 
 Ivan Krstić [EMAIL PROTECTED] writes:
[...]
  [0] Last paragraph, http://diswww.mit.edu/bloom-picayune/crypto/14238
 
 As it turns out, the central image of Peter's post was popularized
 earlier*.
 
 However, Peter clearly said this first in a security context, and I
 hope that the term Gutmann Soundwave Therapy spreads widely within
 our field as a way of ridiculing the desire to invent your own crypto
 algorithms and protocols. When it gets to the point where salesmen are
 vaguely aware of the phrase and fear it, we will know we have done our
 job successfully.

As one of the main developers of tinc, I have been at the receiving end
of Gutmann's therapy, or drive-by shooting as I experienced it at that
time.

Peter sent us his write-up up via private email a few days before he
posted it to this list (which got it on Slashdot). I had little time to
think about the issues he mentioned before his write-up became public.
When it did, I (and others too) felt attacked in a cruel way. Peter
ignored all the reasons *why* we used the kind of crypto we did at
that moment, compared it to a very high standard, and made it feel like
every thing we didn't do or didn't do as well as SSL made our crypto
worthless. 

We had some other people sending us security reviews of tinc, Jerome
Etienne for example. With them, we never had that feeling of being
attacked. The conversations we had with them encouraged us to improve
tinc.

Peter's write-up was the reason I subscribed to this cryptography
mailing list. After a while the anger/hurt feelings I had disappeared.
I knew then that Peter was right in his arguments. Nowadays I can look
at Peter's write-up more objectively and I can see that it is not as
ad-hominem as it felt back then, although the whole soundwave paragraph
still sounds very childish ;)

When tinc 2.0 will ever come out (unfortunately I don't have a lot of
time to work on it these days), it will probably use the GnuTLS library
and authenticate and connect daemons with TLS. For performance reasons,
you want to tunnel network packets via UDP instead of TCP, so hopefully
there is a working DTLS implementation as well then.

I hope that in the future, if you see an application doing something
wrong, you don't immediately give the developers the soundwave therapy.
Be a little bit more gentle and try to find out why it was written that
way in the first place. It will create a lot more understanding and
willingness from the developers to fix the problems.

Also, from experimenting with a version of tinc that uses TLS, I can
tell you that it not the perfect solution for our problem. The main
issue I see with SSL and TLS is with the credentials. Both X.509 and
OpenPGP are focussed on URLs or email addresses. It is not clear to me
how to store other information (like which subnets a node on the VPN is
authorised to use) in such credentials in a nice way, other than
shoehorning it into a CN (X.509) or uid (OpenPGP) field. Certificate
chain verification is something that often goes wrong; some SSL libraries do
not offer that functionality, or only do it when an application
explicitly requests it. With OpenPGP you can have a web of trust, but
how do you make use of it in an automated way? I expect that the next
round of penis-shaped soundwave therapy will not be focussed on
whether or not an application uses SSL, but on how it (mis)uses SSL.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen [EMAIL PROTECTED]


signature.asc
Description: Digital signature


Re: Gutmann Soundwave Therapy

2008-01-31 Thread Ivan Krstić

On Jan 31, 2008, at 4:07 PM, Guus Sliepen wrote:

I hope that in the future, if you see an application doing something
wrong, you don't immediately give the developers the soundwave  
therapy.



The wider point of Peter's writeup -- and of the therapy -- is that  
developers working on security tools should _know_ they're working in  
a notoriously, infamously hard field where the odds are  
_overwhelmingly_ against them if they choose to engineer new solutions.


With such understanding, no competent developer should ever set out to  
build new cryptosystems unless he can explain, point by point, why his  
needs cannot be met by existing, vetted systems. That explanation  
should ideally be made public for dissection by the community.


--
Ivan Krstić [EMAIL PROTECTED] | http://radian.org

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