Re: Last Call: draft-hethmon-mcmurray-ftp-hosts (File Transfer Protocol HOST Command) to Proposed Standard
--On Monday, 12 April, 2010 12:44 -0700 The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'File Transfer Protocol HOST Command ' draft-hethmon-mcmurray-ftp-hosts-11.txt as a Proposed Standard I agree with John Klensin's comments, and especially want to call out this part: On Mon, May 10, 2010 at 11:22 AM, John C Klensin klen...@jck.com wrote: Those decisions should not -- cannot -- be made by processing one command extension at a time, with each one reflecting the taste and assumptions of its authors in different ways. It seems to me that we need a WG or some other mechanism for establishing and determining community consensus around basic design principles for FTP extensions. If the IESG then wants to process individual extensions as individual submissions, that would be fine, but let's first at least establish a framework for evaluating them. It would be a mistake to build a further array of individual, uncoordinated extensions to FTP. As with the establishment of the imapext, sieve, and morg working groups, when the IETF has seen a collection or succession of proposals aimed at extending a protocol, it has opted to charter a working group to coordinate those proposals, winnow them, and establish community consensus on which to standardize, and how. It should do that here, as well. Barry Leiba ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hethmon-mcmurray-ftp-hosts (File Transfer Protocol HOST Command) to Proposed Standard
Barry Leiba wrote: --On Monday, 12 April, 2010 12:44 -0700 The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'File Transfer Protocol HOST Command ' draft-hethmon-mcmurray-ftp-hosts-11.txt as a Proposed Standard I agree with John Klensin's comments, and especially want to call out this part: On Mon, May 10, 2010 at 11:22 AM, John C Klensin klen...@jck.com wrote: Those decisions should not -- cannot -- be made by processing one command extension at a time, with each one reflecting the taste and assumptions of its authors in different ways. It seems to me that we need a WG or some other mechanism for establishing and determining community consensus around basic design principles for FTP extensions. If the IESG then wants to process individual extensions as individual submissions, that would be fine, but let's first at least establish a framework for evaluating them. It would be a mistake to build a further array of individual, uncoordinated extensions to FTP. As with the establishment of the imapext, sieve, and morg working groups, when the IETF has seen a collection or succession of proposals aimed at extending a protocol, it has opted to charter a working group to coordinate those proposals, winnow them, and establish community consensus on which to standardize, and how. It should do that here, as well. Barry/John, You already know that I am waiting for the FTP BOF proposal for Maastricht. I can delay asking IESG to review this document till after the BOF, but if there is no BOF or nothing comes out of it, I don't think it is fair to delay the document just because something can be done better in a WG. Alexey, as the sponsoring Apps AD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hethmon-mcmurray-ftp-hosts (File Transfer Protocol HOST Command) to Proposed Standard
On 2010-05-12, at 12:32, Paul Hoffman wrote: The use of FTP dwarfs the use of SFTP by at least two orders of magnitude. Sure. To paraphrase my comment (or at least re-state it in a clearer way) from a protocol perspective, setting aside deficiencies in particular implementations, it seems more apropos to convey the message that FTP is inadequate in various ways, and to point towards some alternatives, than to imply (through the appearance of protocol maintenance) that FTP is alive and well and a good choice of protocol for new applications. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hethmon-mcmurray-ftp-hosts (File Transfer Protocol HOST Command) to Proposed Standard
On Wed, 12 May 2010, Joe Abley wrote: I'm actually slightly surprised that anybody is considering enhancements to FTP in 2010. I would have thought that given standardised alternatives which are kinder to firewalls and more secure the logical next step would be to publish guidance that advises against using FTP, outlines the reasons why, and points people towards more suitable protocols. Unless I'm missing some use-case where FTP is actually superior to (say) HTTP, or SSH/SFTP? Agreed. It is irresponsible to patch up the ftp protocol to enhance its life span. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hethmon-mcmurray-ftp-hosts (File Transfer Protocol HOST Command) to Proposed Standard
On 5/12/10 9:38 AM, Joe Abley wrote: On 2010-05-12, at 12:32, Paul Hoffman wrote: The use of FTP dwarfs the use of SFTP by at least two orders of magnitude. Sure. To paraphrase my comment (or at least re-state it in a clearer way) from a protocol perspective, setting aside deficiencies in particular implementations, it seems more apropos to convey the message that FTP is inadequate in various ways, and to point towards some alternatives, than to imply (through the appearance of protocol maintenance) that FTP is alive and well and a good choice of protocol for new applications. Agreed. Use of plain-text authentication, even with a pretext of restricting directory views, lacks merit. Most operating systems enforce directory access without dependence upon the access application. Suggestions, that in effect recommends FTP to maintain security, would be misleading especially with many outstanding exploits still found in clients and browsers. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hethmon-mcmurray-ftp-hosts (File Transfer Protocol HOST Command) to Proposed Standard
--On Wednesday, 12 May, 2010 17:12 +0100 Alexey Melnikov alexey.melni...@isode.com wrote: ... Barry/John, You already know that I am waiting for the FTP BOF proposal for Maastricht. I can delay asking IESG to review this document till after the BOF, but if there is no BOF or nothing comes out of it, I don't think it is fair to delay the document just because something can be done better in a WG. Alexey, as the sponsoring Apps AD. Alexey, While I'd like to see a BOF too, and I suppose that Barry and I could get a proposal together, I think you and the IESG should look at this in a different way. As Paul Hoffman pointed out, there is a large community of FTP users out there. There are even multiple people, in multiple organizations, who spend significant time working on code for it. However, while several of them have been willing to write individual submission drafts, they have not been willing to show up at the IETF and do work, with each other, to get this standardized. For the record, while I agree with Paul, I'd also suggest that, even if the relevant community were much smaller, it would be worthwhile to develop a coordinated effort to design and evaluate FTP modification proposals if only to ensure continued interoperability. Others may disagree, but our success record when we tell people not to do something that works well for them and, in their opinion, poses no risks, is terrible. All saying FTP is dead, go use something else can accomplish is to drive the work away from the IETF. That increases the risk of interoperability problems if those who are interested don't find another forum. If they do find another forum, it could strengthen some body who would like to eat our lunch in other areas, areas that we have not chosen to discard. However, my view is that there is not, and should not be, meaningful community consensus for putting any (or all) of these proposals on the Standards Track unless a coordinated effort is possible. If someone from the relevant community needs help putting a BOF proposal together, I'd be happy to help. But, absent signs of willingness, within that community, to participate actively and take leadership roles, I don't see a BOF as being helpful. It might just confirm that there is a problem (which we know) and that no one is actually willing to work together rather than writing individual proposals. So my answer would be that considering these documents in an uncoordinated way as individual submissions is a bad idea. The alternative to a WG (or some coordination alternative) should not be well then, we have to process and approve the individual submissions. It should be if the FTP community can't organize itself sufficiently, even with offers of help, to put a WG (or other coordination process) together, then IETF review and value-added is almost meaningless. If that were to be the case, those involved should revise their documents into, e.g., Paul's and Robert's clever idea for an FTP extension for virtual hosts, publish them as Informational, enter the relevant bits into the registry, and move on. I'd also suggest that those who don't like FTP and think we should do no more work on it should not be complaining about this draft, or others, but should be writing an I-D explaining their case. If they can get enough consensus to get that explanation published as a BCP or standards-track document moving FTP to Historic, so be it (although I'd be surprised). If not and their arguments are well-reasoned and documented, I assume that the ISE would be as welcoming to their contribution as he would be to well-written protocol descriptions of existing practices or strongly-motivated proposals. I think keeping these documents off standards track because there isn't a critical mass of designers and developers willing to do work would be a sad outcome. However, unless the community of folks proposing these extensions are willing to come forward and start working with each other in a coordinated and consensus-establishing way, I think it is by far the better outcome than more uncoordinated and mutually underdesigned standards-track extensions. best, john p.s. I've been trying to avoid saying a protocol-developing WG is the only way although it is certainly my first preference. Maybe an FTP-specific review team that would contain at least some appointed experts and that worked entirely by correspondence would be adequate. Maybe we could do something intense in a meeting or two to lay out design principles against which the individual submissions could then be evaluated. Maybe you or others can come up with some other idea, even if it were radical enough to require a 3933 experiment proposal first. But I think that anything that goes on the standard track has to reflect IETF value-added and some reasonable level of informed IETF consensus that the idea is a good one, both individually and in context. And, right now, this document doesn't meet
Re: Last Call: draft-hethmon-mcmurray-ftp-hosts (File Transfer Protocol HOST Command) to Proposed Standard
On 5/12/10 2:39 PM, John C Klensin wrote: Others may disagree, but our success record when we tell people not to do something that works well for them and, in their opinion, poses no risks, is terrible. All saying FTP is dead, go use something else can accomplish is to drive the work away from the IETF. In this case, the IETF should say Use something more secure. The proposed enhancement combines multiple host's credentials to avoid transparent techniques that could offer network isolation as well. Your concern would be valid when there is also a commensurate effort at improving security. Unfortunately, the opposite is true. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hethmon-mcmurray-ftp-hosts (File Transfer Protocol HOST Command) to Proposed Standard
--On Wednesday, 12 May, 2010 16:04 -0700 Douglas Otis do...@mail-abuse.org wrote: ... In this case, the IETF should say Use something more secure. The proposed enhancement combines multiple host's credentials to avoid transparent techniques that could offer network isolation as well. Your concern would be valid when there is also a commensurate effort at improving security. Unfortunately, the opposite is true. Doug, Let's separate two issues. One is whether or not this particular proposal, with or without RFC 4217 (an existing Proposed Standard), is appropriate. If it is not, or cannot exist in harmony with 4217, then it reinforces my view that it should not be put on the Standards Track without a more comprehensive examination in the context of existing FTP work and proposals. The other is whether we should proceed with any FTP work at all. Especially in the context of 4217 (you were aware of that when you wrote your comments, weren't you), I find your remarks completely unpersuasive. One could reasonably argue that it is time to establish a SASL binding for FTP (maybe it is; a WG could figure that out), but I think it is hard to argue that FTP generally is any worse from an authentication, authorization, or privacy standpoint than any other protocol that we've protected by running it over an encrypted tunnel. YMMD, of course. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)' to Proposed Standard
The IESG has approved the following document: - 'Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) ' draft-ietf-isms-dtls-tm-14.txt as a Proposed Standard This document is the product of the Integrated Security Model for SNMP Working Group. The IESG contact persons are Sean Turner and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-dtls-tm-14.txt Technical Summary This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. Working Group Summary This ID is the product of the ISMS WG. The WG went over several revisions of this document and the document and all WG last call comments have been resolved. There has been strong WG consensus to publish this document as Proposed Standard. Document Quality There are two known implementations in progress of the (D)TLS Transport Model. Personnel Juergen Schoenwaelder (j.schoenwael...@jacobs-university.de) is the document shepherd. Sean Turner is the Responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Using Advanced Encryption Standard (AES) Counter Mode with IKEv2' to Informational RFC
The IESG has approved the following document: - 'Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 ' draft-ietf-ipsecme-aes-ctr-ikev2-07.txt as an Informational RFC This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Sean Turner and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-07.txt Technical Summary This document describes how to use the AES-CTR mode with an explicit initialization value to protect IKEv2 messages after keys are established. Working Group Summary This is the product of the IPSECME WG. Nothing worth noting: it got a small but adequate amount of review. Document Quality There are already a bunch of implementations based on developers guessing how to do this; to the best of our knowledge, those implementations match what is described in this document. Personnel Paul Hoffman (paul.hoff...@vpnc.org) is the document Shepherd. Sean Turner (turn...@ieca.com) is the Responsible Area Director. The IANA Expert(s) for the registries in this document is Tero Kivinen (kivi...@iki.fi). RFC Editor Note 1) Please remove the following from the 1st page: Updates: RFC4307 (if approved) 2) Please move the reference to [RFC3686] in Section 7.2 to be the 1st reference in 7.1 (i.e., make it a normative reference). 3) Add the following as a new last paragraph in Section 1: Implementers need to carefully consider use of AES-CTR over the mandatory to implement algorithms in [RFC4307] because the performance improvements of AES-CTR are minimal in the context of IKEv2. Furthermore, these performance improvements may be offset by the Counter Mode-specific risk of a minor, hard to detect, implementation issue resulting in total security failure. 4) Please note that this is intended for informational - not standards as indicated in the header of the draft. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-avt-rapid-rtp-sync (Rapid Synchronisation of RTP Flows) to Proposed Standard
The IESG has received a request from the Audio/Video Transport WG (avt) to consider the following document: - 'Rapid Synchronisation of RTP Flows ' draft-ietf-avt-rapid-rtp-sync-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 i...@ietf.org mailing lists by 2010-05-26. 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-avt-rapid-rtp-sync-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18487rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
