RE: Where to find IONs?
Hi Mykyta, Please see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg04792.html Adrian From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mykyta Yevstifeyev Sent: 06 March 2011 05:12 To: IETF Discussion Subject: Where to find IONs? Hello all, RFC 4693, in accordance with RFC 3933, created the new experimental series of documents called IONs. However the only page I found relevant to this topic on ietf.org site is http://www.ietf.org/old/2009/u/ietfchair/opNotes.html dated March 2008. It links to http://www.ietf.org/iesg/content/ions.html that does not seem to exist at all. So my question is: where should I find IONs and were they published recently at all? Mykyta Yevstifeyev ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Where to find IONs?
--On Sunday, March 06, 2011 11:15 + Adrian Farrel adr...@olddog.co.uk wrote: Hi Mykyta, Please see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg 04792.html Adrian Adrian, With the understanding that this is a different question than Mykyta's, how is someone new to the IETF or trying to understand our procedures or procedural documentation supposed to find that out. The usual searches mostly tell me about the ION WG, not these documents. Wouldn't it be reasonable to publish a short RFC that updates RFC 4693 into oblivion, says at least that IONs are dead and maybe explains briefly why it wasn't a good idea. If the IESG doesn't have enough spare cycles to give that priority, I assume that, since Mykyta is asking and given the energy he has been putting into other things, if some AD gave him a quick explanation, a little encouragement, and a promise to process such a document, it might appear fairly quickly. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Where to find IONs?
John, I (personally and not daring to speak for the IESG) consider that an RFC updating 4693 to report on the experiment and the consequent acts is a fine idea. Basically taking the text from the email I referenced, but being a bit careful with URLs. Cheers, Adrian -Original Message- From: John C Klensin [mailto:john-i...@jck.com] Sent: 06 March 2011 10:32 To: adr...@olddog.co.uk; 'Mykyta Yevstifeyev'; 'IETF Discussion' Subject: RE: Where to find IONs? --On Sunday, March 06, 2011 11:15 + Adrian Farrel adr...@olddog.co.uk wrote: Hi Mykyta, Please see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg 04792.html Adrian Adrian, With the understanding that this is a different question than Mykyta's, how is someone new to the IETF or trying to understand our procedures or procedural documentation supposed to find that out. The usual searches mostly tell me about the ION WG, not these documents. Wouldn't it be reasonable to publish a short RFC that updates RFC 4693 into oblivion, says at least that IONs are dead and maybe explains briefly why it wasn't a good idea. If the IESG doesn't have enough spare cycles to give that priority, I assume that, since Mykyta is asking and given the energy he has been putting into other things, if some AD gave him a quick explanation, a little encouragement, and a promise to process such a document, it might appear fairly quickly. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Where to find IONs?
Adrian, Four of eight links in the message you referred to are dead. I'm looking for /ion-ad-sponsoring/, but there is neither such ION nor IESG statement, as mentioned there. Where should I find it? Mykyta 06.03.2011 13:52, Adrian Farrel wrote: John, I (personally and not daring to speak for the IESG) consider that an RFC updating 4693 to report on the experiment and the consequent acts is a fine idea. Basically taking the text from the email I referenced, but being a bit careful with URLs. Cheers, Adrian -Original Message- From: John C Klensin [mailto:john-i...@jck.com] Sent: 06 March 2011 10:32 To: adr...@olddog.co.uk; 'Mykyta Yevstifeyev'; 'IETF Discussion' Subject: RE: Where to find IONs? --On Sunday, March 06, 2011 11:15 + Adrian Farrel adr...@olddog.co.uk wrote: Hi Mykyta, Please see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg 04792.html Adrian Adrian, With the understanding that this is a different question than Mykyta's, how is someone new to the IETF or trying to understand our procedures or procedural documentation supposed to find that out. The usual searches mostly tell me about the ION WG, not these documents. Wouldn't it be reasonable to publish a short RFC that updates RFC 4693 into oblivion, says at least that IONs are dead and maybe explains briefly why it wasn't a good idea. If the IESG doesn't have enough spare cycles to give that priority, I assume that, since Mykyta is asking and given the energy he has been putting into other things, if some AD gave him a quick explanation, a little encouragement, and a promise to process such a document, it might appear fairly quickly. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: conformance languages (issue 278), was: Last Call: draft-ietf-httpbis-content-disp-06.txt (Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)) to Proposed Stan
On 02.03.2011 15:11, Julian Reschke wrote: ... Proposed change for the three items in 4.3: o Many platforms do not use Internet Media Types ([RFC2046]) to hold type information in the file system, but rely on filename extensions instead. Trusting the server-provided file extension could introduce a privilege escalation when the saved file is later opened (consider .exe). Thus, recipients SHOULD ensure that a file extension is used that is safe, optimally matching the media type of the received payload. o Recipients SHOULD strip or replace character sequences that are known to cause confusion both in user interfaces and in filenames, such as control characters and leading and trailing whitespace. o Other aspects recipients need to be aware of are names that have a special meaning in the file system or in shell commands, such as . and .., ~, |, and also device names. Recipients SHOULD ignore or substitute names like these. (see http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/278/i278.diff). ... ...applied with http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1152; I plan to submit a -07 draft soon after LC ends. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Where to find IONs?
Mykyta, URLs become out of date or are mistyped. It is not my job to run Google for you. Nevertheless: in this case it would appear that statements should read statement in the URLs. IESG statements are linked from the IETF home page at http://www.ietf.org/iesg/statement.html I presume what you are specifically looking for is: http://www.ietf.org/iesg/statement/ad-sponsoring-docs.html Adrian From: Mykyta Yevstifeyev [mailto:evniki...@gmail.com] Sent: 06 March 2011 11:04 To: adr...@olddog.co.uk Cc: 'John C Klensin'; 'IETF Discussion' Subject: Re: Where to find IONs? Adrian, Four of eight links in the message you referred to are dead. I'm looking for ion-ad-sponsoring, but there is neither such ION nor IESG statement, as mentioned there. Where should I find it? Mykyta 06.03.2011 13:52, Adrian Farrel wrote: John, I (personally and not daring to speak for the IESG) consider that an RFC updating 4693 to report on the experiment and the consequent acts is a fine idea. Basically taking the text from the email I referenced, but being a bit careful with URLs. Cheers, Adrian -Original Message- From: John C Klensin [mailto:john-i...@jck.com] Sent: 06 March 2011 10:32 To: adr...@olddog.co.uk; 'Mykyta Yevstifeyev'; 'IETF Discussion' Subject: RE: Where to find IONs? --On Sunday, March 06, 2011 11:15 + Adrian Farrel mailto:adr...@olddog.co.uk adr...@olddog.co.uk wrote: Hi Mykyta, Please see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg 04792.html Adrian Adrian, With the understanding that this is a different question than Mykyta's, how is someone new to the IETF or trying to understand our procedures or procedural documentation supposed to find that out. The usual searches mostly tell me about the ION WG, not these documents. Wouldn't it be reasonable to publish a short RFC that updates RFC 4693 into oblivion, says at least that IONs are dead and maybe explains briefly why it wasn't a good idea. If the IESG doesn't have enough spare cycles to give that priority, I assume that, since Mykyta is asking and given the energy he has been putting into other things, if some AD gave him a quick explanation, a little encouragement, and a promise to process such a document, it might appear fairly quickly. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Where to find IONs?
On 06.03.2011 14:14, Adrian Farrel wrote: Mykyta, URLs become out of date or are mistyped. It is not my job to run Google for you. ... http://www.w3.org/Provider/Style/URI BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/04/2011 08:06 PM, Dean Willis wrote: I just came across what may be old news to many of you. The July 2007 issue of IEEE Spectrum included an article entitled The Athens Affair, subtitled How Some Extremely Smart Hackers Pulled Off The Most Audacious Cell-Network Break-in Ever. In short, perpetrators appear to have accessed the lawful-intercept component of mobile switches in-use, and were able to tap a lot of phones, including that of the Prime Minister of the host nation. Apparently this was made easier by the fact that the user-interface for the LI component had not yet been installed, making it possible for the interceptions to go undetected for some time. This is just an example of a maxim: if we build nefarious mechanisms into systems, SOMEBODY is going to abuse them. Otherwise said: If you build in a back-door, don't be surprised when somebody sticks something in it. Sure, any meathead can slap a microphone on a window, order the withdrawal of a bunch of BGP routes, or cut the power to a switching center. There's not a lot we can do about that. But we can do a lot about a wide variety of man in the middle attacks, if we're willing to step up and confront the bullies out there, along with the misguided who don't understand why security back-doors are a two-edged sword, as dangerous to themselves as to their opposition. Sure, everybody wants their systems to be secure and their opposition's systems less so, but in the real world, everybody is somebody's opposition. The only way to be safe is to have universal protections. Start by locking yourself out. If that works, then it MAY stop the bad guys too. So what can we do about it? Every document we now produce has a Security Considerations. I hereby propose the following extensions to that section, such that each specification requiring a meaningful Security Considerations section MUST address the following: 1) Privacy and Integrity: We believe that intermediaries should be neither able to understand nor alter the transmitted material without the explicit consent and awareness of the users. How are the principles of end-to-end privacy and integrity provided by the specification? Reasonable solutions might include any of our well-documented encryption and signature systems coupled with applicable key management mechanisms. Analysis within the specification should also describe the known limitations of the specification, such as susceptibility to hostile certificate authorities. Further, forthcoming IETF specifications MUST not allow plain-text transmission of anything within any protocol. Sign or cipher (or both, as appropriate) everything, all the time. 2) Privacy and Obscurity: We believe that observation of a traffic flow pr sequence of traffic flows should reveal as little information about the application or user of the application as possible to an intermediary who observes the traffic without the explicit consent and awareness of the user. In principle, deep packet inspection should be completely useless, as should attempts by an intermediary to trace the end-user(s) to a specific physical location. How does the specification provide for obscuring the content of the application and the identity and location of users involved in the sequence? Reasonable solutions might include things like TOR combined with TLS. Analysis within the specification should also describe known limitations of the specification, such as frequency and time domain analysis at a network-adjacent node, or dependency on interceptible dereferencing mechanisms like the DNS. Currently we have millions of people using our protocols to defend themselves from aggressors, who typically have more reach into the infrastructure than the end users do. I know the utilization on my TOR exit relay has been 100% for several months now, so there are clearly people who understand enough of the problem to be attempting some sort of defense. And we have persons in authority who find open communication threatening and frequently shutting down access to parts of the net, such as LinkedIn, Facebook, Skype, Blackberry Messenger, or whatever they deem threatening on any given day. We can't keep them from turning off the whole Internet, but if we design protocols correctly, we can force them to choose between participating in the civilization of the Internet, ALL OF IT, or being completely isolated. If we do NOT act on this proposal, then our misguided leaders, censors, tyrants, and fools will continue to be able to piecemeal select which parts of the Internet they will allow, thereby manufacturing their own self-serving subsets of the truth. At the same time, criminals will continue to exploit protocol weaknesses to spam, spoof, steal, and subvert. And the Internet will not be the mechanism for
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
Am 06.03.2011 um 16:52 schrieb Marc Petit-Huguenin: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/04/2011 08:06 PM, Dean Willis wrote: I just came across what may be old news to many of you. The July 2007 issue of IEEE Spectrum included an article entitled The Athens Affair, subtitled How Some Extremely Smart Hackers Pulled Off The Most Audacious Cell-Network Break-in Ever. In short, perpetrators appear to have accessed the lawful-intercept component of mobile switches in-use, and were able to tap a lot of phones, including that of the Prime Minister of the host nation. Apparently this was made easier by the fact that the user-interface for the LI component had not yet been installed, making it possible for the interceptions to go undetected for some time. This is just an example of a maxim: if we build nefarious mechanisms into systems, SOMEBODY is going to abuse them. Otherwise said: If you build in a back-door, don't be surprised when somebody sticks something in it. Sure, any meathead can slap a microphone on a window, order the withdrawal of a bunch of BGP routes, or cut the power to a switching center. There's not a lot we can do about that. But we can do a lot about a wide variety of man in the middle attacks, if we're willing to step up and confront the bullies out there, along with the misguided who don't understand why security back-doors are a two-edged sword, as dangerous to themselves as to their opposition. Sure, everybody wants their systems to be secure and their opposition's systems less so, but in the real world, everybody is somebody's opposition. The only way to be safe is to have universal protections. Start by locking yourself out. If that works, then it MAY stop the bad guys too. So what can we do about it? Every document we now produce has a Security Considerations. I hereby propose the following extensions to that section, such that each specification requiring a meaningful Security Considerations section MUST address the following: 1) Privacy and Integrity: We believe that intermediaries should be neither able to understand nor alter the transmitted material without the explicit consent and awareness of the users. How are the principles of end-to-end privacy and integrity provided by the specification? Reasonable solutions might include any of our well- documented encryption and signature systems coupled with applicable key management mechanisms. Analysis within the specification should also describe the known limitations of the specification, such as susceptibility to hostile certificate authorities. Further, forthcoming IETF specifications MUST not allow plain-text transmission of anything within any protocol. Sign or cipher (or both, as appropriate) everything, all the time. 2) Privacy and Obscurity: We believe that observation of a traffic flow pr sequence of traffic flows should reveal as little information about the application or user of the application as possible to an intermediary who observes the traffic without the explicit consent and awareness of the user. In principle, deep packet inspection should be completely useless, as should attempts by an intermediary to trace the end-user(s) to a specific physical location. How does the specification provide for obscuring the content of the application and the identity and location of users involved in the sequence? Reasonable solutions might include things like TOR combined with TLS. Analysis within the specification should also describe known limitations of the specification, such as frequency and time domain analysis at a network-adjacent node, or dependency on interceptible dereferencing mechanisms like the DNS. Currently we have millions of people using our protocols to defend themselves from aggressors, who typically have more reach into the infrastructure than the end users do. I know the utilization on my TOR exit relay has been 100% for several months now, so there are clearly people who understand enough of the problem to be attempting some sort of defense. And we have persons in authority who find open communication threatening and frequently shutting down access to parts of the net, such as LinkedIn, Facebook, Skype, Blackberry Messenger, or whatever they deem threatening on any given day. We can't keep them from turning off the whole Internet, but if we design protocols correctly, we can force them to choose between participating in the civilization of the Internet, ALL OF IT, or being completely isolated. If we do NOT act on this proposal, then our misguided leaders, censors, tyrants, and fools will continue to be able to piecemeal select which parts of the Internet they will allow, thereby manufacturing their own self-serving subsets of the truth. At the same time, criminals will continue to exploit protocol weaknesses to spam, spoof, steal,
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
On Sun, Mar 6, 2011 at 10:52 AM, Marc Petit-Huguenin petit...@acm.orgwrote: I any case, may I suggest a Bar BOF in Prague? Plotting revolutions in coffeehouses is a very old tradition. I am told that http://www.cafeslavia.cz/ was a popular hangout for Czech revolutionaries. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Where to find IONs?
On 2011-03-07 00:15, Adrian Farrel wrote: Hi Mykyta, Please see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg04792.html Adrian One could argue that http://www.ietf.org/iesg/process-experiment.html should also contain pointers, or at least a status line, for concluded experiments. (It's my fault that it doesn't, since I created the original version of that page.) Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
Marc suggested: I any case, may I suggest a Bar BOF in Prague? Plotting revolutions in coffeehouses is a very old tradition. Excellent idea. Perhaps this should be plotted over jasmine tea instead of coffee... The point I really want to stress is that we must stop deliberately designing privacy, integrity, and obscurity weakness into our protocols, and where we can't avoid weakness we should at least consider its implications. We have a real lack of understanding of these issues in the community. For example, if Alice and Bob have a communications session, IETF has never clued onto the fact that Alice and Bob might want intermediary Charlie not jut to be unable to read the data of their session, but to not even be able to know that they have one. We might not be able to hide the fact that Alice has a session with SOMEBODY from her next-door neighbor Allen, or the fact that Bob has a session from his next-door neighbor Burt, but even if Allen and Burt are working together, we should be able to hide the Alice-Bob relationship. What do I mean by not designing weakness into our protocols? I give you SIP, for example. After twelve years of work, I have yet to make a real call using the optional sips signaling model. Why? It's optional. Nobody uses it. Actually, I'm having a hard time using even basic SIP any more -- it looks like Google just pulled-the-plug on my telephony ISP service, which had been provided by the Gizmo Project. But that's another problem. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2011 12:52 PM, Dean Willis wrote: Marc suggested: I any case, may I suggest a Bar BOF in Prague? Plotting revolutions in coffeehouses is a very old tradition. Excellent idea. Perhaps this should be plotted over jasmine tea instead of coffee... The point I really want to stress is that we must stop deliberately designing privacy, integrity, and obscurity weakness into our protocols, and where we can't avoid weakness we should at least consider its implications. We have a real lack of understanding of these issues in the community. For example, if Alice and Bob have a communications session, IETF has never clued onto the fact that Alice and Bob might want intermediary Charlie not jut to be unable to read the data of their session, but to not even be able to know that they have one. We might not be able to hide the fact that Alice has a session with SOMEBODY from her next-door neighbor Allen, or the fact that Bob has a session from his next-door neighbor Burt, but even if Allen and Burt are working together, we should be able to hide the Alice-Bob relationship. What do I mean by not designing weakness into our protocols? I give you SIP, for example. After twelve years of work, I have yet to make a real call using the optional sips signaling model. Why? It's optional. Nobody uses it. Actually, I'm having a hard time using even basic SIP any more -- it looks like Google just pulled-the-plug on my telephony ISP service, which had been provided by the Gizmo Project. But that's another problem. My very cynical view of this is that if encryption is one day available for every computer and devices, this will be so the cloud services can hide their activity siphoning all the privacy information from these devices. - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk10DhYACgkQ9RoMZyVa61d4cwCgk7G6QZV1s/FFa/DLhk1Y1B9o fCYAoJiKZuuAo5t8eCnOkqHieCfkL2rL =XA6v -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
Hi Dean, At 20:06 04-03-2011, Dean Willis wrote: I just came across what may be old news to many of you. The July 2007 issue of IEEE Spectrum included an article entitled The Athens Affair, subtitled How Some Extremely Smart Hackers Pulled Off The Most Audacious Cell-Network Break-in Ever. In short, http://spectrum.ieee.org/telecom/security/the-athens-affair/0 So what can we do about it? Every document we now produce has a Security Considerations. I hereby propose the following extensions to that section, such that each specification requiring a meaningful Security Considerations section MUST address the following: 1) Privacy and Integrity: We believe that intermediaries should be neither able to There is a mailing list at https://www.ietf.org/mailman/listinfo/ietf-privacy Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Where to find IETF recommendations?
On 3/2/11 5:45 AM, Shane Kerr wrote: Joel, On Tue, 2011-03-01 at 12:49 -0800, Joel Jaeggli wrote: in v6ops ops we have documents like: http://tools.ietf.org/id/draft-jankiewicz-v6ops-v4v6biblio-03.txt Cool, this is actually the document I was looking for when I started this thread - even if it doesn't have the logging recommendation draft too. :) cool, there are certain limitations to documenting the documents from within the document framework. but there's been a certain amount of effort that ammounts to that nonetheless. -- Shane ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
I am rather skeptical. At this point the secret is out and the potential of the Internet and the Web is rather too well understood. Documenting the privacy issues raised may well serve more to provide dictators with ideas than actionable advice and even if the recommendations are actionable there is no guarantee they will be acted on. We really need to progress from looking at the effects we wish to achieve and design technology that is designed to meet those ends. On Sun, Mar 6, 2011 at 10:52 AM, Marc Petit-Huguenin petit...@acm.orgwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/04/2011 08:06 PM, Dean Willis wrote: I just came across what may be old news to many of you. The July 2007 issue of IEEE Spectrum included an article entitled The Athens Affair, subtitled How Some Extremely Smart Hackers Pulled Off The Most Audacious Cell-Network Break-in Ever. In short, perpetrators appear to have accessed the lawful-intercept component of mobile switches in-use, and were able to tap a lot of phones, including that of the Prime Minister of the host nation. Apparently this was made easier by the fact that the user-interface for the LI component had not yet been installed, making it possible for the interceptions to go undetected for some time. This is just an example of a maxim: if we build nefarious mechanisms into systems, SOMEBODY is going to abuse them. Otherwise said: If you build in a back-door, don't be surprised when somebody sticks something in it. Sure, any meathead can slap a microphone on a window, order the withdrawal of a bunch of BGP routes, or cut the power to a switching center. There's not a lot we can do about that. But we can do a lot about a wide variety of man in the middle attacks, if we're willing to step up and confront the bullies out there, along with the misguided who don't understand why security back-doors are a two-edged sword, as dangerous to themselves as to their opposition. Sure, everybody wants their systems to be secure and their opposition's systems less so, but in the real world, everybody is somebody's opposition. The only way to be safe is to have universal protections. Start by locking yourself out. If that works, then it MAY stop the bad guys too. So what can we do about it? Every document we now produce has a Security Considerations. I hereby propose the following extensions to that section, such that each specification requiring a meaningful Security Considerations section MUST address the following: 1) Privacy and Integrity: We believe that intermediaries should be neither able to understand nor alter the transmitted material without the explicit consent and awareness of the users. How are the principles of end-to-end privacy and integrity provided by the specification? Reasonable solutions might include any of our well-documented encryption and signature systems coupled with applicable key management mechanisms. Analysis within the specification should also describe the known limitations of the specification, such as susceptibility to hostile certificate authorities. Further, forthcoming IETF specifications MUST not allow plain-text transmission of anything within any protocol. Sign or cipher (or both, as appropriate) everything, all the time. 2) Privacy and Obscurity: We believe that observation of a traffic flow pr sequence of traffic flows should reveal as little information about the application or user of the application as possible to an intermediary who observes the traffic without the explicit consent and awareness of the user. In principle, deep packet inspection should be completely useless, as should attempts by an intermediary to trace the end-user(s) to a specific physical location. How does the specification provide for obscuring the content of the application and the identity and location of users involved in the sequence? Reasonable solutions might include things like TOR combined with TLS. Analysis within the specification should also describe known limitations of the specification, such as frequency and time domain analysis at a network-adjacent node, or dependency on interceptible dereferencing mechanisms like the DNS. Currently we have millions of people using our protocols to defend themselves from aggressors, who typically have more reach into the infrastructure than the end users do. I know the utilization on my TOR exit relay has been 100% for several months now, so there are clearly people who understand enough of the problem to be attempting some sort of defense. And we have persons in authority who find open communication threatening and frequently shutting down access to parts of the net, such as LinkedIn, Facebook, Skype, Blackberry Messenger, or whatever they deem threatening on any given day. We can't keep them from turning off the whole Internet, but if we design protocols correctly, we can force them to choose between
IONs Report (was: Where to find IONs?)
Hello all, I've just made the Internet-Draft containing some summary on IONs experiment available. You may find it here: http://tools.ietf.org/html/draft-yevstifeyev-ion-report-00 Any comments and suggestions are welcome. All the best, Mykyta Yevstifeyev 06.03.2011 22:11, Brian E Carpenter wrote: On 2011-03-07 00:15, Adrian Farrel wrote: Hi Mykyta, Please see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg04792.html Adrian One could argue that http://www.ietf.org/iesg/process-experiment.html should also contain pointers, or at least a status line, for concluded experiments. (It's my fault that it doesn't, since I created the original version of that page.) Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RFC 6150 on MD4 to Historic Status
A new Request for Comments is now available in online RFC libraries. RFC 6150 Title: MD4 to Historic Status Author: S. Turner, L. Chen Status: Informational Stream: IETF Date: March 2011 Mailbox:turn...@ieca.com, lily.c...@nist.gov Pages: 10 Characters: 19583 Obsoletes: RFC1320 I-D Tag:draft-turner-md4-to-historic-11.txt URL:http://www.rfc-editor.org/rfc/rfc6150.txt This document retires RFC 1320, which documents the MD4 algorithm, and discusses the reasons for doing so. This document moves RFC 1320 to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6151 on Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms
A new Request for Comments is now available in online RFC libraries. RFC 6151 Title: Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms Author: S. Turner, L. Chen Status: Informational Stream: IETF Date: March 2011 Mailbox:turn...@ieca.com, lily.c...@nist.gov Pages: 7 Characters: 14662 Updates:RFC1321, RFC2104 I-D Tag:draft-turner-md5-seccon-update-08.txt URL:http://www.rfc-editor.org/rfc/rfc6151.txt This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
