Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
On Sun, Sep 30, 2007 at 10:32:39PM -0600, Danny McPherson [EMAIL PROTECTED] wrote a message of 51 lines which said: Section 4's reference to BCP 84, in part, creates a false sense of useful action on part of the operator, This could be said of all the parts of the I-D which mentions non-DNS issues such as BCP 38. In that respect, I full agree with Stephen Hanna's review (http://www1.ietf.org/mail-archive/web/ietf/current/msg48117.html). Some more details and recommendations on SOHOish ORNS might be useful for implementers. Any idea? The current draft mentions Incoming Interface based selection and I do not see what to add? I also agree with Paul Hoffman's comments on some reasons for ORNSs. There are many reasons why I may want to use a specific resolver consistently, to include those outlined by Paul/John. Sorry, but their messages are quite off the track. The problem is not wether there is an use case for using a resolver different from the one provided by the current access point. There are, indeed, many reasons for *not* using the default resolver (ISP which violates RFC 4925, section 2.5.2 are a very good example). But ORNS are *not* the proper solution for that use case. TSIG signatures, VPNs, local caching resolvers are the good solutions. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: secid review of draft-ietf-ipv6-deprecate-rh0-01
Hi David, and thanks for your review. Inline: As such, the whole document is a security consideration. The vulnerability appears well-documented, and the guidelines for handling the deprecated RH0 are clear. Good. I have a few comments 1) RH0 really is something we do not want to see used, right? Should this RH be obsoleted rather than deprecated? The new RFC cannot obsolete the RFC where RH0 was defined, because the latter contains also parts that we do not intend to remove :-) i.e., base IPv6 spec. 2) Per BCP61, MUST is for implementers, and SHOULD is for users/deployers. There is a MUST NOT in section 4.2 that is a deployment decision, so this should be a SHOULD NOT. At the same time, there is a must in section 4.2 that is an implementation requirement, so this should be a MUST. Hmm. There was fair amount of discussion about this in the WG. The problem is that wholesale filtering of protocol 43 breaks other things, including Mobile IPv6. This is why the document explicitly says that type specific filtering is required. There was a desire to make this very clear. But then again, who is the IETF to say what filtering MUST be performed? If someone wants to block all of TCP, they should be able to do it... We'll talk about this point in the next IESG telechat. 3) Section three uses must where MUST would seem appropriate This is a quote from another RFC, and as such we should not change it. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Third Last Call: draft-housley-tls-authz-extns
Brian E Carpenter wrote: IANAL, but it's my understanding that the prominently displayed Note Well text already serves this purpose. The real sanction can only be having a patent struck down by the courts due to intentional failure to disclose it; all the IETF can do is to make its rules clear enough for the courts to be able to make such a finding. ... I don't see what we need to change. As the current case shows, we know how to rescind a standards action if appropriate. IALOAL (I am less of a lawyer) but what you say makes complete sense to me (which probably should worry folks.) IETF actions: Note Well note, and later possibility of rescinding standards status. Legal action (by others): Use of Note Well, etc. as input to suit against patent. The only issue that occurs to me is the difference between Historic vs. Experimental/Informational. The only reason it might be worthy of discussion is the possible legal impact. I could imagine that Historic would be a more clear bit of input to the legal process... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Third Last Call: draft-housley-tls-authz-extns
Hi, Dave, Just to make sure I'm breathing the same atmosphere you are ... Are you suggesting initial publication of RFCs as Historic? I have some opinions about that, but wanted to make sure what you are suggesting before I start typing... Spencer The only issue that occurs to me is the difference between Historic vs. Experimental/Informational. The only reason it might be worthy of discussion is the possible legal impact. I could imagine that Historic would be a more clear bit of input to the legal process... d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt
On Tuesday, September 25, 2007 09:36:23 AM +1000 Mark Andrews [EMAIL PROTECTED] wrote: The Introduction seems a bit defensive in stating that the DOS attacks are not due to any flaw in the design of DNS or its implementations. While the blame for the attacks lies with the attackers, some aspects of nameserver configuration, behavior, and even protocol design make the systems vulnerable to these attacks. I suggest that the defensive language be removed. No, the blame lies with the parties not implementing BCP 38. A rogue end site should not be able to inject spoofed packets. No; the blame for an attack _always_ lies with the attacker, not the victim. While I certainly wish more network providers would implement BCP 38, those who fail to do so are not to blame for the bad acts of others. FWIW, I believe the defensive language in question is neither necessary nor particularly problematic, so I take no position on whether it should be removed. Finally, I wonder whether other more fundamental techniques for addressing the problem have been explored. For instance, if DNS clients were required to perform a simple handshake before a DNS server sent a long response, fake requests would provide little amplification. For example, requests that elicit long responses could prompt a shift to TCP. The DNS already does this. The DNS is optimised so that the normal responses go via UDP and the exceptional responses via TCP. It does, but normally only responses which are too long for UDP require the use of TCP. A recursive nameserver could mitigate this type of attack by lowering the maximum response size it is willing to send via UDP, forcing the use of TCP and thus a three-way handshake for larger responses. The tricky part is that setting the threshold too low can have serious performance impact. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Third Last Call: draft-housley-tls-authz-extns
Spencer Dawkins wrote: Hi, Dave, Just to make sure I'm breathing the same atmosphere you are ... Are you suggesting initial publication of RFCs as Historic? No (though I think DomainKeys was just initially published that way, albeit for a very different and benign reason; kinda amusing to see.). Brian suggested the Historic label as an essentially punitive action, *after* publication on standards track, to reclassify it off the track. If it is discovered that there was inadequate disclosure. It's not exactly insightful to predict that the IETF's taking this unusual action is likely to be the result of a process that includes a lot of anger amongst the IETF community. However I think the action need not be viewed as punitive. Rather it merely marks an error and fixes the publication books to reflect the error. (But, then, I don't see getting on standards track as a reward, either...) Let's be clear: 1. Lots of specifications do just fine in the real world without any IETF label at all and certainly without an IETF standards track label. So there is no inherent basis for claiming that the label is needed for a spec to be useful. 2. Rather, the label says something about community consensus. If a later disclosure alters that consensus, then of course the community should re-label the thing, to take it off standards track. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt
On Oct 1, 2007, at 10:10 AM, Jeffrey Hutzelman wrote: No; the blame for an attack _always_ lies with the attacker, not the victim. While I certainly wish more network providers would implement BCP 38, those who fail to do so are not to blame for the bad acts of others. Given the reality with bots et al. today, most of the attacking systems are actually victims themselves. It does, but normally only responses which are too long for UDP require the use of TCP. A recursive nameserver could mitigate this type of attack by lowering the maximum response size it is willing to send via UDP, forcing the use of TCP and thus a three-way handshake for larger responses. The tricky part is that setting the threshold too low can have serious performance impact. Note that in real deployments just this behavior has broken things on occasion, as many firewall and other such policy application points assume things like DNS resolution will only be UDP/53 transactions. YMMV. -danny ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
[secdir] draft-aboba-sg-experiment-02.txt
Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document described an RFC3933 experiment in forming a Study Group prior to Working Group formation. As such I agree with the authors that there are no additional specific security considerations as also discussed in RFC3933. Aside from the Security Review, I have three comments: 1. editorial comment to section 1: s/those who have no followed the/ those who have not followed the 2. comment to section 2: Section 2 states that: If at any point, including after a first or second BoF session, ... the IESG MAY propose that a Study Group be formed. This sounds to me like partially conflicting with RFC2418, which clearly states that an absolute maximum of two BOFs are allowed for a topic. This would implicate that if a Study Group was formed after the second BOF, it would have to directly lead to a WG (or be abandoned) as it can not go back to BOF. I would propose to change this to that a Study Group may be initiated after the first BOF but not after the second to prevent this conflict. (The second BOF is already an extension and we should not add the Study Group as a second extension to the system. People should be pretty well prepared at a second BOF to get either a Yes or No - and if they are not ready for a decision by then, another second extension may probably also not help.) So, proposal to change the line in section 2 accordingly: s/including after a first or second BoF session/including after a first BoF session I.e. if a first BOF does not lead to the anticipated results (WG: yes/no decision), the appropriate mechanism for the AD should be to decide whether s/he wants to use this experiment or run straight with the second BOF as defined in the process. With the study group the second BOF could be initiated after the Study Group has concluded if the AD does not want to go to WG directly without second BOF. 3. comment to section 3: In section 3 it is described that a study group shall have and run the same infrastructure identical to a WG. I would not agree with this suggestion, but think it should be limited to less than a WG. Otherwise it might lead to false impressions, de-facto situations and also prolong the work of the study group to finally get a go for a WG, as they might consider this an already fully functional lightweight WG. Summary: I believe that this idea of a Study Group is a great idea that will add a new tool for the AD for the situation that a BOF has not been satisfactory preparing a WG formation. However I would suggest to make sure to keep a clear distinction between a WG and a study group, as they differ dramatically in the regard of role and acceptance by the IETF community. If they both look similar this might be misunderstood by people outside or new to the IETF. Greeting, Tobias __ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:[EMAIL PROTECTED] Internet: http://www.opentext.com/ Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: München, Germany | Trade Register Number / HRB: 168364 | VAT ID Number /USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton, Walter Köhler ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching)
What a timely thread. I've recently concluded that we need an extension to getaddrinfo() along these lines, but I'm looking for somewhat tighter and more generic semantics. My proposal is to add an AI_SECURE_CANONNAME flag with the following semantics: - it MUST be used with AI_CANONNAME - if set in the hints then it will be set in the results IFF: - the resulting ai_canonname == the nodename given as input or - the resulting ai_canonname was obtained securely, such as from a write-protected local hosts file, via DNSSEC, or via any other acceptably secure name service or - the resulting ai_canonname == nodename + '.' + default domain from the resolver's configuration (i.e., the _first_ domain in the search list) Additional flags modifying for controlling search behaviour would be nice, such as: - AI_CANONNAME_SEARCH_ANY Accept canonical names formed by successively trying the given nodename suffixed with the domainnames from the resolver's search list. If this flag is used in the input hints then it will be set in the result IFF the domainname used to qualify the given nodename was not the first domain in the search list. - AI_CANONNAME_SEARCH_PARENTS Like AI_CANONNAME_SEARCH_ANY, but skip domainnames in the search list which are not parents (or grandparents) of the preceding domainname on the list. - AI_CANONNAME_SEARCH_SIBLINGS Like AI_CANONNAME_SEARCH_PARENTS, but search sibling domains in the search list too. - AI_CANONNAME_SEARCH_DEFAULT Allow whatever AI_CANONNAME_SEARCH_* behaviour is locally configured as a default for this flag. If this flag is used in the input hints then one of the above will be set in the result to indicate which search policy was configured and used. This flag might be all the other AI_CANONNAME_SEARCH_* flags ORed together. I'm still researching this proposal. We might want one more flag to indicate whether unsecured NXDOMAIN replies can be/were processed during search list processing, say, AI_SECURE_CANONNAME_SEARCH. And we might not care to have so many AI_CANONNAME_SEARCH_* flags, maybe AI_CANONNAME_SEARCH_ANY will do. Comments? Nico -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
On Oct 1, 2007, at 1:52 AM, Stephane Bortzmeyer wrote: On Sun, Sep 30, 2007 at 10:32:39PM -0600, Danny McPherson [EMAIL PROTECTED] wrote a message of 51 lines which said: Section 4's reference to BCP 84, in part, creates a false sense of useful action on part of the operator, This could be said of all the parts of the I-D which mentions non-DNS issues such as BCP 38. In that respect, I full agree with Stephen Hanna's review (http://www1.ietf.org/mail-archive/web/ietf/current/msg48117.html). I read Stephen's comments before posting, and I agree as well. However, the BCP 84 bit is slightly different because it's only useful for mitigating reflective attacks IF it's employed in a particular way. If this document is going to reference it then it should make a distinction here. Any idea? The current draft mentions Incoming Interface based selection and I do not see what to add? Perhaps expanding in the Problem Description section would be beneficial. Something mentioning that Many SOHO and broadband access devices provide some flavor of name resolution services (e.g., there are 4 flavors outlined by JKT and others; Recursive, Forwarder, Caching- only and Restricted). Some other empirical bits might be useful as well, though and although I'm not sure they need to be in the I-D, they would be useful: E.g., 16M recursive type servers, , with 800k or so being the larger problem. Also, some references that provide usual information on actual numbers, such as John's work here: http://condor.depaul.edu/~jkristof/orns/ http://maps.measurement-factory.com/gallery/Openresolvers/ And this is particularly illustrative: http://maps.measurement-factory.com/gallery/Openresolvers/20070429.png As for the current text, you don't provide much in the way of explaining that queries should probably not be accepted from the Internet/untrusted interfaces, you just essentially state that interface-based discrimination might be employed. That was my initial concern. If your attempt is to progress as BCP, then some actual specific guidelines on this front for implementers and administrators alike might provide more actionable information. Sorry, but their messages are quite off the track. The problem is not wether there is an use case for using a resolver different from the one provided by the current access point. There are, indeed, many reasons for *not* using the default resolver (ISP which violates RFC 4925, section 2.5.2 are a very good example). But ORNS are *not* the proper solution for that use case. TSIG signatures, VPNs, local caching resolvers are the good solutions. I think you made my point. Where is this currently explained in the document as such? Acknowledging existence and practical realities is important, methinks. -danny ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Third Last Call: draft-housley-tls-authz-extns
Post-posting additional thoughts: Dave Crocker wrote: 2. Rather, the label says something about community consensus. If a later disclosure alters that consensus, then of course the community should re-label the thing, to take it off standards track. Although this should be check with an appropriate attorney, I would expect that relabeling to Historic might have a variety of uses for an legal actions. Reversing a patent is only one. I could imagine something as interesting as class action, among the companies who were deceived by the non-disclosing party. After all, they will have gone down the path of strategic planning and implementation, on a basis that the disclosing party knew to be both incorrect and to its benefit, along with being against the IETF rules. I could even imagine that those companies could even demand fees for having been used as unwitting consultants to the disclosing party's design efforts... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Would someone help the secretariat figure out why they cannot route to teredo addresses?
Hi. I opened a ticket with the secretariat a few weeks ago complaining that I cannot reach www.ietf.org using a teredo address either allocated through the Microsoft Teredo server or the Debian teredo server. This is annoying because glibc's source address selection algorithm seems to prefer teredo addresses to v4 addresses. So, I get really bad response times to www.ietf.org when using teredo. Based on the responses to the ticket, it was not entirely clear if the people at NSS understood how teredo differs from a normal IPV6 address. I just don't have time to work with them to debug the problem. Is there someone out there with significant IPV6 experience who can reproduce the problem and who would be willing to work with NSS to resolve? I want to reiterate that NSS has been incredibly helpful. They are willing to work with me, I just don't have time to explain Teredo and be responsive. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Would someone help the secretariat figure out why they cannot route to teredo addresses?
I can work on that. Regards, Jordi De: Sam Hartman [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Mon, 1 Oct 2007 13:50:00 -0400 (EDT) Para: ietf@ietf.org Asunto: Would someone help the secretariat figure out why they cannot route to teredo addresses? Hi. I opened a ticket with the secretariat a few weeks ago complaining that I cannot reach www.ietf.org using a teredo address either allocated through the Microsoft Teredo server or the Debian teredo server. This is annoying because glibc's source address selection algorithm seems to prefer teredo addresses to v4 addresses. So, I get really bad response times to www.ietf.org when using teredo. Based on the responses to the ticket, it was not entirely clear if the people at NSS understood how teredo differs from a normal IPV6 address. I just don't have time to work with them to debug the problem. Is there someone out there with significant IPV6 experience who can reproduce the problem and who would be willing to work with NSS to resolve? I want to reiterate that NSS has been incredibly helpful. They are willing to work with me, I just don't have time to explain Teredo and be responsive. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching)
What a timely thread. I've recently concluded that we need an extension to getaddrinfo() along these lines, but I'm looking for somewhat tighter and more generic semantics. My proposal is to add an AI_SECURE_CANONNAME flag with the following semantics: do not try to implement policy into applications. you will end up forced to (?) rewrite every existing applications. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
As for the TSIG or SIG(0) recommendation, I'm not sure what the numbers are for client support today, but I suspect it's at best an negligible sample. Well all Windows XP/2003/Vista boxes can be configured to support TSIG, with free software, if not natively. All Linux, *BSD and Apple boxes can do this with what ships with the OS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
On Oct 1, 2007, at 7:42 PM, Mark Andrews wrote: As for the TSIG or SIG(0) recommendation, I'm not sure what the numbers are for client support today, but I suspect it's at best an negligible sample. Well all Windows XP/2003/Vista boxes can be configured to support TSIG, with free software, if not natively. All Linux, *BSD and Apple boxes can do this with what ships with the OS. Sorry, I said support, I meant use. Any numbers there? -danny ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt
On Tuesday, September 25, 2007 09:36:23 AM +1000 Mark Andrews [EMAIL PROTECTED] wrote: The Introduction seems a bit defensive in stating that the DOS attacks are not due to any flaw in the design of DNS or its implementations. While the blame for the attacks lies with the attackers, some aspects of nameserver configuration, behavior, and even protocol design make the systems vulnerable to these attacks. I suggest that the defensive language be removed. No, the blame lies with the parties not implementing BCP 38. A rogue end site should not be able to inject spoofed packets. No; the blame for an attack _always_ lies with the attacker, not the victim. I'm not blaming the victim, I'm pointing out the contributory negligence on behalf of the ISP that is supplying the attacker bandwidth. BCP 38 is over 7 years old now. The time has past where you can blame the hardware vendors for lack of support. The blame now has to be squarely brought down on the ISP's that have failed to deploy BCP 38. A attacker should not be able to send spoofed packet and have them reach the destination. I don't care if the destination is the other side of the world or the neighbor. ISP's should be doing this anyway to protect their customers from accidental traffic. e.g. DHCP lease changes where not all of the sockets with the old address have shutdown. RFC 1918 sourced traffic. While I certainly wish more network providers would implement BCP 38, those who fail to do so are not to blame for the bad acts of others. FWIW, I believe the defensive language in question is neither necessary nor particularly problematic, so I take no position on whether it should be removed. Finally, I wonder whether other more fundamental techniques for addressing the problem have been explored. For instance, if DNS clients were required to perform a simple handshake before a DNS server sent a long response, fake requests would provide little amplification. For example, requests that elicit long responses could prompt a shift to TCP. The DNS already does this. The DNS is optimised so that the normal responses go via UDP and the exceptional responses via TCP. It does, but normally only responses which are too long for UDP require the use of TCP. A recursive nameserver could mitigate this type of attack by lowering the maximum response size it is willing to send via UDP, forcing the use of TCP and thus a three-way handshake for larger responses. The tricky part is that setting the threshold too low can have serious performance impact. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt
It does, but normally only responses which are too long for UDP require the use of TCP. A recursive nameserver could mitigate this type of attack by lowering the maximum response size it is willing to send via UDP, forcing the use of TCP and thus a three-way handshake for larger responses. The tricky part is that setting the threshold too low can have serious performance impact. Note that in real deployments just this behavior has broken things on occasion, as many firewall and other such policy application points assume things like DNS resolution will only be UDP/53 transactions. That assumption has always been wrong. I would also dispute the many above. Most firewalls actually handle the transition to TCP perfectly fine. There are the odd few that are misconfigured. When that happens people complain because nameservers resolution fails. Either the dataset is fixed or the firewall is fixed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt
On Monday, October 01, 2007 10:34:37 AM -0600 Danny McPherson [EMAIL PROTECTED] wrote: Note that in real deployments just this behavior has broken things on occasion, as many firewall and other such policy application points assume things like DNS resolution will only be UDP/53 transactions. Yeah; I'm getting a little tired of having our protocols redefined based on the incorrect assumptions of people who don't understand them. The DNS sometimes uses TCP, UDP flows can last more than one round trip, and ICMP unreachable messages are an essential part of IP; vendors and operators who assume otherwise should be made to fix their assumptions, instead of everyone else having to cripple their applications and networks to make the assumptions true. -- Jeff And IP fragnments exist and are useful. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching)
Jun-ichiro itojun Hagino wrote: What a timely thread. I've recently concluded that we need an extension to getaddrinfo() along these lines, but I'm looking for somewhat tighter and more generic semantics. My proposal is to add an AI_SECURE_CANONNAME flag with the following semantics: do not try to implement policy into applications. you will end up forced to (?) rewrite every existing applications. perhaps, but having the policy be application-independent doesn't make sense either. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
On Oct 1, 2007, at 7:42 PM, Mark Andrews wrote: As for the TSIG or SIG(0) recommendation, I'm not sure what the numbers are for client support today, but I suspect it's at best an negligible sample. Well all Windows XP/2003/Vista boxes can be configured to support TSIG, with free software, if not natively. All Linux, *BSD and Apple boxes can do this with what ships with the OS. Sorry, I said support, I meant use. Any numbers there? -danny I use TSIG on my laptop. As for others I have no idea. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] draft-aboba-sg-experiment-02.txt
Hi Tobias, Many thanks for your review. Please see inline for my thoughts on your observations. On 10/1/2007 9:39 AM, Tobias Gondrom wrote: Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document described an RFC3933 experiment in forming a Study Group prior to Working Group formation. As such I agree with the authors that there are no additional specific security considerations as also discussed in RFC3933. Aside from the Security Review, I have three comments: 1. editorial comment to section 1: s/those who have no followed the/ those who have not followed the We'll fix this in the revision. 2. comment to section 2: Section 2 states that: If at any point, including after a first or second BoF session, ... the IESG MAY propose that a Study Group be formed. This sounds to me like partially conflicting with RFC2418, which clearly states that an absolute maximum of two BOFs are allowed for a topic. This would implicate that if a Study Group was formed after the second BOF, it would have to directly lead to a WG (or be abandoned) as it can not go back to BOF. I would propose to change this to that a Study Group may be initiated after the first BOF but not after the second to prevent this conflict. (The second BOF is already an extension and we should not add the Study Group as a second extension to the system. People should be pretty well prepared at a second BOF to get either a Yes or No -- and if they are not ready for a decision by then, another second extension may probably also not help.) My take is that after the SG it is a WG or nothing. The sponsoring and other ADs would have the opportunity to observe the SG in progress just as they would do a BoF and can assess whether to form a WG or not. With that clarification, does the current wording sound alright? So, proposal to change the line in section 2 accordingly: s/including after a first or second BoF session/including after a first BoF session I.e. if a first BOF does not lead to the anticipated results (WG: yes/no decision), the appropriate mechanism for the AD should be to decide whether s/he wants to use this experiment or run straight with the second BOF as defined in the process. With the study group the second BOF could be initiated after the Study Group has concluded if the AD does not want to go to WG directly without second BOF. 3. comment to section 3: In section 3 it is described that a study group shall have and run the same infrastructure identical to a WG. I would not agree with this suggestion, but think it should be limited to less than a WG. It is in fact less than a WG. More specifically, A Study Group charter MUST NOT include milestones relating to development of a protocol specification. was included to make it less than a WG. The limited lifetime is another constraint. The other processes are intentionally made similar so as to reuse our current operational structures. Does that clarification alleviate this concern? regards, Lakshminath Otherwise it might lead to false impressions, de-facto situations and also prolong the work of the study group to finally get a go for a WG, as they might consider this an already fully functional lightweight WG. Summary: I believe that this idea of a Study Group is a great idea that will add a new tool for the AD for the situation that a BOF has not been satisfactory preparing a WG formation. However I would suggest to make sure to keep a clear distinction between a WG and a study group, as they differ dramatically in the regard of role and acceptance by the IETF community. If they both look similar this might be misunderstood by people outside or new to the IETF. Greeting, Tobias ***__* *Tobias Gondrom* Head of Open Text Security Team Director, Product Security *Open Text* Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:[EMAIL PROTECTED] Internet: http://www.opentext.com/ Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: München, Germany | Trade Register Number / HRB: 168364 | VAT ID Number /USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton, Walter Köhler ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching)
Jun-ichiro itojun Hagino wrote: I've recently concluded that we need an extension to getaddrinfo() along these lines, but I'm looking for somewhat tighter and more generic semantics. My proposal is to add an AI_SECURE_CANONNAME flag with the following semantics: do not try to implement policy into applications. you will end up forced to (?) rewrite every existing applications. perhaps, but having the policy be application-independent doesn't make sense either. it can be application-specific, without application modification. check out systrace by Niels Provos. it's useful but it really isn't flexible enough to remove the need for applications to be able to specify policies. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching)
I've recently concluded that we need an extension to getaddrinfo() along these lines, but I'm looking for somewhat tighter and more generic semantics. My proposal is to add an AI_SECURE_CANONNAME flag with the following semantics: do not try to implement policy into applications. you will end up forced to (?) rewrite every existing applications. perhaps, but having the policy be application-independent doesn't make sense either. it can be application-specific, without application modification. check out systrace by Niels Provos. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching)
it can be application-specific, without application modification. check out systrace by Niels Provos. it's useful but it really isn't flexible enough to remove the need for applications to be able to specify policies. i wonder how many command line options will be added to the applications once you start adding up policy stuff... sendmail.cf lookalike for every apps? itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: AI_SECURE_CANONNAME, AI_CANONNAME_SEARCH_* (Re: getaddrinfo() and searching)
Jun-ichiro itojun Hagino wrote: it can be application-specific, without application modification. check out systrace by Niels Provos. it's useful but it really isn't flexible enough to remove the need for applications to be able to specify policies. i wonder how many command line options will be added to the applications once you start adding up policy stuff... sendmail.cf lookalike for every apps? well, I do think we need a policy specification language that lets policies for use of the network be specified independently of the application. I just don't think it will be sufficient for all applications. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [secdir] secdir review ofdraft-ietf-dnsop-reflectors-are-evil-04.txt
See http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-02.txt . Donald -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Hanna Sent: Monday, September 24, 2007 3:52 PM To: ietf@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [secdir] secdir review ofdraft-ietf-dnsop-reflectors-are-evil-04.txt ... Finally, I wonder whether other more fundamental techniques for addressing the problem have been explored. For instance, if DNS clients were required to perform a simple handshake before a DNS server sent a long response, fake requests would provide little amplification. ... Thanks, Steve ___ secdir mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/secdir ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Aggregation of DiffServ Service Classes ' draft-ietf-tsvwg-diffserv-class-aggr-04.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 [EMAIL PROTECTED] mailing lists by 2007-10-15. Exceptionally, comments may be sent to [EMAIL PROTECTED] 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-tsvwg-diffserv-class-aggr-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14993rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type' to Proposed Standard
The IESG has approved the following document: - 'Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type ' draft-ietf-smime-cms-auth-enveloped-06.txt as a Proposed Standard This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Tim Polk and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-auth-enveloped-06.txt Technical Summary This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped- data content type. Working Group Summary This document is a product of the smime working group. The document follows the style of RFC 3852 (CMS) in describing a content type and it's fields. It is heavily based on an existing content type (authenticated-data) therefore it is straightforward to understand the fields and their use. The only discussion point on the list was the number and location of the authenticated attributes (authAttrs) field. It was argued that the current document, which has one authAttrs field after the content, is optimized for the aes-gcm/ccm algorithms (see aes-gcm/ ccm draft) and that it would be better to have two locations for the authAttr field. With two fields, efficiencies are afforded to both the current algorithms and yet-to-be-defined algorithms that work faster/better with the authAttrs before the content. The counter argument against two fields was complexity. The working group determined one field after the data could adequately support the full range of algorithms based on tests performed by Peter Gutmann. Protocol Quality Tim Polk reviewed this document for the IESG. There are no current implementations, although WG members have expressed interest in implementing this specification. Note to RFC Editor Please make the following changes. In section 3: OLD: accept unsolicited encrypted messages, they become even more vulnerable to unwanted traffic since the present mitigation ^^^ NEW: accept unsolicited encrypted messages, they become even more vulnerable to unwanted traffic since many present mitigation In section 2.2: OLD: the AAD, the IMPLICIT [1] tag in for authAttrs field is not used for ^^^ NEW: the AAD, the IMPLICIT [1] tag in the authAttrs field is not used for ^^^ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
