Re: [mile] Last Call: draft-ietf-mile-template-04.txt (Guidelines for Defining Extensions to IODEF) to Informational RFC
On 5/18/12 6:13 AM, Brian Trammell wrote: Hi, Peter, all, Many thanks for the comments; And to you for following up. replies inline... Likewise. On May 17, 2012, at 5:25 AM, Peter Saint-Andre wrote: On 5/16/12 3:53 PM, The IESG wrote: The IESG has received a request from the Managed Incident Lightweight Exchange WG (mile) to consider the following document: - 'Guidelines for Defining Extensions to IODEF' draft-ietf-mile-template-04.txt as Informational RFC Although this document does no harm, I have my doubts that the topic warrants publication of an RFC (and I say that as someone who is defining some IODEF extensions for use on the XMPP network [1]). Why would a simple wiki page [2] not suffice? Indeed, it may; the WG decided we wanted something semi-permanent to give guidance to extension authors, especially given that we anticipated (and have had) significant participation from people with little or no previous involvement in the IETF. Whether that's an RFC or not is, but an RFC seemed the natural thing to do, as it is how things are published out of IETF WGs. The previous version of this document _did_ need to be an RFC as it specified a change to the IANA XML registry requiring a Standards Action; this has been split out into draft-ietf-mile-iodef-xmlreg per AD guidance. Thanks for the clarifications. I chatted about this I-D offlist with Sean Turner and he explained that a bunch of folks who are not familiar with the IETF might be coming here to define IODEF extensions, so I now think that an Informational RFC could be useful. If we decide than an RFC is needed, I have some more actionable feedback... 1. The document could be construed as assuming that IODEF extensions will all be defined in Internet-Drafts, that extension namespaces will be registered with IANA, and even that namespaces will be of the form 'urn:ietf:params:xml:schema:iodef-*'. It might be helpful to clarify the intended applicability of this document, i.e., merely as helpful suggestions for authors of Internet-Drafts, not truly as universally applicable guidelines for defining IODEF extensions. Hm. The document does indeed assume that extensions to IODEF are defined in Internet-Drafts, that extension namespaces will be registered with IANA, and that those namespaces be of the described form; it makes these assumptions because that is the intent of the document. Whether that's universal or not could be an open question, perhaps, but the intent is to specify a more restrictive method of extension than that in 5070 in the interests of consistency. So, yes, it's an informational document, they're just helpful suggestions, but we would hope they'd be followed, and the document is written assuming that they will... As mentioned, I happen to be working on some IODEF extensions that are specific to the XMPP community. Is it expected that I work on the relevant spec in the MILE WG, in the XMPP WG, or (as I'm doing right now) at the XMPP Standards Foundation? IMHO, doing this work at the XSF makes the most sense because that's where most of the XMPP developers and operators are active. Seeking a sanity check on this work from the MILE WG does seem reasonable, though (once it's ready for review). 2. Why is RFC 6545 a normative reference? Oversight, should be informative (I checked this briefly; it is referenced from a section entitled Terminology, but this is terminology in the Appendix; oops.) 3. Given the many comments provided by Martin Dürst, mentioning his AppsDir review in the Acknowledgements seems appropriate. Indeed, also oversight; thanks. 4. Some of the text in the appendix seems needlessly detailed (e.g., saying that each extension needs to be specified in a subsection, or the recommendation to include a UML diagram). These guidelines are intended to help the set of drafts defining IODEF extensions to be consistent with RFC 5070 and with each other. 5. Why is the list of datatypes in appendix A.4.1 copied from RFC 5070? A simple reference would do. (I almost said the same about the list in Section 3, but that one is marginally useful.) The A.4.1. list was copied over because doing so was consistent with the list in Section 3, more or less; it's intended to give an inline definition of the allowable TYPE values as in the UML diagram in Figure 1, section A.4. (Copying this was also consistent with the inclusion of the list in Section 3.) 6. Some of the information in this document repeats information from the RFC style guide and other sources; why? Here we have a duelling-commenters situation; this is per early-AD commentary in http://www.ietf.org/mail-archive/web/mile/current/msg00657.html and the subsequent thread. IMHO, it seems fine to repeat some of that information, as long as you say that the styleguide rules on general matters of RFC authorship. But your AD might know better. ;-) Peter -- Peter Saint-Andre
Re: Updated secdir review of draft-ietf-emu-chbind-15.txt
Stephen == Stephen Hanna sha...@juniper.net writes: Stephen The changes in draft-ietf-emu-chbind-15.txt satisfactorily Stephen address almost all of the comments in my April 13, 2012 Stephen secdir review. I do have one remaining substantive comment Stephen on this latest draft and two non-substantive ones. Stephen Substantive Comment --- Stephen The last paragraph of section 9.1 points out a security Stephen problem with implementing channel bindings using EAP tunnel Stephen methods. If the EAP tunnel method terminates on the Stephen authenticator, the channel bindings can easily be defeated Stephen by the authenticator. While that's true, nobody terminates Stephen the EAP tunnel method on the authenticator today. In the Stephen EAP model, the authenticator is not trusted so terminating Stephen the EAP tunnel method on the authenticator is a bad idea Stephen for many reasons. For example, the authenticator would then Stephen have the ability to bypass protected result indications and Stephen to bypass all the cryptographic protections provided by the Stephen tunnel. Sometimes there is value in having the inner and Stephen outer methods terminate on different servers but both Stephen servers must be trusted. The authenticator is not. So Stephen there is no big security hole here, unless you have already Stephen opened an enormous security hole. It's ironic that this Stephen document which attempts to close vulnerabilities caused by Stephen malicious authenticators ends up subtly suggesting that Stephen people open a much larger vulnerability! Stephen I would recommend deleting the end of this paragraph, Stephen starting with the sentence that starts Even when Stephen cryptographic binding. I disagree very strongly with this proposed change. It's possible that the text is not clear and I'd be happy to work for a round or two to see if we can clarify the text, but ending the paragraph as you propose would defeate the point of text we added after a WG consensus call. I agree with you that authenticators are not trusted. The issue is that you cannot trust attackers to act within a specification. If an attacker can gain benefit from doing something, they may do so. So, if an attacker can create a tunnel terminating at an authenticator and gain advantage from doing so, then they will do so. Remember that we're talking about crypto binding. If crypto binding is relevant for confirming there are no extra servers, then we're in a threat model space where we're trusting the inner method to authenticate the server, not the outer method. You can't say you should only establish trusted tunnels, because we're hoping that crypto binding will give us that trust. So, the issue here is that once you add channel bindings and the associated changes to the threat model to EAP, an authenticator can gain advantage through convincing a client to trust a tunnel that terminates at an authenticator. That is, an authenticator can mount an attack. Yes, the authenticator needs to convince the peer to trust the extra tunnel. However, as I discuss in draft-hartman-emu-mutual-crypto-binding and in my presentation at last IETF, that's often fairly easy. So, how can we make the text more clear?
Results of IETF-conflict review for draft-irtf-dtnrg-prophet-09.txt
The IESG has completed a review of draft-irtf-dtnrg-prophet consistent with RFC5742. This review is applied to all non-IETF streams. The IESG has concluded that there is no conflict between this document and IETF work. The IESG has no problem with the publication of 'Probabilistic Routing Protocol for Intermittently Connected Networks' draft-irtf-dtnrg-prophet-09.txt as an Experimental RFC. The IESG would also like the IRSG to review the comments in the datatracker (http://datatracker.ietf.org/doc/draft-irtf-dtnrg-prophet/) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-irtf-dtnrg-prophet/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary Technical Summary This document defines PRoPHET, a Probabilistic Routing Protocol using History of Encounters and Transitivity. PRoPHET is a variant of the epidemic routing protocol for intermittently connected networks that operates by pruning the epidemic distribution tree to minimize resource usage while still attempting to achieve the best case routing capabilities of epidemic routing. It is intended for use in sparse mesh networks where there is no guarantee that a fully connected path between source and destination exists at any time, rendering traditional routing protocols unable to deliver messages between hosts. These networks are examples of networks where there is a disparity between the latency requirements of applications and the capabilities of the underlying network (networks often referred to as Delay- and Disruption-Tolerant). The document presents an architectural overview followed by the protocol specification. Working Group Summary This document is the product of the IRTF. This document is a product of the Delay Tolerant Networking Research Group within the IRTF. It has been reviewed by that group and no objection to its publication as an RFC was raised. Document Quality It is believed that there have been implementations and experimentation as described in the document. Personnel Stephen Farrell (stephen.farr...@cs.tcd.ie) is the Document Shepherd. Adrian Farrel (adr...@olddog.co.uk) carried out the RFC5742 review. RFC Editor Note The IESG has review this document according to RFC 5742 and has concluded that there is no conflict between this document and IETF work. The IESG makes no request for the inclusion of an IESG note in this document.
