Re: Last Call: draft-ietf-yam-rfc4409bis-02.txt (Message Submission for Mail) to Full Standard
--On August 11, 2011 6:37:52 -0700 The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Yet Another Mail WG (yam) to consider the following document: - 'Message Submission for Mail' draft-ietf-yam-rfc4409bis-02.txt as a Full Standard I have read this draft and support advancing it to Full Standard as written or with modifications suggested by others. My comment on issues raised: Russ Housley's discuss: The document is more helpful to implementers if it has an informational downward reference to deployed signing technologies such as DKIM and multipart/signed (RFC 2480, RFC 1847) so that implementers know to consider the impact of message modification on those technologies. Normative language on that topic is best avoided so the document would be improved by removing the SHOULD related to those technologies. I believe the alternative text that was proposed is fine, but I would also be fine with the current text and also with dropping the offending paragraph if necessary to advance the specification. Informative reference to RFC 6186: As much as I like 6186 and hope it deploys, there is not sufficient deployment today to justify a reference from a full standard. Informative reference to RFC 5068 / BCP 134: I think an informative reference would be helpful to readers, but if adding that reference would cause an approval delay then expedience is more important. SMTP AUTH / STARTTLS: I have seen SMTP AUTH and STARTTLS work well operationally between multiple independent implementations of submission. Problems with those technologies related to MTA relay are unrelated to this submission draft and thus need no additional text in this draft. - Chris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
I have read version 08 and support this proposal. - Chris --On July 27, 2011 17:46:22 -0400 Jari Arkko jari.ar...@piuha.net wrote: Here's the link: http://tools.ietf.org/html/draft-housley-two-maturity-levels ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard
--On December 2, 2009 11:12:26 +0200 Yoav Nir y...@checkpoint.com wrote: On Dec 2, 2009, at 9:04 AM, Chris Newman wrote: This the most time-sensitive and security-critical IETF draft with respect to impact on the Internet community that I have seen in 17 years of IETF participation. This is the part I disagree with. Since that's a statement about my observations, you'd have to propose a different draft that better met that criteria in the last 17 years and get me to agree ;-) New extensions to protocols will take years to deploy. There's no getting around this. SSL/TLS servers that do not depend on renegotiation can disable renegotiations entirely. They can do this NOW. SSL/TLS servers that rely on renegotiation only for the upgrade-to-mutual feature for web servers can disable client-initiated renegotiations, and tweak their web applications so that the prefix injection doesn't matter. The can do this NOW. (We did) The only real case of using renegotiation that I've heard about was identity protection, where the client connects anonymously first, and then presents the certificate during the (encrypted) renegotiation. This is probably very rare, and accounts for a fraction or a percent of SSL use. So I don't think we should sit on our thumbs or even wait until the next face-to-face meeting, but whatever the RFC says, it will take years to deploy on the general Internet. We should hurry, but we shouldn't rush into things. The problem is more a customer-service one than a purely technical one: there's a real problem with just turning off SSL/TLS renegotiation by default. Yes, it's what vendors are working on doing, but it's just an interim solution. Basically, a vendor has to go to an HTTP server customer and say: You need to patch your HTTP server to stop a security vulnerability tech babble, but it might break your server deployment if tech babble, you can work around that problem if you do complex stuff or set flag so you stay vulnerable. It doesn't matter if the downside only impacts 1% of the HTTP server customers as the analysis of whether they'll be impacted may take time and money and that 1% may be the people who most urgently need the vulnerability fixed. When the vulnerability in the IETF specification is fixed and has made it to 2-3 major browser vendors, the message to HTTP server customers becomes more reasonable (albeit still unsatisfactory). While the complex stuff is feasible for a vendor with a small HTTP footprint and solid tech knowledge like yourself, it's less feasible for large corporate sites that would have to analyze thousands of HTTP-based services. - Chris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer
--On December 2, 2009 15:19:53 +0100 Martin Rex m...@sap.com wrote: 1. Running code: multiple implementations and interop testing was performed on an earlier version of draft-ietf-tls-renegotiation. Even EKR admitted that implementing the update is an insignificant amount of work. Pushing this point, that there were interoperable implementations when this proposal was made in the IETF smells very much like a request for rubber stamping. The IETF's motto is rough consensus and running code. So running code matters. rubber stamping is only a problem if incompatible changes are refused, but the fact such changes were made makes that straw man moot. 4. The mrex proposal requires use of TLS_RENEGO_PROTECTION_REQUEST in some circumstances. That approach is untested in the field and I have concerns it will negatively impact middleboxes. Huh? That sounds extremely unbelievable. First, I'll reiterate that I found both proposals acceptable, so the four points I made were all matters of design preference for this situation and not issues I find strongly compelling. The issue with middleboxes was raised by others and is a straw man. There are government standards that have a fixed list of cipher suites and most clients can be configured to comply with those standards today. Given the TLS standards available at the time, a middlebox which enforced the presence of just those cipher suites and no others in the TLS handshake would reasonably be expected to be forwards compatible. Use of a mandatory-to-implement cipher suite value will require such middleboxes to be upgraded, thus slowing deploying. I'm not a fan of middleboxes, but we shouldn't break them gratuitously. As draft-ietf-tls-renegotiation allows use of either the cipher suite value or the extension for C-S signaling, that mitigates the concern -- the field can choose the mechanism that works best. I consider this a defect in draft-ietf-tls-renegotiation-01. There should be exactly **ONE** signaling mechanism for the initial ClientHello on a connection so that extensions-tolerant but extensions-free Servers will not be force to wade through lists of extensions sent by clients. I'd be fine with one signaling mechanism as long as it's the mechanism that's been standardized since 2006 and backwards-compatible with correct implementations since 1999 (TLS 1.0). If we're misusing a cipher suite value as a protocol extensibility flag, an issue I'm willing to compromise on despite the lack of strong evidence it's necessary, we unfortunately need two signaling mechanisms: one that's standard that we know will work with modern correct implementations, and one a kludge that works with very old software, but might break good-faith modern implementations (like the middlebox straw man above). The existing fallbacks or conservative approaches give you a hint where you may expect interop problems. TLS extensions are a known interop problem. While I've seen evidence of bugs in TLS extension handling, and backwards compatibility fallback code that's been present in browsers since 1999, I've seen no evidence that extensions are an interoperability problem for correct standards-compliant TLS implementations or that such fallback code is necessary in operation today. - Chris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard
I strongly support publishing this draft either in its present form or with any modification that does not impact the protocol's security analysis. This the most time-sensitive and security-critical IETF draft with respect to impact on the Internet community that I have seen in 17 years of IETF participation. As such, I strongly support the decision to start IETF last call early as permitted by RFC 2418 section 7.4. I also encourage the IESG to move this document to the front of the queue for all support organizations (Secretariat, IANA, RFC editor) when processing occurs and to avoid holding a blocking DISCUSS after the telechat unless that blocking issue is more serious than the ongoing presence of this TLS security vulnerability on the Internet. === Three changes to draft-ietf-tls-renegotiation-01 I consider important (but not blocking): * The header should explicitly state it Updates RFC 5246, 4346, 4366, 2246. This gets forward pointers in the RFC index to increase chances implementers of those specs will also find this one. This is also necessary for RFC 5246 as this creates an exception to a MUST NOT. * There is an error-of-fact in the introduction; this is incorrect: If certificate-based client authentication is used, the server will believe that the initial traffic corresponds to the authenticated client identity. This statement is true only for application protocols with a badly designed state transition from unauthenticated to authenticated state. That is primarily limited to HTTPS and protocols based on HTTPS. It is not true for most other IETF application protocols including SMTP, POP, IMAP, LDAP, NNTP, BEEP and XMPP (however, I suspect all of these are impacted by the TLS vulnerability in other ways). Changing is used to is used with HTTPS would correct the error. * Nomenclature: when discussing TLS_RENEGO_PROTECTION_REQUEST, the term cipher suite value needs to be used instead of cipher suite, and the text needs to explicitly state that TLS_RENEGO_PROTECTION_REQUEST is not a cipher suite (it is not sufficient to say it can't be negotiated). This is important for evaluating implementations against government standards that dictate which cipher suites an implementation may advertise. Evaluation relative to draft-mrex-tls-secure-renegotiation-03: Kudos to Martin Rex for producing such a good alternate proposal. The introductory text up to and including section 4.1 is very good and would improve draft-ietf-tls-renegotiation. While I would support a consensus to publish the mrex document as the solution, I presently prefer draft-ietf-tls-renegotiation-01 for four reasons: 1. Running code: multiple implementations and interop testing was performed on an earlier version of draft-ietf-tls-renegotiation. 2. Impact to core protocol handshake: The mrex proposal alters the handshake to include data that is not exchanged in-protocol. If this impacts PKCS#11 hardware tokens or other SSL accelerators (an issue mentioned by Dr Stephen Henson on the TLS list on Nov 26, 2009 19:24:55 +) that could severely impact deployment. I do not know if that concern applies to the mrex proposal, but I know it does not apply to the draft-ietf-tls-renegotiation. The point being the mrex proposal requires more analysis to verify impact. As we're in a hurry, I prefer to easier to analyze proposal. 3. Extensibility. In my experience one of the protocol design features most important to get right is extensibility. SSL/TLS didn't really get that right until v1.2 (which is causing problems now). As draft-ietf-tls-renegotiation uses the TLS extension facility more extensively, it will help future-proof more implementations. 4. The mrex proposal requires use of TLS_RENEGO_PROTECTION_REQUEST in some circumstances. That approach is untested in the field and I have concerns it will negatively impact middleboxes. As draft-ietf-tls-renegotiation allows use of either the cipher suite value or the extension for C-S signaling, that mitigates the concern -- the field can choose the mechanism that works best. My take on some controversial issues: * There may not be a sufficient number of extension intolerant SSL/TLS servers in operation to justify the added complexity of TLS_RENEGO_PROTECTION_REQUEST. However, I do not object to inclusion as it's possibly helpful for some alleged extension intolerant servers compliant with early drafts of SSLv3 and it helped move closer to WG consensus. * I believe Bodo Moeller's proposal to exclude client's verify_data from ServerHello improves the protocol, but I do not find it a blocking or compelling issue. * I find the present text in security considerations on identity change mid-stream acceptable from my perspective as an application developer. However, I do not care if that text is included or excluded from the approved version as it is ancillary to the important
Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC
--On November 4, 2008 6:28:19 -0800 The IESG [EMAIL PROTECTED] wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DNS-Based Service Discovery ' draft-cheshire-dnsext-dns-sd-05.txt as an Informational RFC As a technical contributor and end user, I strongly support publication of this document, although I would prefer it was on the standards track. I very much appreciate the text discussing why certain design decisions were made, as well as mentioning implementation/UI issues where people made mistakes in the past. Other comments: Section 4: The Instance portion of the Service Instance Name is a single DNS label, containing arbitrary precomposed (Unicode Normalization Form C [UAX15]) UTF-8-encoded text [RFC 3629]. Have you considered referencing RFC 5198 instead? It's based on the same normalization form, but has some minor restrictions/clarifications that are likely to improve interoperability. As your current text allows line breaks (was that intentional?) it would be helpful to have a canonical form for line breaks that 5198 defines. If you didn't intend to allow line breaks you might want to recommend against their use as well. intended to ever be typed in by a user accessing a service; the user accesses a service by selecting its name from a list of choices presented on the screen. Since this list may also be presented by a screen reader to the blind, and selection from the list is a mandatory part of the user experience, have you considered adding a way to include a language tag to assist screen readers in their translation to voice? BCP 18 has some discussion of this. Is there implementation experience that a language tag is not necessary for this situation? Section 19: What is the title of the registry that will be listed on IANA's web page? Do you believe it would be possible to merge the new service registry with this one: http://www.iana.org/assignments/gssapi-service-names creating a single service-name registry shared by these protocols? Thanks, - Chris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
--On April 15, 2008 13:30:01 -0700 IESG Secretary [EMAIL PROTECTED] wrote: NETCONF Data Modeling Language (netmod) I support the creation of this WG. 2. The YANG data modeling language and semantics (proposed standard) ... 5. Mapping rules of YANG to DSDL data modeling framework (ISO/IEC 19757), including annotations for DSDL to preserve top-level semantics during translation (proposed standard). A great deal of effort has been put into designing standard XML data modeling languages over many years and given that both DTD and XML Schema have significant weaknesses (particularly in the area of extensibility), a DML for XML is clearly difficult and requires special expertise. (5) is critical to demonstrating that YANG has learned from the mistakes of past XML-DMLs with respect to extensibility and other areas. The simpler (5) happens to be, the more confident I will become that YANG is following best practices for XML DMLs. 4. YIN, a semantically equivalent fully reversible mapping to an XML-based syntax for YANG. YIN is simply the data model in an XML syntax that can be manipulated using existing XML tools (e.g., XSLT) (proposed standard) If 5 is as simple as I think it should be, then I suspect there will be little semantic difference between 4 5 and much additional utility in 5. I'd prefer if the WG was free to drop work item 4 in the event I'm correct. If 2 provides the human-friendly form and 5 provides the form that best leverages existing standard XML tools and parsers then I see no value in 4 which is both less human-friendly than 2 and less XML-tool-friendly than 5. In the event I'm wrong and there are significant semantic differences between 2/4 and 5 that are well justified, then I don't object to continued work on 4. I suggest adding a sentence to the charter: In the event work items 4 and 5 are semantically similar, the WG may choose to omit work item 4. I'm interested in other opinions on this topic. - Chris ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hutzler-spamops (Email Submission: Access and Accountability) to BCP
My last call comment as a technical contributor (apologies for the lateness): Overall, this is a very important document which I support. I'm not fond of the current title because I believe it will cause the document to be ignored by the people who most need to read it. I suggest: Operational Requirements for Email Submission The best way to improve this document otherwise would be by deleting text from the document and trimming it down to just the best practice requirements and recommendations. Move the descriptive text about architecture and how the email system works somewhere else (e.g. Dave's email architecture document). Operators will run MSAs on port 25 if they need to, so it's unnecessary to make a normative recommendation about that. At some point it may cease to be useful to run an MSA on port 25 so requiring an update to this document when that happens is short-sighted. - Chris The IESG wrote on 6/6/07 10:32 -0400: The IESG has received a request from an individual submitter to consider the following document: - 'Email Submission: Access and Accountability ' draft-hutzler-spamops-07.txt as a BCP 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 2007-06-20. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Note that this is a second run of the Last Call. The first Last Call happened in 2005, and the current version tried to address all the comments received then. Taking into account the amount of time since the first Last Call the Area Director and the editors decided to run again a two weeks Last Call. The file can be obtained via http://www.ietf.org/internet-drafts/draft-hutzler-spamops-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=11673 rfc_flag=0 ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-siemborski-rfc1734bis (POP3 SASL Authentication Mechanism) to Proposed Standard
I have reviewed this document and support moving it forward on the standards track. On procedural nit: In section 4, the document states: The service name specified by this protocol's profile of SASL is pop. A note in the IANA Considerations section is needed which directs IANA to update the GSSAPI/SASL service name registry to reference this document. The service name registry is located here: http://www.iana.org/assignments/gssapi-service-names - Chris The IESG wrote on 1/24/07 16:29 -0500: The IESG has received a request from an individual submitter to consider the following document: - 'POP3 SASL Authentication Mechanism ' draft-siemborski-rfc1734bis-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 2007-02-21. Exceptionally, comments may be sent to iesg@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-siemborski-rfc1734bis-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=10914 rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
