Re: Gutmann Soundwave Therapy
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
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
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
| - 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
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
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
| 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
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
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
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
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
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
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
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
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
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
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
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
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
[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
-- 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
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
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
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
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
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
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
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
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
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
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
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
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
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]
