Re: Last Call: draft-ietf-dnsext-axfr-clarify (DNS Zone Transfer Protocol (AXFR)) to Proposed Standard
At 11:00 22-02-10, The IESG wrote: The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'DNS Zone Transfer Protocol (AXFR) ' draft-ietf-dnsext-axfr-clarify-13.txt as a Proposed Standard ... In Section 2.2.5: The contents of this section MUST follow the guidelines for EDNS0 and TSIG, SIG(0), or whatever other future record is possible here. Does the MUST apply to guidelines specified after the publication of this document? Regards, -sm Yes. Kind regards, Alfred. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard
I have commented numerous times that with a paragraph that specifically provides vendors to make connection-less resets == attack packets this will not get much if any use among ISPs or other bgp speakers. Those statements have pretty much been ignored. I do not support this draft and believe I have wasted my time trying to explain why to someone that is unwilling to compromise with even a a vendor MAY maintain state to allow connectionless resets to work. (coffee != sleep) (!coffee == sleep) donald.sm...@qwest.com gcia -Original Message- From: tcpm-boun...@ietf.org [mailto:tcpm-boun...@ietf.org] On Behalf Of The IESG Sent: Wednesday, February 24, 2010 10:25 AM To: IETF-Announce Cc: t...@ietf.org Subject: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'The TCP Authentication Option ' draft-ietf-tcpm-tcp-auth-opt-10.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-03-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-o pt-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=vie w_iddTag=16685rfc_flag=0 ___ tcpm mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/tcpm This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard
Hi Wesley, I stand red faced and corrected. The last version I saw did not address this (I think that was either 08 or 09) and I assumed the .10 didn't either. I withdraw my objection and apologize for having missed this significant rewrite!! (coffee != sleep) (!coffee == sleep) donald.sm...@qwest.com gcia -Original Message- From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] [mailto:wesley.m.e...@nasa.gov] Sent: Friday, February 26, 2010 4:18 PM To: Smith, Donald; 'ietf@ietf.org' Cc: 't...@ietf.org' Subject: RE: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard Hi Donald, as the document shepherd, I need to set the record straight on this, as your statement is simply false. In checking that the WGLC comments had been handled in the following document update, I looked at both the email thread you participated in and the updated document. In this case, the editor very clearly responded to your inputs and made significant changes to the document. You can find an entirely new section (9.7 Connectionless Resets) starting in version 09 of the draft, which specifically responds to your comments with resolutions that were discussed on the mailing list. This section discusses maintenance of the traffic keys across reboots which answers your concern and makes the practice a SHOULD which is stronger even than the MAY that you mention below. I do not understand why you feel like your inputs were ignored, but I hope that you'll agree that this was not the case. From: tcpm-boun...@ietf.org [tcpm-boun...@ietf.org] On Behalf Of Smith, Donald [donald.sm...@qwest.com] Sent: Friday, February 26, 2010 2:45 PM To: 'ietf@ietf.org'; 'IETF-Announce' Cc: 't...@ietf.org' Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (TheTCP Authentication Option) to Proposed Standard I have commented numerous times that with a paragraph that specifically provides vendors to make connection-less resets == attack packets this will not get much if any use among ISPs or other bgp speakers. Those statements have pretty much been ignored. I do not support this draft and believe I have wasted my time trying to explain why to someone that is unwilling to compromise with even a a vendor MAY maintain state to allow connectionless resets to work. (coffee != sleep) (!coffee == sleep) donald.sm...@qwest.com gcia -Original Message- From: tcpm-boun...@ietf.org [mailto:tcpm-boun...@ietf.org] On Behalf Of The IESG Sent: Wednesday, February 24, 2010 10:25 AM To: IETF-Announce Cc: t...@ietf.org Subject: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'The TCP Authentication Option ' draft-ietf-tcpm-tcp-auth-opt-10.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-03-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-o pt-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=vie w_iddTag=16685rfc_flag=0 ___ tcpm mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/tcpm This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ tcpm mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/tcpm This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-harkins-emu-eap-pwd (EAP Authentication Using Only A Password) to Informational RFC
I am submitting one comment on draft-harkins-emu-eap-pwd : (1) Channel bindings are becoming increasingly necessary for new and evolving uses of EAP. This EAP-PWD protocol should provide for them. Dorothy Stanley Dorothy Stanley Aruba Networks dstan...@arubanetworks.com 630-363-1389 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Who are these 'security researchers' of whom you speak? I am a principal in the security field, if you want to contradict me then you should either say that something is your personal opinion or you should specify the other parties you are referring to. The reason that I want to see what the key registration process is going to look like is precisely because the validation process matters. It is the reason that I sent out the invitations to the original meeting that started the process that created EV certificates. Moving to DNSSEC, regardless of the technical model does not eliminate the need for certificates or CAs. The purpose of EV certificates is to re-establish the principle of accountability. You can design a PKI to meet many different needs. Identity is one purpose, but not a very useful one. Which is the real reason that identity systems are so hard to deploy. If you want security from a PKI you will do better with a validation system that provides accountability. I use words very carefully. I know that you can use SSH keys protected by DNSSEC. But at the moment there is not a complete proposal for a Secure DNS system. Key parts of that system are being left to chance and that is why the prospects for an alternative system are much better than you imagine. On Thu, Feb 25, 2010 at 11:55 AM, Paul Wouters p...@xelerance.com wrote: On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote: But SSH would be much better if we could integrate the key distribution into a secured DNS. See previous post. Already done and running. And self-signed SSL certs would be better if we could use hash values distributed through a secured DNS to verify them. Yes. The CERT/CERTQ record is still a bit of a problem and needs some work. If DNSSEC succeeds, the domain validated certificate business will have to either transform or eventually die. I think that for most CAs, the business opportunities from SSL+DNSSEC are greater than the opportunities from the current DV SSL business. DNSSEC cannot deploy unless the registrars have cryptography expperience, the CAs have that experience. If you ask security researchers, it has been proven that CA's sacrificed security for profitability. The CA model has failed to work. 2 second validation based on email, md5 based * root certificates signed, etc etc. The last two years saw a significant amount of attacks against CA's, and CA's have seen their profit margin fall to near zero, so even if they wanted to, they cannot increase security (you ask me a confirmation for my cert, I'll go to this other ssl provider that doesn't). CERT's in DNS(SEC) put the responsibility of the cert within the domain of the customer. If they care, they can do their security. The time of outsourcing security to CA's is over. Paul -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Some CAs sacrificed security for profitability. Which was the reason I started the EV process. If the race to the bottom had continued the products we sold would have no value at all. Getting your root into a browser requires you to get a WebTrust audit against your CPS. The problem is that before EV there were no requirements for the CPS. So long as your process said 'I do absolutely nothing at all', you could get your WebTrust audit. Some of the browser providers impose other requirements, but none addressed the validation criteria until EV was created. http://technet.microsoft.com/en-us/library/cc751157.aspx The only thing that was holding the system together was the fact that the older browsers could not update their root stores. So new CAs could only get a start by paying to cross-certify with an existing root. And all the roots that were inserted pre-Web Trust had been required to provide a CPS that actually committed them to do something with at least some meaning. That is why it costs more to get your CA cross-signed by some roots than others, those that promised least can command the highest prices. At this stage there are far fewer older browsers due to natural attrition and the older roots timing out. And at the end of this year Microsoft is going to pull the 1024 bit roots from the program. That is a good thing from the crypto point of view but will eliminate the last vestiges of control in the DV market unless something is done. I would like to deploy DNSSEC for the same reasons that you give. The problem is that at the moment it runs straight into a buzz-saw of global international politics. That is in the process of being fixed. On Thu, Feb 25, 2010 at 3:18 PM, Shumon Huque shu...@isc.upenn.edu wrote: On Thu, Feb 25, 2010 at 11:55:03AM -0500, Paul Wouters wrote: On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote: If DNSSEC succeeds, the domain validated certificate business will have to either transform or eventually die. I think that for most CAs, the business opportunities from SSL+DNSSEC are greater than the opportunities from the current DV SSL business. DNSSEC cannot deploy unless the registrars have cryptography expperience, the CAs have that experience. If you ask security researchers, it has been proven that CA's sacrificed security for profitability. The CA model has failed to work. 2 second validation based on email, md5 based * root certificates signed, etc etc. The last two years saw a significant amount of attacks against CA's, and CA's have seen their profit margin fall to near zero, so even if they wanted to, they cannot increase security (you ask me a confirmation for my cert, I'll go to this other ssl provider that doesn't). I'll refrain from inserting the obligatory Matt Blaze CA quote here :-) The time of outsourcing security to CA's is over. Paul Exactly. What many of us would like to see is the ability for enterprises to issue X.509 certificates themselves for their own application services. If we're going to have a global PKI, the way I think it should work is that CA's higher up in the hierarchy should certify CA's below them (enterprises or some trusted intermediaries) using 'name constraint's so that the subordinate CA's can only issue certificates for subject identities in the namespace for which they have authority. And ideally the higher level CAs should be multi-lateral non-profits, rather than states or for-profit corporations engaged in a collective race to the bottom. The current situation with commercial CAs is beyond horrible. Just take a look at how many root CAs are embedded in your favorite browser, and with virtually no constraints on the name space in which they can issue certs. Do you really trust all of them? Any of them, whether by malice or by being tricked, can issue a certificate for any of your services. Our security is basically as good as the the CA with the laxest policies worst security. And in terms of functionality, they are woefully inadequate too. Most of them can only issue certs for hostnames in subject or subject alternative name dnsname fields. What if I want to deploy a certificate with other types of extension fields to better compartmentalize security or to enable new functionality, eg. URI, SRVName, a custom SAN, or application-service specific EKU fields? Allowing organizations to issue their own certificates allows them to deploy security infrastructure that actually addresses their needs. Perhaps it's wishful thinking, but I kinda look forward to the day that DNSSEC is widely deployed. I look forward to using SSHFP, IPSECKEY, and (a better version of) CERT to displace the broken Internet PKI .. --Shumon. -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Once you have established an SSH relationship the protocol allows you to determine with a high degree of confidence that you are connecting to the same end point in future. That is not a perfect security control but it is a very useful one. It is a much more useful control than any provided by infrastructure that is not deployed. On Fri, Feb 26, 2010 at 3:58 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Phillip Hallam-Baker wrote: SSH is not a bad security protocol. It provides a very high level of protection against high probability risks with little or no impact on the user. There is a narrow window of vulnerability to a man in the middle attack. As a security researcher, I can teach you that the security you observe is not of SSH but of return routability. Return routability over many third party ISPs is not 'verifiable', of course. Masataka Ohta -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
ietf 1id_guidelines tool broken
As of Feb 9th, the IESG posted a second status boilerplate. But the tool doesn't yet recognize it Be warned. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ietf 1id_guidelines tool broken
Henrik Levkowetz wrote: On 2010-02-26 20:42 William Allen Simpson said the following: As of Feb 9th, the IESG posted a second status boilerplate. But the tool doesn't yet recognize it Be warned. Specifics, please? * Is this the idnits tool or some other tool? * Which version did you use? Whatever the IETF Secretariat is using. * Did you use the downloaded script or the web-service, and if so, with which URL? * Which boilerplate change specifically isn't recognized? I.e., what is your input? http://www.ietf.org/ietf-ftp/1id-guidelines.txt I-D Guidelines R. Housley (for the IESG) Vigil Security 9 February 2010 In the modern Internet, the need for stable URLs is more important than providing multiple sites around the world to obtain I-Ds. Also, search engines have replaced the need for a file containing a collection of I-D abstracts. As a result, the second choice is: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress. * What is the output of the tool, given your input? ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? 1id_guidelines, paragraph 1: Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. ... text found in draft: Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working ..^ documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current.; ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. 1id_guidelines, paragraph 3: The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html; ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. 1id_guidelines, paragraph 4: The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html; ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ietf 1id_guidelines tool broken
Henrik Levkowetz wrote: The short response to the information below is that it seems that the secretariat is still running version 2.12.00 of idnits, while the newer version 2.12.01 (released 4 Feb 2010) accepts the new boilerplate correctly. I'm notifying the secretariat so they can update to the newest version. --- The longer response is that diagnosing this required much more time than would have been required if all the requested and available information had been supplied below (instead of flippancy); further comments inline: On 2010-02-27 00:03 William Allen Simpson said the following: Henrik Levkowetz wrote: On 2010-02-26 20:42 William Allen Simpson said the following: As of Feb 9th, the IESG posted a second status boilerplate. But the tool doesn't yet recognize it Be warned. Specifics, please? * Is this the idnits tool or some other tool? * Which version did you use? Whatever the IETF Secretariat is using. Not particularly helpful. The program version is indicated on the first line of its output. It would have been good if you'd provided the full output below, instead of snipping away part of it. I forwarded you the full output section that was sent to me by the IETF Drafts Team internet-dra...@ietf.org. There is no version. The sentence before was Please let me know if you have any questions. The line after was Sincerely, Obviously, that was all boilerplate. When I called her, Stephanie had no idea that there was a problem. Her hands were tied. * What is the output of the tool, given your input? As indicated earlier, what you provide here is only part of the output, and you've managed to snip away the part which would have made the actual problem obvious without detective work. You are incorrect. Get off your high horse. You should have notified the secretariat of the version change weeks ago. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ietf 1id_guidelines tool broken
Henrik Levkowetz wrote: Your initial 'bugreport' contained no specifics whatsoever. You inappropriately sent the 'tool is broken' message to the whole IETF general discussion list, in addition to addressing me directly (so it's not as if you didn't know where to direct a bug report). All IETF draft submitters need to know promptly, as Monday is the deadline for -00 version internet-drafts. It took some time (2 hours) to figure out that you had written the tool that generated the bad output, as the secretariat does not put your name (nor the tool name nor the version number) in their response message. I'm regretting wasting my time (finding you). And you probably shouldn't increment the .trivial for such a huge change. That was really a major change (as was 1id_guidelines itself). Maybe that's the reason the secretariat didn't think it was important enough to install. All of the above earns you no respect with me, and that colours my responses. Next time, send a bug report to the secretariat or to me directly, containing specifics that lets us *fix* the problem, rather than blazoning an unspecific and unhelpful 'Things don't work' message across the sky, and you might get a different tone back. It was reported to the secretariat directly ~13:53 EST by 'phone, but could not be fixed promptly. AFAICT, it's still not updated! http://tools.ietf.org/tools/idnits/ At this very moment: Version: 2.12.00 Author: Note the author is missing here, too. Also, the verbose output doesn't count line lengths correctly. Apparently, it is including the non-printing FF in the count. Not good. sarcasm Also, this was somewhat amusing: ** Obsolete normative reference: RFC 1700 (ref. 'RFC 3232') (Obsoleted by RFC 3232) Outstanding! Fails on the reference to RFC 1700 in the *title* of the RFC 3232 reference that obsoleted RFC 1700: 1432 [RFC 3232] Reynolds, J., Assigned Numbers: RFC 1700 is Replaced by 1433 an On-line Database, January 2002. /sarcasm At least the secretariat was smart enough to know that ** pseudo-error was bogus, and didn't include it in their message to me. As I wrote previously, get off your high horse. We really don't need the attitude Next time, test to see that your own code was installed and actually works. It's obvious that you never tested much of anything. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ietf 1id_guidelines tool broken
Henrik Levkowetz wrote: So you're still maintaining that it's good and right to send out a notice of a problem widely and provide no information which makes it possible to resolve it? Bah! Please stop before you embarrass yourself further. The original report was very clear: As of Feb 9th, the IESG posted a second status boilerplate. Indeed, the new Feb 9th status section itself is clearly written with the word second. (I've also sent you the *entire* section as written.) But the tool doesn't yet recognize it *PROVEN*, as of yesterday, and you admit farther down this message that some (many/most) servers weren't running the needed updated software. Given the secretariat message doesn't identify the tool or the version, you had *all* the information that was sent me by the secretariat. You're not duplicating what I've been saying. The tool *was* installed on February 4th. Somewhere there's been a slip-up, but translating that into evaluation of importance is nonsense. No, it wasn't. At least, not on the server the secretariat was using, nor on the server that I accessed a day later. Two strikes. AFAICT, it's still not updated! http://tools.ietf.org/tools/idnits/ At this very moment: Version: 2.12.00 Ooh, that's not good. The .01 version is only available on some of the tools servers, not all. Fixed. Author: Note the author is missing here, too. Funny. I see my name quite clearly on the web page there. Still missing. Apparently, somebody thought that field should be displayed with javascript, which no security-minded person runs. Also, the verbose output doesn't count line lengths correctly. Apparently, it is including the non-printing FF in the count. Not good. Same problem with idnits 2.12.01 sarcasm Also, this was somewhat amusing: ** Obsolete normative reference: RFC 1700 (ref. 'RFC 3232') (Obsoleted by RFC 3232) Outstanding! Fails on the reference to RFC 1700 in the *title* of the RFC 3232 reference that obsoleted RFC 1700: I'm afraid I can't comment on this, as the error message is based on the content of the reference entry in your document, which you've not seen fit to provide, although I requested it in my first note. 1432 [RFC 3232] Reynolds, J., Assigned Numbers: RFC 1700 is Replaced by 1433 an On-line Database, January 2002. /sarcasm And yet, you don't seem to be able to read the entry provided before your very eyes. That's it. Try it in your own testbed. Or wait for the internet-draft to be posted, and test it then. It would be obvious to you if you'd looked at the idnits report of your own submission that idnits *had* been installed: https://datatracker.ietf.org/idst/display_idnit.cgi?submission_id=21622 That is a URL you have apparently made up to access your tool. Of course it works as you desire, and accesses the appropriate tool version (today). Prior to your message, there was never any indication such a URL exists. The URL provided by the secretariat in an email on Feb 25th was: I-D Submission Tool URL: https://datatracker.ietf.org/idst/status.cgi?submission_id=21622 At this moment in time today, that still doesn't work: blockquote Your request was not processed due to the following error(s): Error - Draft is not in an appropriate status for the requested page /blockquote I have no idea what that means ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review for draft-ietf-ipsecme-esp-null-heuristics-05.txt
Spencer Dawkins writes: I don't feel strongly about this, but do suggest s/uses the same policy/uses the same policy, and that changes to that single policy can be coordinated throughout the administrative domain/, to capture what you said in your response, which I found helpful. Changed that sentence as you suggested and the full sentence is now: Also, such a solution might require some kind of centralized policy management to make sure everybody in an administrative domain uses the same policy, and that changes to that single policy can be coordinated throughout the administrative domain. I saw that this isn't a 2119 document, but it's hard for people who are familiar with 2119 language to ignore the words when they are in lower case :D I really liked the explanation you gave in your response here. I suggest picking one of can/will/should, probably can, and including your response in the document. The resulting text (with some additional edits) might look something like As ESP-NULL heuristics need to know the same protocols as a deep inspection device, an ESP-NULL instance of an unknown protocol can be handled the same way as a cleartext instance of the same unknown protocol. Changed to the text you suggested. OK, that's the part that was missing for me. I would suggest the packet has already transited a NAT box which changed the IP addresses but assumed any ESP payload was encryped and did not recalculate the transport checksums with the new IP addresses. Thus Made the changes you requested, but used fix instead recalculate as most of the nats do not recalculate checksum, but do incremental update on it. The whole text section is now: The most obvious field, TCP checksum, might not be usable, as it is possible that the packet has already transited a NAT box which changed the IP addresses but assumed any ESP payload was encrypted and did not fix the transport checksums with the new IP addresses. Thus the IP numbers used in the checksum are wrong, thus the checksum is wrong. This explanation is helpful. I'd suggest adding This hueristic is most helpful when only one packet is outstanding. For example, if a TCP SYN packet is lost, the next packet would always be a retransmission of the SYN packet. Changed (with minor edits) as you suggested. The full text is now: One good method of detection is if a packet is dropped then the next packet will most likely be a retransmission of the previous packet. Thus if two packets are received with the same source, and destination port numbers, and where sequence numbers are either same or right after each other, then it's likely a TCP packet has been correctly detected. This heuristics is most helpful when only one packet is outstanding. For example, if a TCP SYN packet is lost (or dropped because of policy), the next packet would always be a retransmission of the same TCP SYN packet. Your explanation was very helpful. I'd suggest Forcing use of ESP-NULL everywhere inside the enterprise, so that accounting, logging, network monitoring, and intrusion detection all work, increases the risk of sending confidential information where eavesdroppers can see it Changed to use your text. I updated the draft and submitted 06 version which includes these changes. -- kivi...@iki.fi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
I just want to remind everyone that a DNScurve draft is on the table. http://tools.ietf.org/html/draft-dempsky-dnscurve-01 There is an urgent need to solve the DNS security issues within a reasonable period of time. Please remember the Kaminsky dns bug did not identify a security problem with the DNS but the UDP transport. DNScurve fixes the problem today without having to spend 15 more years getting it right. And it does not cost a fortune to implement. DNSSEC is more of a make work project then it is a solution. And DNSSEC does not solve the UDP issue. And that is the problem DNScurve fixes NOW. If there is any common sense left at the IETF. And I think there are sparks here and there. Then I strongly recommend IETF members get DNScurve established as RFC. We need leadership - not more DNSSEC blah blah blah. Together let's exercise some common sense and support draft-dempsky-dnscurve-01. regards joe baptista On Thu, Feb 25, 2010 at 3:01 PM, Phillip Hallam-Baker hal...@gmail.comwrote: Who are these 'security researchers' of whom you speak? I am a principal in the security field, if you want to contradict me then you should either say that something is your personal opinion or you should specify the other parties you are referring to. The reason that I want to see what the key registration process is going to look like is precisely because the validation process matters. It is the reason that I sent out the invitations to the original meeting that started the process that created EV certificates. Moving to DNSSEC, regardless of the technical model does not eliminate the need for certificates or CAs. The purpose of EV certificates is to re-establish the principle of accountability. You can design a PKI to meet many different needs. Identity is one purpose, but not a very useful one. Which is the real reason that identity systems are so hard to deploy. If you want security from a PKI you will do better with a validation system that provides accountability. I use words very carefully. I know that you can use SSH keys protected by DNSSEC. But at the moment there is not a complete proposal for a Secure DNS system. Key parts of that system are being left to chance and that is why the prospects for an alternative system are much better than you imagine. On Thu, Feb 25, 2010 at 11:55 AM, Paul Wouters p...@xelerance.com wrote: On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote: But SSH would be much better if we could integrate the key distribution into a secured DNS. See previous post. Already done and running. And self-signed SSL certs would be better if we could use hash values distributed through a secured DNS to verify them. Yes. The CERT/CERTQ record is still a bit of a problem and needs some work. If DNSSEC succeeds, the domain validated certificate business will have to either transform or eventually die. I think that for most CAs, the business opportunities from SSL+DNSSEC are greater than the opportunities from the current DV SSL business. DNSSEC cannot deploy unless the registrars have cryptography expperience, the CAs have that experience. If you ask security researchers, it has been proven that CA's sacrificed security for profitability. The CA model has failed to work. 2 second validation based on email, md5 based * root certificates signed, etc etc. The last two years saw a significant amount of attacks against CA's, and CA's have seen their profit margin fall to near zero, so even if they wanted to, they cannot increase security (you ask me a confirmation for my cert, I'll go to this other ssl provider that doesn't). CERT's in DNS(SEC) put the responsibility of the cert within the domain of the customer. If they care, they can do their security. The time of outsourcing security to CA's is over. Paul -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ 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: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Mar 1, 2010, at 8:34 AM, Joe Baptista wrote: Please remember the Kaminsky dns bug did not identify a security problem with the DNS but the UDP transport. The problem Dan Kaminsky exploited is a known weakness in the DNS protocol, specifically that a 16-bit identifier space is too small. DNScurve fixes the problem today without having to spend 15 more years getting it right. Not really. Ignoring for the moment that there is a limited amount of deployed software that supports DNScurve, DNScurve addresses the DNS protocol problem by protecting the channel of communication. It doesn't actually protect DNS data. And it does not cost a fortune to implement. How much did it cost you to implement DNScurve? DId you make your code open source or otherwise available? And DNSSEC does not solve the UDP issue. Actually, DNSSEC does address the DNS protocol issue by ensuring any modification to DNS data can be identified. In the DNSSEC world, it no longer matters how you get the DNS data or what channel the data comes over or how secure that channel is. The same is not true of DNScurve. And that is the problem DNScurve fixes NOW. DNSSEC is already deployed in 12 top-level domains and the root is in the process of being signed. Multiple interoperable implementations of DNSSEC exist in production software. Together let's exercise some common sense and support draft-dempsky-dnscurve-01. As has been pointed out on several occasions, DNSSEC and DNScurve are not mutually exclusive. Of course, if you implement DNSSEC, the protections provided by DNScurve are superfluous (and the opposite isn't true), but that doesn't stop anyone from deploying both. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Mon, 1 Mar 2010, David Conrad wrote: DNSSEC is already deployed in 12 top-level domains Add a half for .uk :-) It has a deliberately invalid DNSKEY this week, full deployment next week. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Mon, 1 Mar 2010, Tony Finch wrote: DNSSEC is already deployed in 12 top-level domains Add a half for .uk :-) It has a deliberately invalid DNSKEY this week, full deployment next week. There is more then the 12 in itar. From the top of my head: .br .us .museum and .pt, and of course a large part of the reverse (all RIPE zones) and ENUM. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF Workshop on Broadband Home Gateways
During the 76th IETF meeting, the Transport Area sponsored a Broadband Home Gateway BoF, called HOMEGATE. Since that time, interested IETF participants have been working to narrow the scope of the draft charter and to reach out to other Standards Development Organizations (SDOs) to ensure that the planned work is complimentary and not overlapping with their respective work. To further that goal, the IETF's Transport and Internet Areas intend to co-sponsor a two-day workshop on HOMEGATE between IETF-77 and IETF-78. This workshop is slated to take place on April 20-21, 2010 in London, England. In order to reserve a properly sized meeting facility, it is important for interested people to indicate their interest in attending AS SOON AS POSSIBLE. Please do so at http://event.pingg.com/HomeGateLondonMtg NOTE: Due to potential venue limitations and the desire to allow participants from different stakeholder groups to be represented, physical attendance may need to be limited. Attendance will be confirmed at a later time (and certainly early enough for people to book reasonably priced travel accommodations). Remote listening or participation facilities of some sort will be available to all. PLEASE INDICATE YOUR INTEREST NOW if you wish to attend this interim meeting in person: http://event.pingg.com/HomeGateLondonMtg In addition: - You can find the HOMEGATE wiki at http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE - You should join the HOMEGATE mailing list at https://www.ietf.org/mailman/listinfo/homegate Thank you in advance for your interest and participation! Regards, Lars Eggert Magnus Westerlund, Transport Area Directors Jari Arkko Ralph Droms, Internet Area Directors ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Phillip Hallam-Baker wrote: Moving to DNSSEC, regardless of the technical model does not eliminate the need for certificates or CAs. The purpose of EV certificates is to re-establish the principle of accountability. I don't know what EV means, but anything human, including CA, is not infallible, which is why PKI is insecure. Is EV divine? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Mon, Mar 1, 2010 at 2:13 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Phillip Hallam-Baker wrote: Moving to DNSSEC, regardless of the technical model does not eliminate the need for certificates or CAs. The purpose of EV certificates is to re-establish the principle of accountability. I don't know what EV means, but anything human, including CA, is not infallible, which is why PKI is insecure. = Can you please explain in few lines what would be your preference(s) for a solution to enable DNSsec? I apologize if you have already submitted a proposal about it which I must have missed... in which case, I would appreciate a pointer. Regards, Wassim H. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
PKIgate
Phillip Hallam-Baker wrote: You can design a PKI to meet many different needs. No, PKI can be designed for imaginary needs only with no real security. Identity is one purpose, but not a very useful one. It is an example of imaginary security. If you want security from a PKI you will do better with a validation system that provides accountability. Real accountability needs a real account with real *M*O*N*E*Y* in it. If you loss $1M by a wrong operation of a CA, the CA should be able to compensated the amount of the loss, which is the accountability. *M*O*N*E*Y* is the reality. Then, what if, a wrong operation of a CA causes $1000 loss for 1M people? Bankruptcy of the CA does not help the people. A CA charging $2000 for 1M certificates may have $10 in its account and may be able to compensate $1000 loss of 1M people. But, what the point of people paying $2000, only to receive $1000 compensation? It's better for the people not to pay anything to the CA. What if, if the loss is $1M loss for 1M people? The only thing serious CAs can do is to make the possibility of wrong operation absolute ZERO, which is not human and costs infinite amount of money, which makes the CAs not profitable. On the other hand, less serious CAs do little, if not nothing, and just sell imaginary security at low cost to people who really need real security. That's how PKI is designed and CAs work. PKI is a system of fraud. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Patent disclosure in draft-shin-augmented-pake-00.txt
Hi. This document [1] contains the following section: 6. Intellectual Property The National Institute of Advanced Industrial Science and Technology (AIST) has submitted a patent application about the AugPAKE protocol, described in this document. For details of the patent application and its status, please contact the authors of this document. That by itself does not fulfill the IETF procedures regarding patent disclosure. Please read section 6.1 of RFC 3979: http://tools.ietf.org/html/rfc3979#section-6.1 Searching for a patent disclosure on this document suggests that none has been filed (yet): https://datatracker.ietf.org/ipr/search/?option=document_searchdocument_search=draft-shin-augmented-pake Therefor you need to file the proper patent disclosure for your submission to comply with the IETF rules. To make your technology benefit Internet applications everywhere, please consider licensing your patent in a liberal way. One example what I believe is a friendly patent license would be this one: https://datatracker.ietf.org/ipr/941/ Writing a patent license in friendly way is complicated, if you are interested I can work with you and the Free Software Foundation or the Software Freedom Law Center to help you write a good license. Thanks, /Simon [1] http://www.ietf.org/internet-drafts/draft-shin-augmented-pake-00.txt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
Wassim Haddad wrote: I don't know what EV means, but anything human, including CA, is not infallible, which is why PKI is insecure. = Can you please explain in few lines what would be your preference(s) for a solution to enable DNSsec? I apologize if you have already submitted a proposal about it which I must have missed... in which case, I would appreciate a pointer. If you are talking about a technical mechanism not to cause message size overflow beyond 512B even with 2048bit keys, the solution is to use different RR types for different kind of keys, which I proposed more than 15 yeas ago in draft-ohta-simple-dns-00: In general, data size for authentication is often as large as of 100 bytes or more. So, it is a bad idea to share a single RR type value between different authentication mechanisms, because querying them all will often break 512 byte limit of UDP query. So, authentication algorithms are distinguished by RR type values, not by something like an algorithm type field. It's crazy to share an RR type between ZSK and KSK. For key roll over, different RR types should be used for even and odd generations. You may also use elliptic curve cryptography, though I don't prefer it. But, later, I noticed fundamental fraud in PKI, against which no technical solution exists. Note that separation of ZSK and KSK was an impossible attempt make inherently insecure PKI less insecure. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC/Telechat review of draft-ietf-ipfix-export-per-sctp-stream-06
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ipfix-export-per-sctp-stream-06 Reviewer: Ben Campbell Review Date: 1 March 2010 IESG Telechat date: 4 March 2010 Summary: This document is almost ready for publication as a proposed standard, but there is an open issue that should be considered first. Major issues: -- section 4.5, general: I am confused as to how the collector determines the exporter supports this extension. If I understand correctly (and it's probable that I do not, since this is my first real exposure to IPFix), the collector basically has to infer exporter support from the behavior of the exporter. But then the second paragraph after the numbered list (i.e. 2 paragraphs after item 4) says: In the case where the Exporting Process does not support the per-SCTP-stream extension, then the first Data Record received by the Collecting Process will disable the extension for the specific Exporter on the Collecting side. This seems to conflict. Why would the collector need to worry about items 1-4 if it can categorically determine exporter support from the first data record? In general, though, I think that having the collector infer support is not the right way to do this. It would be far better to explicitly signal support, if that is at all possible in IPFix. Otherwise, it seems like the collector has to watch every record for violations of 1-4, and make fairly complex decisions on a per-record basis. Minor issues: -- section 4.2, 3rd paragraph from end, starting with When an Options Template... I'm confused by this paragraph. Would exporters using this extension ever send the options template and associated data records in different streams? Nits/editorial comments: -- section 4.1, description of dataRecordsReliability: I find the first sentence hard to parse. -- section 4.2, first paragraph ...exporting processes should follow... (Note that an identical comment applies to the first paragraph of several of the specification sections.) It would be best to avoid the word should in this context. Even though we all know a lower case should is not normative, it's still enough to confuse a reader into interpreting as a normative SHOULD, which is actually weaker than the real requirement. That is, I don't think you mean to say that, in order to take advantage of this extension and implementation SHOULD follow this specification. -- section 4.3, paragraph 3: pedantic nit - I think you mean all IPFIX messages in a single stream MUST be sent in order--not that all messages have to be in a single stream, right? The current wording is (slightly) ambiguous on that point. -- section 4.3, last paragraph: Why mention the alternative if it is not feasible in production? --Examples, figure 3: Is Data 257 a typo? -- idnits has some warnings. Please check before publication. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-nsis-rmd (RMD-QOSM - The Resource Management in Diffserv QOS Model) to Experimental RFC
The IESG has received a request from the Next Steps in Signaling WG (nsis) to consider the following document: - 'RMD-QOSM - The Resource Management in Diffserv QOS Model ' draft-ietf-nsis-rmd-16.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2010-03-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-16.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=12558rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-ippm-twamp-session-cntrl (Individual Session Control Feature for TWAMP) to Proposed Standard
The IESG has received a request from the IP Performance Metrics WG (ippm) to consider the following document: - 'Individual Session Control Feature for TWAMP ' draft-ietf-ippm-twamp-session-cntrl-04.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2010-03-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-session-cntrl-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17883rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-ipfix-mediators-problem-statement (IPFIX Mediation: Problem Statement) to Informational RFC
The IESG has received a request from the IP Flow Information Export WG (ipfix) to consider the following document: - 'IPFIX Mediation: Problem Statement ' draft-ietf-ipfix-mediators-problem-statement-08.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2010-03-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-statement-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17243rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Internet Draft Initial Version (-00) Cut-Off Today
This is a reminder that the Internet Draft Initial Version (-00) cut-off is today, Monday, March 1, 2010. All Initial Version (-00) submissions are due by 17:00 PST (01:00 Tuesday, March 2 UTC). All drafts can be uploaded using the ID submission tool located here: https://datatracker.ietf.org/idst/upload.cgi Thank you! ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: [rfc-i] Glenn Kowack appointed as Transitional RFC Series Editor
On Feb 26, 2010, at 3:25 PM, IAB Chair wrote: The IAB also acknowledges the support of the volunteers that served on the the Ad-hoc Advisory Committee (ACEF) and assisted the IAB in their selection. They are: Joel Halpern (who took the responsibility for coordinating), Bob Hinden, Joe Touch, and Jim Schaad, Craig Partridge (who left the committee in October 2009) and Scott Bradner (who recused in December 2009). They worked with IAB members John Klensin, Russ Housley, and me. I am a bit embarrassed to confess that I made a mistake in the above acknowledgments: Joe Touch was never on the committee, Bruce Davies was. --Olaf ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: [rfc-i] Glenn Kowack appointed as Transitional RFC Series Editor
As the newly appointed Transitional RSE, Olaf asked me to introduce myself to the community. I first got onto the ARPANET in the mid-1970s while studying computer science at the University of Illinois. Since then, I've done networking and operating systems (mostly UNIX) RD first as a programmer and later as director of a UNIX RD center. I even managed an ARPANET IMP. For the past 20 years I've been leading networking start-ups in Europe and the US: I was founding CEO of EUnet, Europe's first commercial internet service provider, and founding CEO of NextHop Technologies, which developed routing software. I've also been on the boards of international internet organizations such as Ebone and the Commercial Internet Exchange (CIX), and was a VP for Strategy and Planning at ISOC in the late 1990s. I've done a lot of of organizational development in corporations, including creating and leading teams of technical writers, and have done my share of technical writing. I've published ACM and IEEE articles on Internet and technology history and policy. I worked closely with Jon Postel as IANA's delegate to the Policy Oversight Committee, which provided leadership in the gTLD debates that led to ICANN's formation. My association with the 'IETF' began in the late 1970s when I was on Jon Postel's mailing lists. I attended my first IETF in the early 1990s and have been a frequent participant since then. I've led or worked with engineering teams that contributed to protocol standards, largely radius and routing. However, I've never personally written an RFC. My experience qualifies me as a long-standing participant in the IETF, and gives me an understanding of and appreciation for its history, processes, and culture. However, I have not been intimately involved in administration of the RFC editorial process. This combination affords me a broad perspective, but no specific opinions or biases regarding the current situation. That means I'm starting from a blank page, which I will fill by working closely with the entire community. The IAB has made it very clear that I'm to work with complete independence of process and analytical method, which I will do. I am calling for interested community members to contact me to share your thinking about the RSE function. Your input is essential to fulfilling my mission. For at least several weeks, you'll hear me say I don't know - I haven't enough information to form an opinion about that yet. What do you think? I hope you will find me a most open-minded and interested listener. I look forward to working with all of you on this critically important project. best regards, Glenn Transitional RFC Series Editor ___ On Feb 26, 2010, at 9:25 AM, IAB Chair wrote: Dear Colleagues, I am happy to announce that Glenn Kowack will be the Transitional RFC Series Editor(RSE). Glenn will take up his responsibilities as of March 1. His main responsibility [2] is that of formulating the RSE as defined in RFC5620 in practice while critically reviewing all aspects of the model and its implementation. Specifically, Glenn will be working with the IAB, the RFC Series Advisory Group (RSAG, see RFC5620) as appropriate, the IAOC, and the community to refine the definition of the role and relationships of the RSE. This involves providing: (i) recommendations for changes to the RFC Series model structure, (ii) recommendations for changes to the role and responsibilities of the RFC Series Editor, and (iii) recommendations to effect the acquisition of an RFC Series Editor. In the cause of the next weeks Glenn will be taking over responsibilities from Bob Braden who is acting RSE currently and will remain available as a resource of knowledge and experience. The actual title will pass between March 1 and April 19. During the next few months Glenn will talk to many of us. I hope that Glenn can count on your collaboration and frankness. Glenn will introduce himself shortly. With the appointment of Glenn Kowack as TRSE and the appointment of Nevil Brownlee as Inependent Submissions Editor the four pieces of the RFC Editor model are now in place. The IAB would like to thank the candidates that stepped forward between June and December last year. The IAB also acknowledges the support of the volunteers that served on the the Ad-hoc Advisory Committee (ACEF) and assisted the IAB in their selection. They are: Joel Halpern (who took the responsibility for coordinating), Bob Hinden, Joe Touch, and Jim Schaad, Craig Partridge (who left the committee in October 2009) and Scott Bradner (who recused in December 2009). They worked with IAB members John Klensin, Russ Housley, and me. The ACEF has served its purpose for this appointment cycle and has been dismantled. For the IAB, Olaf Kolkman IAB Chair. ___ IETF-Announce mailing list IETF-Announce@ietf.org
IETF Workshop on Broadband Home Gateways
During the 76th IETF meeting, the Transport Area sponsored a Broadband Home Gateway BoF, called HOMEGATE. Since that time, interested IETF participants have been working to narrow the scope of the draft charter and to reach out to other Standards Development Organizations (SDOs) to ensure that the planned work is complimentary and not overlapping with their respective work. To further that goal, the IETF's Transport and Internet Areas intend to co-sponsor a two-day workshop on HOMEGATE between IETF-77 and IETF-78. This workshop is slated to take place on April 20-21, 2010 in London, England. In order to reserve a properly sized meeting facility, it is important for interested people to indicate their interest in attending AS SOON AS POSSIBLE. Please do so at http://event.pingg.com/HomeGateLondonMtg NOTE: Due to potential venue limitations and the desire to allow participants from different stakeholder groups to be represented, physical attendance may need to be limited. Attendance will be confirmed at a later time (and certainly early enough for people to book reasonably priced travel accommodations). Remote listening or participation facilities of some sort will be available to all. PLEASE INDICATE YOUR INTEREST NOW if you wish to attend this interim meeting in person: http://event.pingg.com/HomeGateLondonMtg In addition: - You can find the HOMEGATE wiki at http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE - You should join the HOMEGATE mailing list at https://www.ietf.org/mailman/listinfo/homegate Thank you in advance for your interest and participation! Regards, Lars Eggert Magnus Westerlund, Transport Area Directors Jari Arkko Ralph Droms, Internet Area Directors ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
