RE: IETF privacy policy - update
I think is very likely (if not certain) that right now the IETF is operating in violation of the European Union's Data Protection Directive, nope, never while they're in the U.S. National data protection laws do not apply for someone operating entirely in a different country. I have no idea about to what extent the EU directive applies. But I would have thought it would be tricky to argue that the IETF is operating entirely in the US when it's about to meet and collect data in Maastricht. This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
In message aanlktillt7bxq7lkdn0r1g10q8ipnmbpgngz6owge...@mail.gmail.com, Phil lip Hallam-Baker writes: On Tue, Jul 20, 2010 at 12:12 AM, Mark Andrews ma...@isc.org wrote: In message aanlktikni86aoabgkib1_joeqe0ou4swpgrs8h1mb...@mail.gmail.com= , Phil lip Hallam-Baker writes: Being able to verify signatures is of no value. The system only has value when you can act differently according to whether the signature verifies or not. I keep asking, but nobody will tell me how I get the keys for my domains into the TLD. Firstly you get DS records into the TLD not DNSKEY records. Secondly it is/will be by a mechanism similar to how you get NS records into the TLD. In other words go ask your registrar when they are going to support adding DS records and stop complaining here. I am not asking about the TLD keys, I am asking about my keys. I will repeat myself. The parent zone has DS records added to it not DNSKEY records. Your keys are added to your zone so I presume you know how to update your zones. And I really hope that the mechanism for handling the name holder keys recognizes that registering a million keys is different to distributing a hundred where all the parties know each other personally. Well you know your parent or its agent (registrar). You hand the DS to them to publish. The rest of the world gets the DS from them. The only keys that have to be widely distributed are those for the root zone and that's a similar problem to distributing the list of root nameservers and their addresses. Millions of recursives server operators have managed that. You would not be saying go ask your registrar when they are going to support adding DS records if you didn't know that the answer was that the registrars have made no commitment to deploy. Well pick one that does. GoDaddy does accord to reports I've seen. There are others that also support DS records. Holding a key signing ceremony is not a new technological achievement. It is being held now with great fanfare in the hope that if everyone makes enough noise about how much momentum DNSSEC has that the opposition of the registrars will somehow disappear. No one said it would magically fix things. It does however remove one of the more common excuses people have been using to not do the could of minutes work that is required to turn on DNSSEC. I don't see why that strategy would work. I have certainly never seen it work in the past. We go complain to your registrar. Say you will take you business away unless they add support and do it when they don't. This is not a technological problem. It is a business problem between you, your registrar and the registry. You are an engineer. If the technology does not meet the business needs then you have failed. The technology is not the problem. It's getting the registrars to change their web forms to support adding DS records. That is the last step. EPP supports DS. The nameservers support DS. The clients support DS. Adding DS records is really no harder than adding NS, A and records that are required to make a delegation work. If DNSSEC is not going to fail we need to re-engineer it to propose a business model that actually works. Sitting on the sidelines and shouting 'the technology is perfect damit, go make the business model work', is not going to solve the problem. Nor is 'go away, my technology is perfect, perfect I tell you'. What has me very worried here are the comments to the effect 'the registrars are behind'. What if the registrars are not 'behind', what if they have no interest in deployment or are actively opposed but unable to say so openly while Cerf and co are saying that DNSSEC is the historic solution to solve the problem of Internet security? Except they arn't all against it. Some have already started accepting DS records. This is not a trivial issue. There is a question of liability to be addressed. So far ICANN and VeriSign Registry Services have addressed the issue by booting it down the chain. But the system as a whole cannot work until there is someone willing to accept the liability and for that to happen they are going to require tools to manage their litigation risk. How is the liability different from that of accepting NS records? DS records don't magically change the liability. Stuffing up either NS or DS records will break the delegation. Yes they do. An NS record specifies the address of the DNS server No. It specifies the NAME of a nameserver. A/ records specify the addresses. A DS record specifies an intermediate certificate in the chain of trust for authenticating any entity that is attached to the domain. And a registrar should be treating changes to NS, A, and DS records with a equal level of respect. They shouldn't be accepting changes from anybody. They should already be doing the level of checking needed for DS records for NS, A and
WG Review: Authority to Citizen Alert (ATOCA)
A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, July 27, 2010. Authority to Citizen Alert (ATOCA) -- Current Status: Proposed Working Group Last Modified: 2010-07-15 Chairs(s) TBD Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo gonzalo.camari...@ericsson.com Robert Sparks rjspa...@nostrum.com Real-time Applications and Infrastructure Area Advisor: Robert Sparks rjspa...@nostrum.com Mailing Lists: General Discussion: earlywarn...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/earlywarning Archive: http://www.ietf.org/mail-archive/web/earlywarning Real-time Applications and Infrastructure Area Advisor: Robert Sparks rjspa...@nostrum.com Description of Working Group: There are a variety of mechanisms that authorities have available to notify citizens and visitors during emergency events. Traditionally, they have done so with broadcast networks (radio and television). For commercial mobile devices, broadcasting services such as the Public Warning System (PWS), the Earthquake and Tsunami Warning System (ETWS), and the Commercial Mobile Alert System (CMAS) are standardized and are in various stages of deployment. The Internet provides another way for authority-to-citizen alerts to be sent, but it also presents new challenges. While there are some existing layer 2 mechanisms for delivering alerts, the work in this group focuses on delivering alerts to IP endpoints only. The general message pattern that this group is intended to address is the sending of alerts from a set of pre-authorized agents (e.g., governmental agencies) to a large population without impacting layer 2 networks (e.g. causing congestion or denial of service). The goal of this group is not to specify how originators of alerts obtain authorization, but rather how an ATOCA system can verify authorization and deliver messages to the intended recipients. A critical element of the work are the mechanisms that assure that only those pre-authorized agents can send alerts via ATOCA, through an interface to authorized alert distribution networks (e.g., iPAWS/DM-Open in the U.S.). The ATOCA effort is differentiated from and is not intended to replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the recipients of ATOCA alerts are the wide range of devices connected to the Internet and various private IP networks, which humans may have at hand to get such events, as well as automatons who may take action based on the alerts. This implies that the content of the alert contains some information, which is intended to be consumed by humans, and some which is intended to be consumed by automatons. Ideally, the alerts would contain, or refer to media other than text media (e.g., audio and/or video). The initial work in the group is focused on small messages, which may be mechanically rendered by the device in other forms (text to speech for example). Future work in the group may investigate rich media. In situations of a major emergency there could be scenarios where there are multiple alerts generated that may require that a priority mechanism (defined by alert originator policy) has to be used. The work on a resource priority mechanism is out of scope of the initial charter, but may be revisited at a later date. Which devices should get alerts is primarily driven by location. The first set of recipients that must be catered for are those within the area identified by the alert originator to be affected by the emergency event. In many jurisdictions, there are regulations that define whether recipients/devices within the affected area have opt-in or opt-out capability, but the protocols ATOCA will define will include both opt-in and opt-out mechanisms. The group will explore how to support both opt-in and opt-out at the level of communication protocols and/or device behavior. Another class of recipients that are in scope of the work are explicit opt-in subscriptions which ask for alerts for a specified location, not necessarily the physical location of the device itself. An example of such a subscription would be 'send me alerts for location x' (previously determined as the location of interest). This work may build on existing IETF GEOPRIV location work. There are efforts in other fora on early warning, which will be considered in this effort. For example, we expect to make use of the OASIS Common Alerting Protocol (CAP) for the encoding of alerts. OGC, ATIS, TIA, ITU-T, ETSI and 3GPP also have alert efforts underway, and consultation with these efforts will be undertaken to avoid unnecessary duplication of effort and also to avoid
RFC 5901 on Extensions to the IODEF-Document Class for Reporting Phishing
A new Request for Comments is now available in online RFC libraries. RFC 5901 Title: Extensions to the IODEF-Document Class for Reporting Phishing Author: P. Cain, D. Jevans Status: Standards Track Stream: IETF Date: July 2010 Mailbox:pc...@coopercain.com, dave.jev...@antiphishing.org Pages: 51 Characters: 97325 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-cain-post-inch-phishingextns-07.txt URL:http://www.rfc-editor.org/rfc/rfc5901.txt This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 to support the reporting of phishing events, which is a particular type of fraud. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle -- from receipt of the phishing lure to the disablement of the collection site. Both simple reporting and complete forensic reporting are possible, as is consolidating multiple incidents. [STANDARDS TRACK] This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. 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 5930 on Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol
A new Request for Comments is now available in online RFC libraries. RFC 5930 Title: Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol Author: S. Shen, Y. Mao, NSS. Murthy Status: Informational Stream: IETF Date: July 2010 Mailbox:shens...@cnnic.cn, yum...@gmail.com, ssmurthy.nitt...@freescale.com Pages: 6 Characters: 12217 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ipsecme-aes-ctr-ikev2-07.txt URL:http://www.rfc-editor.org/rfc/rfc5930.txt This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit Initialization Vector, by the Internet Key Exchange version 2 (IKEv2) protocol, for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. 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
