Re: TLS vs. IPsec (Was: Re: experiments in the ietf week)
At Wed, 26 Mar 2008 07:32:41 -0700, Eric Rescorla wrote: > > At Wed, 26 Mar 2008 15:01:21 +0100, > Iljitsch van Beijnum wrote: > > > > On 26 mrt 2008, at 14:36, Eric Rescorla wrote: > > > > > - Modern cryptographic implementations are extremely fast. For > > > comparison the MacBook Air I'm typing this on will do order 10^6 > > > HMAC-MD5s/second on 64-byte packets. So, to consume all my > > > resources would require order 10^8 bits per second, which is a > > > pretty serious packet-based DoS ittack on many contexts. > > > > This is a bogus argument. Implementations are always inferior to > > optimistic performance claims > > What do you mean "optimistic performance claims"? I ran > "openssl speed". That's actually a pretty good reflection > of what the performance of SSL implementation will be. That said, there is a dependency on cipher suite. So, RC4-MD5 is not too much slower than HMAC-MD5 alone. By contrast, AES-SHA1 is maybe 4x slower. OTOH, I only was counting the size of the TLS records themselves, so when you add the TCP and UDP headers, the bit rate is probably twice as high. -Ekr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TLS vs. IPsec (Was: Re: experiments in the ietf week)
At Wed, 26 Mar 2008 15:01:21 +0100, Iljitsch van Beijnum wrote: > > On 26 mrt 2008, at 14:36, Eric Rescorla wrote: > > > - Modern cryptographic implementations are extremely fast. For > > comparison the MacBook Air I'm typing this on will do order 10^6 > > HMAC-MD5s/second on 64-byte packets. So, to consume all my > > resources would require order 10^8 bits per second, which is a > > pretty serious packet-based DoS ittack on many contexts. > > This is a bogus argument. Implementations are always inferior to > optimistic performance claims What do you mean "optimistic performance claims"? I ran "openssl speed". That's actually a pretty good reflection of what the performance of SSL implementation will be. > and although maybe your laptop CAN do > that that doesn't mean you WANT it to spend its cycles and battery > power on that. (Or maybe you do, but I certainly don't.) No, I don't, but once again you're totally missing the point: the amount of bandwidth you'd need to perform a computational DoS attack on the symmetric part of the system is so high that it's basically a bandwidth-based DoS in itself. > > - Even mounting this attack requires knowing both host/port > > quartets. With DTLS, as with TLS, the responder/server's > > port is typically known whereas the initiator/client's port > > is random or pseudorandom. This creates some barrier to > > mounting this attack. > > The DTLS design to reuse the port numbers is not unreasonable as long > as DoS against CPU resources isn't a concern. But not using random > sequence numbers, like TCP has been doing since the dawn of time, is a > serious oversight because it costs next to nothing and buys a lot of > protection against spoofing attacks. 1. TCP has *not* used random sequence numbers since the dawn of time. On the contrary, they have been historically extremely predictable, hence RFC 1948 (though of course the techniques predate it.) And the reason that it now uses random sequence numbers is to block attacks much more severe than the ones you're describing here. 2. You're using the term "spoofing" in a way that's misleading. DTLS packets injected into the network by an attacker who does not have possession of the keying materal are quite correctly rejected by the DTLS stack. It's just that they are cryptographically verified first without being rejected out of hand. 3. As you say, it *is* cheap, but in keeping with our general principle of not improving TLS but just making it datagram capable, we decided to stick with TLS's 0-based sequence numbers. Not to put too fine a point on it, I think this proposed attack s basically irrelevant. I have not heard of any situation in which anyone has mounted DoS attacks on machines by forcing them to repeatedly perform cryptographic packet verifications (most likely since it's so lame) and in the unlikely case that that were to happen, we could always quickly roll out an extension to randomize the sequence numbers. > > - A very similar attack is available on IKE (and DTLS, of > > course). In order to block DoS attacks, both handshakes > > offer the option of doing a "stateless cookie" exchange, > > in which the responder gives the initiator a token which > > can be used to verify the client's next message (which must > > of course contain the token). But the way these tokens are > > generates is to have the responder compute a cryptographic > > MAC/hash over some input data. So an attacker can force > > any random IKE or DTLS stack to do as many digest operations > > as it wants. > > That doesn't make sense. For such a cookie to provide additional > benefit over the normal HMAC, the value in the next message must be > present in that next message in the clear so the number of crypto > operations required is equal to the number of valid packets, which > isn't under the control of an attacker, rather than the total number > of packets (like a HMAC), which can be inflated by an attacker. You might want to refamiliarize yourself with how these systems actually work. Let's take IKE as an example (though the situation is the same in DTLS). Here's the initial exchange from RFC 4306 S 2.6.: Initiator Responder ------ HDR(A,0), SAi1, KEi, Ni --> <-- HDR(A,0), N(COOKIE) HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ] So, whenever the responder gets *any* initial packet from a plausible counterparty (and this is clearly in control of the attacker), it has to compute a cookie. And how is that done? Scrolling further down S 2.6, we get some advice. A good way to do this is to set the responder cookie to be: Cookie = | Hash(Ni | IPi | SPIi | ) So, precisely as I said, an attacker can force the responder to compute as many hashes
Re: TLS vs. IPsec (Was: Re: experiments in the ietf week)
On 26 mrt 2008, at 14:36, Eric Rescorla wrote: > - Modern cryptographic implementations are extremely fast. For > comparison the MacBook Air I'm typing this on will do order 10^6 > HMAC-MD5s/second on 64-byte packets. So, to consume all my > resources would require order 10^8 bits per second, which is a > pretty serious packet-based DoS ittack on many contexts. This is a bogus argument. Implementations are always inferior to optimistic performance claims and although maybe your laptop CAN do that that doesn't mean you WANT it to spend its cycles and battery power on that. (Or maybe you do, but I certainly don't.) > - Even mounting this attack requires knowing both host/port > quartets. With DTLS, as with TLS, the responder/server's > port is typically known whereas the initiator/client's port > is random or pseudorandom. This creates some barrier to > mounting this attack. The DTLS design to reuse the port numbers is not unreasonable as long as DoS against CPU resources isn't a concern. But not using random sequence numbers, like TCP has been doing since the dawn of time, is a serious oversight because it costs next to nothing and buys a lot of protection against spoofing attacks. > - A very similar attack is available on IKE (and DTLS, of > course). In order to block DoS attacks, both handshakes > offer the option of doing a "stateless cookie" exchange, > in which the responder gives the initiator a token which > can be used to verify the client's next message (which must > of course contain the token). But the way these tokens are > generates is to have the responder compute a cryptographic > MAC/hash over some input data. So an attacker can force > any random IKE or DTLS stack to do as many digest operations > as it wants. That doesn't make sense. For such a cookie to provide additional benefit over the normal HMAC, the value in the next message must be present in that next message in the clear so the number of crypto operations required is equal to the number of valid packets, which isn't under the control of an attacker, rather than the total number of packets (like a HMAC), which can be inflated by an attacker. >> The part that I don't like about DTLS is the way it avoids dealing >> with MTU issues and pretty much tells people to do PMTUD for IPv4 for >> UDP even though in theory this is extremely hard to get to work and >> practice it never works. > You've misunderstood the purpose of DTLS, which is to replicate > the semantics of UDP to the greatest extent possible, consistent > with also provided an association-based security system. Accordingly, > since UDP-based applications have to deal with PMTU, they have to > do so with DTLS as well. I wasn't offering a critique of DTLS' purpose, but rather, of its operation. Path MTU discovery for IPv4 for UDP can only work if applications can adjust their packet sizes arbitrarily, which they often can't, or at least not in a reasonable way. Perpetuating this broken idea in DTLS was a mistake. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TLS vs. IPsec (Was: Re: experiments in the ietf week)
At Wed, 26 Mar 2008 13:25:20 +0100, Iljitsch van Beijnum wrote: > > On 25 mrt 2008, at 16:10, Dan Wing wrote: > > > ... > >> And yes, the issues I referred to are DoS and TCP spoofing. > >> These can only be protected against at the network level. > > > What are your thoughts on DTLS's DoS and spoofing protection? > > Looks like this is mostly similar to IPsec except that the port > numbers rather than SA is used to demultiplex so the anti-DoS > protection that the sequence number / anti replay counter provides is > less than with IPsec. You really need to describe the attacks you're concerned about, rather than handwaving. After reading this a few times, I *think* you're claiming the following: An attacker who knows the host-port quartet of a DTLS association can send send completely bogus but correctly formatted packets to one side and therefore force them to attempt to decrypt the record. This amounts to a computational DoS attack. Whereas, by contrast, mounting this attack on IPsec requires knowing the SPI, which presumably requires being on path, since it's random. Do I have this right? If so this is a pretty feeble attack. - Modern cryptographic implementations are extremely fast. For comparison the MacBook Air I'm typing this on will do order 10^6 HMAC-MD5s/second on 64-byte packets. So, to consume all my resources would require order 10^8 bits per second, which is a pretty serious packet-based DoS ittack on many contexts. - Even mounting this attack requires knowing both host/port quartets. With DTLS, as with TLS, the responder/server's port is typically known whereas the initiator/client's port is random or pseudorandom. This creates some barrier to mounting this attack. - A very similar attack is available on IKE (and DTLS, of course). In order to block DoS attacks, both handshakes offer the option of doing a "stateless cookie" exchange, in which the responder gives the initiator a token which can be used to verify the client's next message (which must of course contain the token). But the way these tokens are generates is to have the responder compute a cryptographic MAC/hash over some input data. So an attacker can force any random IKE or DTLS stack to do as many digest operations as it wants. > I assume this means in the future we'll be running TCP over DTLS over > UDP... > > The part that I don't like about DTLS is the way it avoids dealing > with MTU issues and pretty much tells people to do PMTUD for IPv4 for > UDP even though in theory this is extremely hard to get to work and > practice it never works. You've misunderstood the purpose of DTLS, which is to replicate the semantics of UDP to the greatest extent possible, consistent with also provided an association-based security system. Accordingly, since UDP-based applications have to deal with PMTU, they have to do so with DTLS as well. -Ekr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TLS vs. IPsec (Was: Re: experiments in the ietf week)
On 25 mrt 2008, at 16:10, Dan Wing wrote: > ... >> And yes, the issues I referred to are DoS and TCP spoofing. >> These can only be protected against at the network level. > What are your thoughts on DTLS's DoS and spoofing protection? Looks like this is mostly similar to IPsec except that the port numbers rather than SA is used to demultiplex so the anti-DoS protection that the sequence number / anti replay counter provides is less than with IPsec. Also, a quick read of RFC 4347 doesn't reveal any advice regarding the initial value of the sequence number, so applications may start at 0 or 1 and make this easy to guess. I assume this means in the future we'll be running TCP over DTLS over UDP... The part that I don't like about DTLS is the way it avoids dealing with MTU issues and pretty much tells people to do PMTUD for IPv4 for UDP even though in theory this is extremely hard to get to work and practice it never works. I wonder what kind of security mechanisms we would come up with if we got to do all of this again from scratch but with the benefit of hindsight. I'm pretty sure it wouldn't be TLS+IPsec+DTLS. And if I could go back in time and make sure the person who invented the DF bit wouldn't make it to work that day, I wouldn't hesitate to do that. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
At Mon, 24 Mar 2008 15:17:56 +0100, Iljitsch van Beijnum wrote: > > On 19 mrt 2008, at 1:46, Eric Rescorla wrote: > > >> A more interesting experiment would be to do away with SSL for a bit > >> and use IPsec instead. > > > Why would this be either interesting or desirable? > > SSL is vulnerable to more attacks than IPsec and IPsec is more general > than SSL. As such it would be good if we could have IPsec deployment > similar to SSL deployment, similar to how it would be good to have > IPv6 rather than IPv4 deployment, so a similar experiment could be > useful in showing what if any the reasons are we're still stuck with > the inferior SSL/TLS technology. One of the true joys of the IETF is watching people explain why their favorite technology is superior to the technology people have actually chosen to use. Both IPsec and SSL have applications where they are the appropriate choice. I don't think there's a lot of point in going into them in detail. But given that the attacks you're mentioning are frankly irrelevant in 99.9% of cases (btw, I know what TCP spoofing is, but it's not relevant for TLS, because the application should be looking at the cryptographic identity, not the transport layer identity), the notion that we should tear out most of the application layer security infrastructure to accomodate your notions of architetural appropriateness strikes me as extremely dubious. -Ekr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TLS vs. IPsec (Was: Re: experiments in the ietf week)
> On 24 mrt 2008, at 18:58, Jari Arkko wrote: > > Now, if we had a proposal that turned IPsec into as easily deployable > > between random clients and known servers as TLS, I would be interested > > in a new experiment! But I did not see a proposal for that yet. Maybe > > time for that draft that Phillip suggested in another thread, > > Iljitsch? > I'm afraid that won't work because of scheduling conflicts if I wanted > to present such a draft to the appropriate SEC area wg... > A quick s/TLS/IPsec/g isn't realistic, but I would certainly be > interested in seeing one or more IETF services use some kind of IPsec > protection in order to see if this is workable in practice. There are > APIs that allow applications to set this up on a per-application > basis, unless I'm mistaken. I believe you're mistaken. There is much work that needs to be done in this area before it will be possible for applications to use IPsec this way. The good news is that the BTNS WG is actively working to fill this gap; see An abstract interface between applications and IPsec (draft-ietf-btns-abstract-api-01.txt) IPsec Channels: Connection Latching (draft-ietf-btns-connection-latching-06) IPsec Application Programming Interfaces (draft-ietf-btns-c-api-03) But even if this work is successful it will be many years before the necessary support is sufficiently widely implemented and deployed to be usable, assuming that ever happens. Ned ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: TLS vs. IPsec (Was: Re: experiments in the ietf week)
Iljitsch van Beijnum wrote: ... > And yes, the issues I referred to are DoS and TCP spoofing. > These can only be protected against at the network level. What are your thoughts on DTLS's DoS and spoofing protection? -d ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Write an RFC Was: experiments in the ietf week
Yes, a security experiment is not so interesting without an attack. I would like an evil twin access point to be set up with a cert that says 'evil twin' and measure how much traffic goes through it. This is frequently done at BlackHat albeit not necessarily in a manner that complies with human subjects criteria. Its not much of a security experiment if you only measure whether people can deploy it. From: Andrew G. Malis [mailto:[EMAIL PROTECTED] Sent: Tue 25/03/2008 9:05 AM To: Patrik Fältström Cc: Hallam-Baker, Phillip; IETF Discussion Subject: Re: Write an RFC Was: experiments in the ietf week Phillip does have a point regarding 802.1x authentication, which is typically used to authenticate the user to the service, and not vice versa. Conceivably a person could set up an "evil" access point that advertises the same beacon as the official access points, and has 802.1x enabled to accept the same shared user name and password (which is also well publicized). One way that could make this much more secure from the user viewpoint would be for every attendee to receive an individual 802.1x user name and password, perhaps printed on the back of their name tag. Presumably an "evil" access point would not have access to these names and passwords, so users can be sure that they are attaching to an official access point. But as this would create much more work for the NOC and admin staff, I'm not advocating we do that. Cheers, Andy On Mon, Mar 24, 2008 at 10:30 PM, Patrik Fältström <[EMAIL PROTECTED]> wrote: > > On 25 mar 2008, at 02.18, Hallam-Baker, Phillip wrote: > > > I am willing to have a go at it next time round but only if I have > > some idea what I am expected to have on my machine and what > > authentication indicata I am to expect. > > > > As it stands there is no way for me to evaluate an authentic or > > inauthentic experience. I don't know what authentic looks like. I > > have no trust anchor. > > This email message sent to me was enough of a trust anchor to use > 802.1x. Specifically as "the instructions" are the same as IETF-70 and > previous meetings. > > http://www.ietf.org/mail-archive/web/71attendees/current/msg00154.html > > Sure, the mail was not signed, but I also asked a friend at the > meeting "what he used". And as we both had the same instructions, we > trusted that. If we wanted to, we could have asked someone actually > running the network, but we did not feel we had to. > >Patrik > > > ___ > IETF mailing list > IETF@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TLS vs. IPsec (Was: Re: experiments in the ietf week)
On 24 mrt 2008, at 18:58, Jari Arkko wrote: > Now, if we had a proposal that turned IPsec into as easily deployable > between random clients and known servers as TLS, I would be interested > in a new experiment! But I did not see a proposal for that yet. Maybe > time for that draft that Phillip suggested in another thread, > Iljitsch? I'm afraid that won't work because of scheduling conflicts if I wanted to present such a draft to the appropriate SEC area wg... A quick s/TLS/IPsec/g isn't realistic, but I would certainly be interested in seeing one or more IETF services use some kind of IPsec protection in order to see if this is workable in practice. There are APIs that allow applications to set this up on a per-application basis, unless I'm mistaken. And yes, the issues I referred to are DoS and TCP spoofing. These can only be protected against at the network level. Encryption can, and therefore, probably should, be handled at the transport level. (That is not to say that authentication at the network level is entirely useless, just that it can protect against more stuff at the network level.) ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Write an RFC Was: experiments in the ietf week
Phillip does have a point regarding 802.1x authentication, which is typically used to authenticate the user to the service, and not vice versa. Conceivably a person could set up an "evil" access point that advertises the same beacon as the official access points, and has 802.1x enabled to accept the same shared user name and password (which is also well publicized). One way that could make this much more secure from the user viewpoint would be for every attendee to receive an individual 802.1x user name and password, perhaps printed on the back of their name tag. Presumably an "evil" access point would not have access to these names and passwords, so users can be sure that they are attaching to an official access point. But as this would create much more work for the NOC and admin staff, I'm not advocating we do that. Cheers, Andy On Mon, Mar 24, 2008 at 10:30 PM, Patrik Fältström <[EMAIL PROTECTED]> wrote: > > On 25 mar 2008, at 02.18, Hallam-Baker, Phillip wrote: > > > I am willing to have a go at it next time round but only if I have > > some idea what I am expected to have on my machine and what > > authentication indicata I am to expect. > > > > As it stands there is no way for me to evaluate an authentic or > > inauthentic experience. I don't know what authentic looks like. I > > have no trust anchor. > > This email message sent to me was enough of a trust anchor to use > 802.1x. Specifically as "the instructions" are the same as IETF-70 and > previous meetings. > > http://www.ietf.org/mail-archive/web/71attendees/current/msg00154.html > > Sure, the mail was not signed, but I also asked a friend at the > meeting "what he used". And as we both had the same instructions, we > trusted that. If we wanted to, we could have asked someone actually > running the network, but we did not feel we had to. > >Patrik > > > ___ > IETF mailing list > IETF@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Usability RE: Write an RFC Was: experiments in the ietf week
What I am trying to get at here is the problem of usability. Security is no use to me to stop Internet crime if everyone either turns it off or is unable to use it. The layered model is a big problem here because the lower layers abstract away the user. There is no user interface, there are no user oriented use cases and as a result the protocols fail to deliver the necessary information to the upper layers to allow the user to make sure that they are safe. "3. Do Not Verify Server Cert and we won't verify yours :)" OK, it is a good idea to turn on confidentiality and integrity. But this is not something that is really going to help solve the evil twin WiFi attack out in the general population. Its a pretty insidious attack as the effects are localized and we can't measure the frequency. If we are going to do experiments then we should be providing feedback to the relevant parties. Pointing out to the IEEE that WiFi security fails basic principles of security usability - the user does not have sufficient information to distinguish the intended connection from the twin - would be a useful purpose. Of course, going round pointing out this sort of thing to others would make it incumbent on us to fix the same problems in our protocols. -Original Message- From: Patrik Fältström [mailto:[EMAIL PROTECTED] Sent: Mon 24/03/2008 10:30 PM To: Hallam-Baker, Phillip Cc: Russ Housley; IETF Discussion Subject: Re: Write an RFC Was: experiments in the ietf week On 25 mar 2008, at 02.18, Hallam-Baker, Phillip wrote: > I am willing to have a go at it next time round but only if I have > some idea what I am expected to have on my machine and what > authentication indicata I am to expect. > > As it stands there is no way for me to evaluate an authentic or > inauthentic experience. I don't know what authentic looks like. I > have no trust anchor. This email message sent to me was enough of a trust anchor to use 802.1x. Specifically as "the instructions" are the same as IETF-70 and previous meetings. http://www.ietf.org/mail-archive/web/71attendees/current/msg00154.html Sure, the mail was not signed, but I also asked a friend at the meeting "what he used". And as we both had the same instructions, we trusted that. If we wanted to, we could have asked someone actually running the network, but we did not feel we had to. Patrik ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Write an RFC Was: experiments in the ietf week
On 25 mar 2008, at 02.18, Hallam-Baker, Phillip wrote: > I am willing to have a go at it next time round but only if I have > some idea what I am expected to have on my machine and what > authentication indicata I am to expect. > > As it stands there is no way for me to evaluate an authentic or > inauthentic experience. I don't know what authentic looks like. I > have no trust anchor. This email message sent to me was enough of a trust anchor to use 802.1x. Specifically as "the instructions" are the same as IETF-70 and previous meetings. http://www.ietf.org/mail-archive/web/71attendees/current/msg00154.html Sure, the mail was not signed, but I also asked a friend at the meeting "what he used". And as we both had the same instructions, we trusted that. If we wanted to, we could have asked someone actually running the network, but we did not feel we had to. Patrik ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Write an RFC Was: experiments in the ietf week
I am willing to have a go at it next time round but only if I have some idea what I am expected to have on my machine and what authentication indicata I am to expect. As it stands there is no way for me to evaluate an authentic or inauthentic experience. I don't know what authentic looks like. I have no trust anchor. -Original Message- From: Russ Housley [mailto:[EMAIL PROTECTED] Sent: Mon 24/03/2008 3:22 PM To: Hallam-Baker, Phillip Cc: IETF Discussion Subject: Re: Write an RFC Was: experiments in the ietf week Phillip: Have you tried the SSID at the IETF meetings that is configured to make use of 802.1x? Russ At 01:49 PM 3/24/2008, Hallam-Baker, Phillip wrote: Secure WiFi Connection I would like to see some demonstration of the fact that the default WiFi configuration on all existing platforms provides zero protection against an 'evil twin' WiFi attack. Using WPA protection has little value unless you have mutual authentication. The current specs don't allow for that. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Write an RFC Was: experiments in the ietf week
Well I would submit that there is a major problem there on the security usability front. Don't make me think. My tolerance for network configuration is vastly greater than the typical user. This has to all just work, just like my Apple Mac did on the home network the day I bought it. Not like my Apple Mac this morning which for some unaccountable reason no longer sees the machines it acknowledged before and gives me precisely zero information to allow me to determine the cause. From: Jari Arkko [mailto:[EMAIL PROTECTED] > *Secure WiFi Connection* > > I would like to see some demonstration of the fact that the default > WiFi configuration on all existing platforms provides zero protection > against an 'evil twin' WiFi attack. Using WPA protection has little > value unless you have mutual authentication. The current specs don't > allow for that. > Is there something missing from ietf.1x ssid support that we've had for years? It uses IETF standards, too... Jari ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Write an RFC Was: experiments in the ietf week
Phillip: Have you tried the SSID at the IETF meetings that is configured to make use of 802.1x? Russ At 01:49 PM 3/24/2008, Hallam-Baker, Phillip wrote: Secure WiFi Connection I would like to see some demonstration of the fact that the default WiFi configuration on all existing platforms provides zero protection against an 'evil twin' WiFi attack. Using WPA protection has little value unless you have mutual authentication. The current specs don't allow for that. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Write an RFC Was: experiments in the ietf week
Phillip, > write an Internet Draft prior to the experiment, > +1 > *IPv6 Next Steps* > > The Philadelphia IPv6 outage tested one specific aspect of the > transition - is there an IPv6 network on the other side to connect to > in due course, is it possible to run a pure IPv6 network? > > I think that that is one useful data point to test but not the only > significant data point. In particular the biggest problem we have is > the exhaustion of IPv4 space. The most important network test to make > in my view is whether current generation machines work acceptably on > an IPv6+NATv4Share connection for typical end user tasks. > I agree, and I think that's been the focus of many folks working in this space. Lets see what we can come up with for Dublin. > By 'acceptably' I mean ZERO-click administration. No configuration > tweaks whatsoever. If a product does not run out of the box it has failed. > > *Secure WiFi Connection* > > I would like to see some demonstration of the fact that the default > WiFi configuration on all existing platforms provides zero protection > against an 'evil twin' WiFi attack. Using WPA protection has little > value unless you have mutual authentication. The current specs don't > allow for that. > Is there something missing from ietf.1x ssid support that we've had for years? It uses IETF standards, too... Jari ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
TLS vs. IPsec (Was: Re: experiments in the ietf week)
Phillip, Iljitsch, > If you beleive that there is an attack that SSL is vulnerable to you > should bring it up in TLS. I think Iljitsch meant that TLS cannot protect against TCP vulnerabilities, such as spoofed connection resets. This is obviously well known. The upside of TLS has of course been that its been extremely easy to deploy. That's the experiment the planet has been running for the last decade, and I think the results speak for themselves ;-) Now, if we had a proposal that turned IPsec into as easily deployable between random clients and known servers as TLS, I would be interested in a new experiment! But I did not see a proposal for that yet. Maybe time for that draft that Phillip suggested in another thread, Iljitsch? Jari ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Write an RFC Was: experiments in the ietf week
Enough, already. If we are going to have experiments in IETF week then lets do the thing right and have a process. In particular - Proposer MUST write an Internet Draft prior to the experiment stating: 1) Purpose - the information to be obtained 2) Method - what it to be done 3) Resources - what will be required of the organizers 4) Expected outcomes - what it is expected that the experiment will tell us 5) Forcing functions - if the experiment is intended to be a forcing function for infrastructure deployment 6) Justification for spending the time and effort Proposer MUST write up the results of the experiment and submit to the RFC editor afterwards I don't think there is much point in just running the same experiment every time. It will become a tradition and the last thing this institution needs is more traditions that have outlived their utility cluttering up the process. And we should probably have a separate mailing list to discuss such proposals. IPv6 Next Steps The Philadelphia IPv6 outage tested one specific aspect of the transition - is there an IPv6 network on the other side to connect to in due course, is it possible to run a pure IPv6 network? I think that that is one useful data point to test but not the only significant data point. In particular the biggest problem we have is the exhaustion of IPv4 space. The most important network test to make in my view is whether current generation machines work acceptably on an IPv6+NATv4Share connection for typical end user tasks. By 'acceptably' I mean ZERO-click administration. No configuration tweaks whatsoever. If a product does not run out of the box it has failed. Secure WiFi Connection I would like to see some demonstration of the fact that the default WiFi configuration on all existing platforms provides zero protection against an 'evil twin' WiFi attack. Using WPA protection has little value unless you have mutual authentication. The current specs don't allow for that. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: experiments in the ietf week
These claims are meaningless to me. Transport and network layer security have distinct objectives and purposes. They are not replacements or interchangeable in any sense. If you beleive that there is an attack that SSL is vulnerable to you should bring it up in TLS. In general the higher up you climb in the stack, the better the security you can offer. In order to provide application layer security in a correctly layered network model you have to apply security at a layer that the application talks to, that means either the messaging (S/MIME/PGP/S-HTTP/SHEN) or the transport layer (SSL, DNS). SSL provides confidentiality, integrity and authentication. If you want useful non-repudiation you need to move up to the message layer. The advantage of going lower in the stack is to gain greater generality. IPSec allows every communication to be protected with a basic level of security in a manner that is transparent to the applications. As such it allows certain aspects of confidentiality and integrity to be supported but cannot inform application logic. Security today is all about layered security. Ideally an email transaction would have at least three layers of security: 1) IPSec 2) TLS (between SUBMIT client to server, STP server to server, POP3/IMAP server to client) 3a) DKIM + S/MIME/PGP Each message should be DKIM signed as a matter of course If the recipient advertises an acceptable encryption key and protocol this should be used to encrypt the message 3b) DRM attachments If a message has attachments (e.g. Word, HTML Archive, etc) these should be subject to lifecycle-long data level protection. The most critical layer here is layer 3b which is unfortunately the one we do not have today. At the moment 2014 is the earliest I can see there being the hope of an unencumbered data level security specification. I do not see any value in 'turning off' upper layer security enhancements as an experiment. From: [EMAIL PROTECTED] on behalf of Iljitsch van Beijnum Sent: Mon 24/03/2008 10:17 AM To: Eric Rescorla Cc: Mark Andrews; Jari Arkko; IETF Discussion; Kurt Erik Lindqvist Subject: Re: experiments in the ietf week On 19 mrt 2008, at 1:46, Eric Rescorla wrote: >> A more interesting experiment would be to do away with SSL for a bit >> and use IPsec instead. > Why would this be either interesting or desirable? SSL is vulnerable to more attacks than IPsec and IPsec is more general than SSL. As such it would be good if we could have IPsec deployment similar to SSL deployment, similar to how it would be good to have IPv6 rather than IPv4 deployment, so a similar experiment could be useful in showing what if any the reasons are we're still stuck with the inferior SSL/TLS technology. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
On 24 Mar 2008, at 11:18 , Marc Manthey wrote: > hello ipv6 peoples, sorry for crossposting > > how can i use ipv6 from my machine ? > > using leopard 10.5.2. mail ? > > my endpoint is 2001:6f8:1051:0:20d:93ff:fe79:f1e > > thought its automatic :-P I think you just need to make sure that the servers you use for inbound and outbound mail are reachable on IPv6 and have records published in the DNS. Joe ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
> >> Umm... At this time, most IETF mailing lists are hosted on >> mail.ietf.org a.k.a. www.ietf.org, which is IPv6 enabled. >> (The numbers I have for active WGs are that 90 out of 120 lists >> are hosted on ietf.org). I can't really reconcile that with >> your statement above. Could you expand on your thoughts in >> this respect? > > > IETF discussion list (and several others): > > Received: from mail.ietf.org (mail.ietf.org > [IPv6:2001:1890:1112:1::20]) > > v6ops list: > > Received: from psg.com (psg.com [IPv6:2001:418:1::62]) > > This is excellent progress since the last time I checked somewhere > last year, which was the basis for my statement. hello ipv6 peoples, sorry for crossposting how can i use ipv6 from my machine ? using leopard 10.5.2. mail ? my endpoint is 2001:6f8:1051:0:20d:93ff:fe79:f1e thought its automatic :-P thanks marc -- "Wer also allgemeine Aufklärung verbreitet, verschafft zugleich eben dadurch allgemeine wechselseitige Sicherheit, und allgemeine Aufklärung und Sicherheit machen Fürsten und Staaten entbehrlich. Oder wozu braucht man sie sodann?" Marc Manthey - Hildeboldplatz 1a D - 50672 Köln - Germany Tel.:0049-221-3558032 Mobil:0049-1577-3329231 jabber :[EMAIL PROTECTED] blog : http://www.let.de ipv6 http://www.stattfernsehen.com/matrix ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
On 16 mrt 2008, at 21:42, Henrik Levkowetz wrote: > ... Nearly all IETF mailinglists are still hosted on IPv4-only >> servers, to name just one issue. > Umm... At this time, most IETF mailing lists are hosted on > mail.ietf.org a.k.a. www.ietf.org, which is IPv6 enabled. > (The numbers I have for active WGs are that 90 out of 120 lists > are hosted on ietf.org). I can't really reconcile that with > your statement above. Could you expand on your thoughts in > this respect? IETF discussion list (and several others): Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) v6ops list: Received: from psg.com (psg.com [IPv6:2001:418:1::62]) This is excellent progress since the last time I checked somewhere last year, which was the basis for my statement. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
On 19 mrt 2008, at 1:46, Eric Rescorla wrote: >> A more interesting experiment would be to do away with SSL for a bit >> and use IPsec instead. > Why would this be either interesting or desirable? SSL is vulnerable to more attacks than IPsec and IPsec is more general than SSL. As such it would be good if we could have IPsec deployment similar to SSL deployment, similar to how it would be good to have IPv6 rather than IPv4 deployment, so a similar experiment could be useful in showing what if any the reasons are we're still stuck with the inferior SSL/TLS technology. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
Yes, that's excellent. In particular, I like your approach of making things available for the IETF crowd, delivered by the folks who are also delivering the standards. Jari ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
Hi Jari, we have already started todo the same with other protocols in GEOPRIV. See http://www.ietf.org/mail-archive/web/geopriv/current/msg05453.html http://www.ietf.org/mail-archive/web/geopriv/current/msg05468.html http://www.ietf.org/mail-archive/web/geopriv/current/msg05472.html Ciao Hannes Jari Arkko wrote: > I really enjoyed the IPv6 experiment, thanks to everyone who was > involved. Obviously, the experiment and a couple of other recent things > (like moving to AMS service) made things move forward in a number of > different places, our own computers, IETF computers, various people's > own and company sites, etc. Perhaps the most notable achievement here > was ipv6.google.com. That was really great, thank you Google! > > But the experiment was useful also in other ways, not only as an > operational/deployment action. The two experiments that I attended > (NANOG and IETF) have changed my and maybe other people's opinions too > on some of the technical issues. I think it helps us see clearer on what > are the things that the IETF needs to do in this space. We will see > follow-ups on this. > > We should also implement future IPv6 experiments and network deployments. > > But why I'm really sending this e-mail is to suggest that IPv6 might not > be the only topic for such future efforts. Here's a challenge for the > RAI folks: What about SIP, as in every plenary participant making SIP > calls to each other. Doable? > > Challenge for our IT folks: Internationalized Internet Drafts, including > file names. Doable? > > ietf.pana in addition to ietf.1x. Doable? > > Etc > > Jari > > ___ > IETF mailing list > IETF@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
Eric, > I was referring to Iljitsch's suggestion about SSL and IPsec, not > the suggestion about DNSSEC. > Yes. FWIW, I don't think that would be interesting. DNSSEC experiments by itself might be interesting, particularly if they could be combined with some movement in getting the root signed. Jari ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
At Wed, 19 Mar 2008 22:59:52 +1100, Mark Andrews wrote: > > > > At Sun, 16 Mar 2008 19:44:12 +0100, > > Iljitsch van Beijnum wrote: > > > > > > On 16 mrt 2008, at 2:16, Mark Andrews wrote: > > > > > > > Enable DNSSEC validation on the network's servers. At a > > > > minimum make them DNSSEC transparent. > > > > > > > > > Is there any software out there for common OSes that does something > > > useful with this? > > > > > > A more interesting experiment would be to do away with SSL for a bit > > > and use IPsec instead. > > > > Why would this be either interesting or desirable? > > DNSSEC transparency is important for machines on the IPv6 > only net trying to validate answers off IPv4 only servers. > > Validatation is useful for protecting the resolvers themselves. I was referring to Iljitsch's suggestion about SSL and IPsec, not the suggestion about DNSSEC. -Ekr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
> At Sun, 16 Mar 2008 19:44:12 +0100, > Iljitsch van Beijnum wrote: > > > > On 16 mrt 2008, at 2:16, Mark Andrews wrote: > > > > > Enable DNSSEC validation on the network's servers. At a > > > minimum make them DNSSEC transparent. > > > > > > Is there any software out there for common OSes that does something > > useful with this? > > > > A more interesting experiment would be to do away with SSL for a bit > > and use IPsec instead. > > Why would this be either interesting or desirable? DNSSEC transparency is important for machines on the IPv6 only net trying to validate answers off IPv4 only servers. Validatation is useful for protecting the resolvers themselves. Mark > -Ekr > ___ > IETF mailing list > IETF@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
At Sun, 16 Mar 2008 19:44:12 +0100, Iljitsch van Beijnum wrote: > > On 16 mrt 2008, at 2:16, Mark Andrews wrote: > > > Enable DNSSEC validation on the network's servers. At a > > minimum make them DNSSEC transparent. > > > Is there any software out there for common OSes that does something > useful with this? > > A more interesting experiment would be to do away with SSL for a bit > and use IPsec instead. Why would this be either interesting or desirable? -Ekr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
> On 16 mrt 2008, at 2:16, Mark Andrews wrote: > > > Enable DNSSEC validation on the network's servers. At a > > minimum make them DNSSEC transparent. > > > Is there any software out there for common OSes that does something > useful with this? Yes. It is also useful in its own right by protecting the down stream clients. Note: DNSSEC validation in the recursive resolver is stage 1 of DNSSEC deployment. > A more interesting experiment would be to do away with SSL for a bit > and use IPsec instead. But I think we're far from being finished with > IPv6. Nearly all IETF mailinglists are still hosted on IPv4-only > servers, to name just one issue. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
Hi Iljitsch, On 2008-03-16 19:44 Iljitsch van Beijnum said the following: ... Nearly all IETF mailinglists are still hosted on IPv4-only > servers, to name just one issue. Umm... At this time, most IETF mailing lists are hosted on mail.ietf.org a.k.a. www.ietf.org, which is IPv6 enabled. (The numbers I have for active WGs are that 90 out of 120 lists are hosted on ietf.org). I can't really reconcile that with your statement above. Could you expand on your thoughts in this respect? Henrik ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
On 16 mrt 2008, at 2:16, Mark Andrews wrote: > Enable DNSSEC validation on the network's servers. At a > minimum make them DNSSEC transparent. Is there any software out there for common OSes that does something useful with this? A more interesting experiment would be to do away with SSL for a bit and use IPsec instead. But I think we're far from being finished with IPv6. Nearly all IETF mailinglists are still hosted on IPv4-only servers, to name just one issue. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
Enable DNSSEC validation on the network's servers. At a minimum make them DNSSEC transparent. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
On 2008-03-16 02:09, Russ Housley wrote: > Jari: > > > Challenge for our IT folks: Internationalized Internet Drafts, > > including file names. Doable? > > Six or seven years ago we had a big discussion regarding the > language(s) to be used in the IETF. Harald was IETF Chair when this > discussion took place, and he declared the consensus to be that the > IETF would use on language: English. > > I do think it would be useful to look at representing author names > according to the individual's preference. And addresses. And there's also the question of useful examples in drafts discussing I18N issues. > However, I do not think > that non-English file names are consistent with the consensus that was > reached. Agreed; I think there are too many practical problems in that, that really aren't ours to solve. draft-hoffman-utf8-rfcs talked about this. An experiment wouldn't be hard, and doesn't need a plenary... Brian ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
On 14 mar 2008, at 13.01, Jari Arkko wrote: > We should also implement future IPv6 experiments and network > deployments. > > But why I'm really sending this e-mail is to suggest that IPv6 might > not > be the only topic for such future efforts. Here's a challenge for the > RAI folks: What about SIP, as in every plenary participant making SIP > calls to each other. Doable? > > Challenge for our IT folks: Internationalized Internet Drafts, > including > file names. Doable? > > ietf.pana in addition to ietf.1x. Doable? I would like to second Jari's statement. To follow up to Joel's comment at the technical plenary on the issue of lack of operators - I believe that if the designers and vendors of some of the IETF standards better understood how they actually worked in real use cases and tried to deployment - we might find a lot more deployment issues earlier. I am all for it. - kurtis - ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
Jari: > Challenge for our IT folks: Internationalized Internet Drafts, > including file names. Doable? Six or seven years ago we had a big discussion regarding the language(s) to be used in the IETF. Harald was IETF Chair when this discussion took place, and he declared the consensus to be that the IETF would use on language: English. I do think it would be useful to look at representing author names according to the individual's preference. However, I do not think that non-English file names are consistent with the consensus that was reached. Russ ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
As some of you might have noticed, some GEOPRIV participants ran a small experiment, using the IETF network as a base for location-based services. We had a few folks try it, and learned a lot, but three main things: 1. Interworking with the IETF NOC was really pleasant (Thanks, guys!) 2. James Winterbottom's location server worked really well and integrated easily with the IETF network. 2. The client software I wrote successfully interworked with the location server in test cases, but failed badly in real life Overall, prototyping these technologies was a really positive experience for us, one that I would recommend to other WGs. We're certainly planning on making another effort at it in Dublin! --Richard Jari Arkko wrote: > I really enjoyed the IPv6 experiment, thanks to everyone who was > involved. Obviously, the experiment and a couple of other recent things > (like moving to AMS service) made things move forward in a number of > different places, our own computers, IETF computers, various people's > own and company sites, etc. Perhaps the most notable achievement here > was ipv6.google.com. That was really great, thank you Google! > > But the experiment was useful also in other ways, not only as an > operational/deployment action. The two experiments that I attended > (NANOG and IETF) have changed my and maybe other people's opinions too > on some of the technical issues. I think it helps us see clearer on what > are the things that the IETF needs to do in this space. We will see > follow-ups on this. > > We should also implement future IPv6 experiments and network deployments. > > But why I'm really sending this e-mail is to suggest that IPv6 might not > be the only topic for such future efforts. Here's a challenge for the > RAI folks: What about SIP, as in every plenary participant making SIP > calls to each other. Doable? > > Challenge for our IT folks: Internationalized Internet Drafts, including > file names. Doable? > > ietf.pana in addition to ietf.1x. Doable? > > Etc > > Jari > > ___ > IETF mailing list > IETF@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
Fred Baker wrote: > On Mar 14, 2008, at 8:01 AM, Jari Arkko wrote: > >> Challenge for our IT folks: Internationalized Internet Drafts, >> including file names. Doable? > > It's doable, no doubt. The next question is whether this is actually > smart. > > The Finnish character set is something I can deal with, although my > keyboard differs from a Finnish one, making typing the name in > something I would have to think about. I personally don't speak or > read any of the languages that use derivatives of the Han character > set, and will find it difficult to read or point you to a draft with > a Japanese or Chinese name. > > I'm inclined to wonder what problem you're solving and what problem > you're trading that one for. I imagine it is that you would like to > be able to use Finnish words in draft monikers or to post internet > drafts in Finnish. I would counsel you to be careful what you wish > for. If the important thing is global communication among engineers, > this might take you in a direction you didn't really intend. Well, two wishes that come up frequently are really modest: - the ability to provide properly spelled contact information - the ability to use non-ASCII characters in specification text that deals with I18N Of course to make this useful, it would need to be accepted in RFCs as well. BR, Julian ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: experiments in the ietf week
On Mar 14, 2008, at 8:01 AM, Jari Arkko wrote: > Challenge for our IT folks: Internationalized Internet Drafts, > including file names. Doable? It's doable, no doubt. The next question is whether this is actually smart. The Finnish character set is something I can deal with, although my keyboard differs from a Finnish one, making typing the name in something I would have to think about. I personally don't speak or read any of the languages that use derivatives of the Han character set, and will find it difficult to read or point you to a draft with a Japanese or Chinese name. I'm inclined to wonder what problem you're solving and what problem you're trading that one for. I imagine it is that you would like to be able to use Finnish words in draft monikers or to post internet drafts in Finnish. I would counsel you to be careful what you wish for. If the important thing is global communication among engineers, this might take you in a direction you didn't really intend. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
experiments in the ietf week
I really enjoyed the IPv6 experiment, thanks to everyone who was involved. Obviously, the experiment and a couple of other recent things (like moving to AMS service) made things move forward in a number of different places, our own computers, IETF computers, various people's own and company sites, etc. Perhaps the most notable achievement here was ipv6.google.com. That was really great, thank you Google! But the experiment was useful also in other ways, not only as an operational/deployment action. The two experiments that I attended (NANOG and IETF) have changed my and maybe other people's opinions too on some of the technical issues. I think it helps us see clearer on what are the things that the IETF needs to do in this space. We will see follow-ups on this. We should also implement future IPv6 experiments and network deployments. But why I'm really sending this e-mail is to suggest that IPv6 might not be the only topic for such future efforts. Here's a challenge for the RAI folks: What about SIP, as in every plenary participant making SIP calls to each other. Doable? Challenge for our IT folks: Internationalized Internet Drafts, including file names. Doable? ietf.pana in addition to ietf.1x. Doable? Etc Jari ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
