Re: Last Call: draft-ietf-abfab-gss-eap-naming-05.txt (Name Attributes for the GSS-API EAP mechanism) to Proposed Standard
Cantor, Scott canto...@osu.edu writes: On 10/6/12 12:50 PM, Simon Josefsson si...@josefsson.org wrote: Thanks, now I understand better. I would feel more comfortable if there were a precise reference to what well-formed serialization means, especially since there is a MUST here. It ought to be possible to determine algorithmically whether something conforms or not. Sometimes I get the impression that well-formed just refers to syntactical correctness, whereas namespace considerations are more semantic. Actually namespaces extend the notion of syntax in XML, so they're not just semantic. When you parse while namespace-aware, there are normative rules for that grammar that include having namespaces declared properly. I think you probably want to reference the notion of namespace well-formed, so my suggested text could be adjusted to include that instead of just well-formed. http://www.w3.org/TR/2009/REC-xml-names-20091208/#Conformance If the document use the term namespace well-formed and/or include the reference that would resolve the issue for me. Thanks for clarifying this. /Simon
Re: Last Call: draft-ietf-abfab-gss-eap-naming-05.txt (Name Attributes for the GSS-API EAP mechanism) to Proposed Standard
Cantor, Scott canto...@osu.edu writes: On 10/4/12 4:58 PM, Sam Hartman hartm...@painless-security.com wrote: Any advice from the SAML community on responding to the following comment from Simon: If the value is not simple or is empty, then the raw value(s) of the GSS name attribute MUST be the well-formed serialization of the saml:AttributeValue element(s) encoded as UTF-8. The display values are implementation-defined. Question: what serialization is intended here? An example here would make this more clear. I think that was my text, possibly. I just meant that it's the XML representation of the element, but well-formed, meaning that you have to make sure any namespaces are declared, etc. so that if a parser were to parse that serialization, it would be well-formed XML. Thanks, now I understand better. I would feel more comfortable if there were a precise reference to what well-formed serialization means, especially since there is a MUST here. It ought to be possible to determine algorithmically whether something conforms or not. Sometimes I get the impression that well-formed just refers to syntactical correctness, whereas namespace considerations are more semantic. Perhaps the text would be improved by adding a sentence between the two sentences above like this: This means, for example, that the XML code includes all necessary namespace declarations, so that a parser is able to parse and understand the meaning of the raw value. If there is a suitable reference to some XML standard, that is probably better. /Simon
Re: Last Call: draft-ietf-abfab-gss-eap-naming-05.txt (Name Attributes for the GSS-API EAP mechanism) to Proposed Standard
I found no major issues with this document. I support publishing it if the minor issues below are resolved. The document is written in a rather information dense style, but I can't come up with any easy way to make it more accessible. More examples and illustrations would help, but I don't see this as sufficient reason to not move forward. /Simon Minor issues: The naming extensions [I-D.ietf-kitten-gssapi-naming-exts]to the ^ insert SPC mechanism allows an Authentication/Authorization/Accounting peer to ^ ... [I-D.ietf-abfab-gss-eap] allows an Authentication/Authorization/ Accounting peer to provide authorization attributes along side an ^ add '(AAA)'. Otherwise the AAA acronym is not expanded. The first is a URI describing the format of the name. The second ^^^ Expand acronym on first use. The first is a URN indicating that the name is a SAML attribute and ^^^ Expand acronym on first use. context Section 4 are issued by the same party performing the ^ ^ I believe parenthesis should be inserted here. information is combined from AAA and SAML sources. The SAML IDP and ^^^ Expand acronym on first use. GSS_S_COMPLETE. Attributes MAy be absent or values MAY change in ^ Typo. value of this attribute would first wait until GSS- _Accept_sec_Context returned GSS_S_COMPLETE. Then the application ^^^ Typo, should be 'GSS_Accept_sec_context'. Check this throughout the document, there are more incorrect uses. GSS_Get_Name_attribute passing this name and an attribute of ^ Typo, should be 'GSS_Get_name_attribute'. Check this throughout the document, there are more incorrect uses. This attribute is returned with the authenticatedoutput of ^ Typo. assertion, then An attribute with the name ^ Typo. urn:ietf:params:gss:federated-saml-attribute urn:oasis:names:tc:SAML:2.0:attrname-format:uri urn:oid:1.3.6.1.4.1.5923.1.1.1.7 could be returned from ^ Should there really be a SPC at the end? It is also not clear that there is a SPC between the parts since they terminate the line. GSS_Inquire_Name. If an application calls GSS_Get_Name_attribute ^ Typo, 'GSS_Inquire_name' (and 'GSS_Get_name_attribute'...). If the value is not simple or is empty, then the raw value(s) of the GSS name attribute MUST be the well-formed serialization of the saml:AttributeValue element(s) encoded as UTF-8. The display values are implementation-defined. Question: what serialization is intended here? An example here would make this more clear. mechanisms are permitted to perform local policy checks on SAML ^ Typo, capitalize to 'M'. choices for non-IETf work. Expert review is permitted mainly to ^ Typo.
Re: copyright notices in RFC 6716
Russ, I had missed that section (which seems like a wonderful section btw). However the license isn't what my initial question was about, so this is a red herring. This also explains why I wasn't able to follow Cullen's initial reply. My question was about the copyright header. Let's see if I can be clearer... The TLP says the copyright header must be: Copyright (c) insert year IETF Trust and the persons identified as authors of the code. All rights reserved. but the code in the document uses: Copyright 1994-2011 IETF Trust, Xiph.Org, Skype Limited, Octasic, Jean-Marc Valin, Timothy B. Terriberry, CSIRO, Gregory Maxwell, Mark Borgerding, Erik de Castro Lopo. All rights reserved. The difference between these two forms is what I'm wondering about. Essentially what I'm asking is which one applies of: 1) Was the copyright header variation permitted intentionally for this document as an exception to the TLP? 2) Nobody noticed that the copyright header was different from what the TLP demands. 3) Something else. /Simon Russ Housley hous...@vigilsec.com writes: Simon: The RFC contains the usual boilerplate and one additional paragraph. The rights granted in the additional paragraph align with the rights that the authors wanted to provide. Here is the additional paragraph: The licenses granted by the IETF Trust to this RFC under Section 3.c of the Trust Legal Provisions shall also include the right to extract text from Sections 1 through 8 and Appendix A and Appendix B of this RFC and create derivative works from these extracts, and to copy, publish, display and distribute such derivative works in any medium and for any purpose, provided that no such derivative work shall be presented, displayed or published in a manner that states or implies that it is part of this RFC or any other IETF Document. Russ On Sep 18, 2012, at 5:33 PM, Simon Josefsson wrote: Russ, I can't seem to align what you say with the document content. The rights granted by the license text in the document (quoted below) appears to me be identical to the TLP except that the copyright header also includes non-authors. Is this what you refer to with granting additional rights? My concern is not about rights granted (they appear to follow the TLD), but with the form of the copyright header that deviates from the TLD boilerplate. What puzzles me is that the explanation that I have received earlier is that variations beyond what the TLP demand is not permitted even if there is community support for the content of a particular document. I'm happy if this is now the policy, as it would allow including more source code into RFCs. /Simon Russ Housley hous...@vigilsec.com writes: Simon: The authors wanted to grant additional rights beyond those that are granted by the TLP. They indicated those rights in Section 10 of the internet-Draft. This was challenged during WG Last Call, and it was challenged during IETF Last Call. In each case, the authors make their desire clear and the community supported them. For this reason the IETF Trust granted the usual TLP rights and the additional rights as well. Russ On Sep 13, 2012, at 10:18 AM, Simon Josefsson wrote: All, I noticed that the recent RFC 6716 contains some reference code that contain the copyright and licenses notice reproduced below. The IETF TLP [1] mandates a certain form of copyright notices and the TLP does not, as far as I can see, permit varying the boiler plate in any way. Note that both companies and organisations are mentioned in the copyright notice in RFC 6716, besides individuals. Does this indicate a policy change, a mistake with that document, or something else? Btw, kudos to the RFC 6716 authors for shipping reference code! I hope this will establish a best practice for standards in the future. /Simon [1] http://trustee.ietf.org/license-info/IETF-Trust-License-Policy-20091228.htm Copyright 1994-2011 IETF Trust, Xiph.Org, Skype Limited, Octasic, Jean-Marc Valin, Timothy B. Terriberry, CSIRO, Gregory Maxwell, Mark Borgerding, Erik de Castro Lopo. All rights reserved. This file is extracted from RFC6716. Please see that RFC for additional information. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors
Re: copyright notices in RFC 6716
Russ, I can't seem to align what you say with the document content. The rights granted by the license text in the document (quoted below) appears to me be identical to the TLP except that the copyright header also includes non-authors. Is this what you refer to with granting additional rights? My concern is not about rights granted (they appear to follow the TLD), but with the form of the copyright header that deviates from the TLD boilerplate. What puzzles me is that the explanation that I have received earlier is that variations beyond what the TLP demand is not permitted even if there is community support for the content of a particular document. I'm happy if this is now the policy, as it would allow including more source code into RFCs. /Simon Russ Housley hous...@vigilsec.com writes: Simon: The authors wanted to grant additional rights beyond those that are granted by the TLP. They indicated those rights in Section 10 of the internet-Draft. This was challenged during WG Last Call, and it was challenged during IETF Last Call. In each case, the authors make their desire clear and the community supported them. For this reason the IETF Trust granted the usual TLP rights and the additional rights as well. Russ On Sep 13, 2012, at 10:18 AM, Simon Josefsson wrote: All, I noticed that the recent RFC 6716 contains some reference code that contain the copyright and licenses notice reproduced below. The IETF TLP [1] mandates a certain form of copyright notices and the TLP does not, as far as I can see, permit varying the boiler plate in any way. Note that both companies and organisations are mentioned in the copyright notice in RFC 6716, besides individuals. Does this indicate a policy change, a mistake with that document, or something else? Btw, kudos to the RFC 6716 authors for shipping reference code! I hope this will establish a best practice for standards in the future. /Simon [1] http://trustee.ietf.org/license-info/IETF-Trust-License-Policy-20091228.htm Copyright 1994-2011 IETF Trust, Xiph.Org, Skype Limited, Octasic, Jean-Marc Valin, Timothy B. Terriberry, CSIRO, Gregory Maxwell, Mark Borgerding, Erik de Castro Lopo. All rights reserved. This file is extracted from RFC6716. Please see that RFC for additional information. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
copyright notices in RFC 6716
All, I noticed that the recent RFC 6716 contains some reference code that contain the copyright and licenses notice reproduced below. The IETF TLP [1] mandates a certain form of copyright notices and the TLP does not, as far as I can see, permit varying the boiler plate in any way. Note that both companies and organisations are mentioned in the copyright notice in RFC 6716, besides individuals. Does this indicate a policy change, a mistake with that document, or something else? Btw, kudos to the RFC 6716 authors for shipping reference code! I hope this will establish a best practice for standards in the future. /Simon [1] http://trustee.ietf.org/license-info/IETF-Trust-License-Policy-20091228.htm Copyright 1994-2011 IETF Trust, Xiph.Org, Skype Limited, Octasic, Jean-Marc Valin, Timothy B. Terriberry, CSIRO, Gregory Maxwell, Mark Borgerding, Erik de Castro Lopo. All rights reserved. This file is extracted from RFC6716. Please see that RFC for additional information. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Re: copyright notices in RFC 6716
Cullen Jennings (fluffy) flu...@cisco.com writes: I was only peripherally involved in this and don't know all the in's and outs of this but let me try and provide a bit of information and hopefully someone from the IETF Trust or RFC Editor can correct me where I am wrong. Thanks. Input from members of the Trust, if they were involved, would be appreciated. The internet draft was done with the normal boiler plate that granted a bunch of rights to the IETF Trust. There was also text in the draft where the authors granted additional rights. The trust normally publishes the RFC with about the same license that is used in the draft however the Trust retains the rights to do whatever they want within the range of the license granted to them in the draft. In this case, the RFC was published with slightly different boiler plate than what was in draft. That is not the case, draft -16 had the same license. So no, I don't think the policy has changed, and no I don't think this was a mistake. I think the RFC Editor working with the IETF Trust and IETF legal advice made this change. My understanding of the reasons for the change was something like this makes it easier for some linux distribution to include the RFC with their distribution or something. I don't believe that is the case here. The license used is the same as normal license, only the copyright header is different. Distributions rarely cares who the copyright holder is. IETF rules says additional copyright notices aren't permitted. /Simon Keep in mind this is a weird RFC in that it includes a huge amount of normative code in the RFC. Hope this helps - and amazed anyone noticed. Cullen PS - I may have this all wrong - I'm not the person that knows but I hope that provides some help. On Sep 13, 2012, at 8:18 AM, Simon Josefsson si...@josefsson.org wrote: All, I noticed that the recent RFC 6716 contains some reference code that contain the copyright and licenses notice reproduced below. The IETF TLP [1] mandates a certain form of copyright notices and the TLP does not, as far as I can see, permit varying the boiler plate in any way. Note that both companies and organisations are mentioned in the copyright notice in RFC 6716, besides individuals. Does this indicate a policy change, a mistake with that document, or something else? Btw, kudos to the RFC 6716 authors for shipping reference code! I hope this will establish a best practice for standards in the future. /Simon [1] http://trustee.ietf.org/license-info/IETF-Trust-License-Policy-20091228.htm Copyright 1994-2011 IETF Trust, Xiph.Org, Skype Limited, Octasic, Jean-Marc Valin, Timothy B. Terriberry, CSIRO, Gregory Maxwell, Mark Borgerding, Erik de Castro Lopo. All rights reserved. This file is extracted from RFC6716. Please see that RFC for additional information. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Re: [AVTCORE] IPR requirements in document write-up
Stephan Wenger st...@stewe.org writes: (1) Are you aware of any IPR that applies to insert document name? (2) If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? For the majority of the documents I am working on, the answer to question (1) would be yes. The answer to question (2) would be quite often no. Based on my interpretation of the policy RFCs, I am in full compliance with language and spirit of the policy. I'm not doing anything fishy. I just don't talk about third party IPR, which is my right under the IETF's IPR policy. RFC 3669 section 5.7: https://tools.ietf.org/html/rfc3669#section-5.7 says for example It is good to notify the IETF of relevant IPR claims even when they are not one's own, and [6] says to do so as soon as possible. My interpretation has always been that partcipants are strongly encouraged to notify about third party patents. Withholding such information seems contrary to the spirit even if not the letter of the guidelines. There are additional advice given here: https://tools.ietf.org/html/rfc3669#section-5.7.1 /Simon
Re: Gen-ART LC Review of draft-ietf-kitten-sasl-saml-06
Ben Campbell b...@nostrum.com writes: -- section 4, 3rd and 4th paragraph (paragraph a and b) These seem like protocol affecting differences. If so, they need elaboration, such as normative statements and formal definitions, or references to such. -- section 5, general: The section seems to need further elaboration or references Hello Ben. Thank you for your review. Klaas pointed me at this part and I will try to work this out with you. Re section 4 I believe your comment is based on a misunderstanding. Let me try to explain what the intention is, and we can work out how to fix the text if needed. What is described in paragraph a) and b) are the protocol requirements that (implicitely) follow from GS2. There is nothing particular to this protocol in there. Let's take a step back: The purpose of GS2 is to map any GSS-API mechanism into a SASL mechanism. However, SASL-SAML is defined as a SASL mechanism (because SASL implementers wants it that way). The point of section 4 is to turn this SASL mechanism into a GSS-API mechanism that, after the SAML GSS-API mechanism is used via GS2, becomes identical to the SAML mechanism defined in the rest of the SASL-SAML document. This is a bit convuleted to describe, but this is the gist of it. (It would have been simpler to specify a SAML GSS-API mechanism and then let GS2 convert it to SASL automatically, but some SASL people doesn't want anything to do with GSS-API so this is a compromise to allow them to implement SAML-SASL without touching GSS-API.) I'm thinking that perhaps the above explanation would be useful to have in the document, to give some background. If you agree, I propose to resolve your section 4 comment by making this change: OLD: The SAML SASL mechanism is actually also a GSS-API mechanism. The SAML user takes the role of the GSS-API Initiator and the SAML NEW: This section specify a GSS-API mechanism that when used via the GS2 bridge to SASL behave like the SASL mechanism defined in this document. Thus, it can loosely be said that the SAML SASL mechanism is also a GSS-API mechanism. The SAML user takes the role of the GSS-API Initiator and the SAML Does this resolve your concern re section 4? Re your section 5 comment, I tend to agree. The section is quite brief because it was ripped out of section 3.1. I propose that we simply collapse this section back into 3.1 where it makes more sense. Thus: OLD: - See Section 5 for the channel binding gs2-cb-flag field. NEW: - The gs2-cb-flag MUST be set to n because channel binding data cannot be integrity protected by the SAML negotiation. (Note: In theory channel binding data could be inserted in the SAML flow by the client and verified by the server, but that is currently not supported in SAML.) And then remove section 5 completely. Section 3 and in particular section 3.1 already contains the relevant references and provides the context where the statements make sense. What do you think? Thanks, /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART Telechat Review of draft-ietf-kitten-sasl-saml-08
Ben Campbell b...@nostrum.com writes: -- section 7 Does the GSS-API description introduce security considerations? If not, please say so. I did not see a response to this comment. I missed this in my last e-mail. I propose we add another sub-section of the security considerations like this: 7.5. GSS-API specific security considerations Security issues inherent in GSS-API (RFC 2743) and GS2 (RFC 5801) apply to the SAML GSS-API mechanism defined in this document. Further, and as discussed in section 4, proper TLS server identity verification is critical to the security of the mechanism. I believe this should cover the relevant security considerations. Of course, having more implementation experience with the SAML mechanism used as a GSS-API mechanism may help to identify further security considerations for the GSS-API mechanism. However, I don't believe that is a show-stopper that prevent publication now. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
gareth.richa...@rsa.com writes: Some form of identifier will be required for the otp-algID in the PA-OTP-CHALLENGE and the PA-OTP-REQUEST and from what I remember about when this was first discussed, it was agreed that it would make sense to use the registry of identifiers already being established for PSKC rather than produce a duplicate one. My assumption was that a registry would be required to ensure that the URIs were unique. I think a separate registry is needed, RFC 6030 requires several things from a profile that shouldn't be required in order to support Kerberos OTP. See below. /Simon 12.4. PSKC Algorithm Profile Registry IANA has created a registry for PSKC algorithm profiles in accordance with the principles set out in RFC 5226 [RFC5226]. As part of this registry, IANA maintains the following information: Common Name: The name by which the PSKC algorithm profile is generally referred. Class: The type of PSKC algorithm profile registry entry being created, such as encryption, Message Authentication Code (MAC), One-Time Password (OTP), Digest. URI: The URI to be used to identify the profile. Identifier Definition: IANA will add a pointer to the specification containing information about the PSKC algorithm profile registration. Algorithm Definition: A reference to the stable document in which the algorithm being used with the PSKC is defined. Registrant Contact: Contact information about the party submitting the registration request. Deprecated: TRUE if this entry has been deprecated based on expert approval and SHOULD not be used in any new implementations. Otherwise, FALSE. PSKC Profiling: Information about PSKC XML elements and attributes being used (or not) with this specific profile of PSKC. PSKC algorithm profile identifier registrations are to be subject to Specification Required as per RFC 5226 [RFC5226]. Updates can be provided based on expert approval only. Based on expert approval, it is possible to mark entries as deprecated. A designated expert will be appointed by the IESG. IANA has added two initial values to the registry based on the algorithm profiles described in Section 10. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-faltstrom-5892bis-04.txt (The Unicode code points and IDNA - Unicode 6.0) to Proposed Standard
Pete Resnick presn...@qualcomm.com writes: On 5/29/11 1:29 PM, Simon Josefsson wrote: John C Klensinjohn-i...@jck.com writes: --On Sunday, May 29, 2011 08:58 +0200 Simon Josefsson si...@josefsson.org wrote: in a Unicode 6.0 environment, evaluate U+19DA as PVALID and therefore not raise that error, then it is not compliant with RFC 5892, irrelevant of the Updates status of the present document. I don't see how. My code uses the tables from RFC 5892 which were generated in an Unicode 5.2 environment. Then you are, in my terminology, implementing RFC 5892 in a Unicode 5.2 environment. Your implementation is carrying the 5.2 environment with it. The Unicode library used during run-time, for RFC 5891, is version 6.0 though. But I now think I see the source of the misunderstanding: You could reasonably say that your implementation is conformant but current only to Unicode 5.2. If you are willing to say that, I guess you don't need to change anything. I claim my implementation is compliant to all requirements in RFC 5890, RFC 5891, RFC 5892 and RFC 5893. There's the problem. You can't claim that your implementation is compliant with the above RFCs without also mentioning the version of Unicode you are using, precisely because the RFCs are now Unicode version independent. Your implementation that evaluates U+19DA as PVALID is complaint with the RFCs *as applied to Unicode version 5.2*. Your implementation that evaluates U+19DA as PVALID is *not* complaint with the RFCs *as applied to Unicode version 6.0*. The correct claim would then be that I use Unicode 5.2 (for tables) and Unicode 6.0 (for run-time). I believe this is typical of how IDNA2008 will be deployed: the IDNA2008 implementation uses pre-computed tables for one Unicode version fixed at compile-time, and the Unicode library on the system may be more rapidly changing and could support a later version of Unicode. Can you point to some (normative) requirement in IDNA2008 that forbids this? /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-faltstrom-5892bis-04.txt (The Unicode code points and IDNA - Unicode 6.0) to Proposed Standard
Pete Resnick presn...@qualcomm.com writes: On 5/26/11 6:19 AM, Simon Josefsson wrote: Dear IESG, Is the intention that this document will update RFC 5892 or not? The document does not contain a Updates: header but the draft name suggests otherwise to me, hence my question. The IESG has not yet discussed this topic, and I will be bringing it to their attention. We may decide to include Updates: RFC 5892; we may not. Thanks for clarifying. If the document does not update RFC 5892 (or some other document), I support publishing this document because it will not affect my implementation of RFC 5892. If the document updates RFC 5892, in order to remain compliant with the RFCs I would have to modify my implementation and make a backwards incompatible change. Today U+19DA converts to xn--pkf. With this document, I would have to raise an error for that input instead. My understanding is that the above statements are, if not false, at least incomplete. It is not true, at least with regard to RFC 5892, that today U+19DA converts to xn-pkf because RFC 5892 doesn't do any converting. Sure. RFC 5892 is part of the IDNA2008 set and primarily RFC 5891 describe the conversion. RFC 5891 uses the properties defined in RFC 5892. It *is* true that the code point U+19DA is PROTOCOL VALID using the algorithm in RFC 5892 as applied to Unicode 5.2, and is DISALLOWED using the algorithm in RFC 5892 as applied to Unicode 6.0. Right. If what you mean above is that your implementation intends to raise an error for DISALLOWED code points and would, That is required by RFC 5891 section 4.2.2: 4.2.2. Rejection of Characters That Are Not Permitted The candidate Unicode string MUST NOT contain characters that appear in the DISALLOWED and UNASSIGNED lists specified in the Tables document [RFC5892]. and section 5.4: Putative U-labels with any of the following characteristics MUST be rejected prior to DNS lookup: o Labels containing prohibited code points, i.e., those that are assigned to the DISALLOWED category of the Tables document [RFC5892]. in a Unicode 6.0 environment, evaluate U+19DA as PVALID and therefore not raise that error, then it is not compliant with RFC 5892, irrelevant of the Updates status of the present document. I don't see how. My code uses the tables from RFC 5892 which were generated in an Unicode 5.2 environment. My IDNA2008 code may eventually run in an Unicode 6.0 environment, or any other future version of Unicode. I can't control the Unicode version used, and from what I understand this is one of the features of IDNA2008. Implementations need not lock down the Unicode version to a single Unicode version, as they had to do for IDNA2003. If this model is not permitted, I believe there are bigger problems. To avoid doubt, and to back up your assertment that my implementation is non-compliant, please point to the MUST or SHOULD in RFC 5892 that forbis this, to me, logical implementation approach. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-faltstrom-5892bis-04.txt (The Unicode code points and IDNA - Unicode 6.0) to Proposed Standard
John C Klensin john-i...@jck.com writes: --On Sunday, May 29, 2011 08:58 +0200 Simon Josefsson si...@josefsson.org wrote: in a Unicode 6.0 environment, evaluate U+19DA as PVALID and therefore not raise that error, then it is not compliant with RFC 5892, irrelevant of the Updates status of the present document. I don't see how. My code uses the tables from RFC 5892 which were generated in an Unicode 5.2 environment. My IDNA2008 code may eventually run in an Unicode 6.0 environment, or any other future version of Unicode. I can't control the Unicode version used, and from what I understand this is one of the features of IDNA2008. Implementations need not lock down the Unicode version to a single Unicode version, as they had to do for IDNA2003. It seems to me that this is exactly where we are having a misunderstanding. In terms of determining conformance, those tables are not normative, so it is not possible to say I implemented the tables in RFC 5892 and therefore I conform to the standard. The closest you can get would be to say I implemented the rules and tested against the tables when those rules were applied to Unicode 5.2 and therefore have great confidence in my implementaton, but conformance statements stop with implemented the rules correctly. For practical reasons, we expect to see production implementations using tables or other abstractions of the rules that are somewhat pre-compiled, not applying the rule set each time. One consequence of this is that a given table-based implementation is inevitably dependent on versions of Unicode even if the Standard (and its conformance requirements) is not. Right, and that describes my implementation. There is no difference in behaviour of an implementation that uses the informative tables in RFC 5892 directly or one that pre-computes the table at compile time using Unicode 5.2. The data and output are the same in both cases. So I don't follow where you think the misunderstanding is? I agree with what you say here. If this model is not permitted, I believe there are bigger problems. To avoid doubt, and to back up your assertment that my implementation is non-compliant, please point to the MUST or SHOULD in RFC 5892 that forbis this, to me, logical implementation approach. The key is the text in Section 4 that says: The table in Appendix B shows, for illustrative purposes, the consequences of the categories and classification rules, and the resulting property values. The list of code points that can be found in Appendix B is non-normative. Sections 2 and 3 are normative. It seems to me that is very clear about the relationship between the rules and the tables. That relationship is reiterated in Section 7.1.1 of RFC 5892. s/5892/5894/ Sure. But that does not prove (or disprove) Pete's claim that my implementation is non-compliant. You could reasonably say that your implementation is conformant but current only to Unicode 5.2. If you are willing to say that, I guess you don't need to change anything. I claim my implementation is compliant to all requirements in RFC 5890, RFC 5891, RFC 5892 and RFC 5893. While we recognize that you have no control over the Unicode version in use, good sense suggests that systems will update versions of Unicode (including all of the associated tables and support routines as applicable) and versions of your library together, That is unrealistic. Traditional operating systems are already so complex that upgrading them to one Unicode versions across all software pieces (Java, Perl, SQL databases, web browsers, word processors, etc) is economically infeasible. Modern operating system rely so much on network services that it is not even useful to decouple the local system from external systems. Essentially the system is identical to the Internet. A flag day to upgrade to the latest Unicode version across the Internet is, despite how infinitely pleasant that would be, impossible. If it was possible to upgrade software components to the latest Unicode version in a controlled way, the IDNA2003 model would have worked fine. Fortunately, I believe IDNA2008 does not require tight Unicode version synchronization. In fact, I believe one of the features with IDNA2008 is exactly that it doesn't require all Unicode versions to be in sync in all parts of the Internet. While that should be clear from the context of the discussions in RFC 5891 and 5892, RFC 5894 is quite explicit about it in the second bullet of Section 7.1.2: o The Unicode tables (i.e., tables of code points, character classes, and properties) and IDNA tables (i.e., tables of contextual rules such as those that appear in the Tables document), must be consistent on the systems performing or validating labels to be registered. Note that this does not require that tables reflect the latest version
Re: Last Call: draft-faltstrom-5892bis-04.txt (The Unicode code points and IDNA - Unicode 6.0) to Proposed Standard
Paul Hoffman paul.hoff...@vpnc.org writes: On May 26, 2011, at 4:19 AM, Simon Josefsson wrote: Dear IESG, Is the intention that this document will update RFC 5892 or not? The document does not contain a Updates: header but the draft name suggests otherwise to me, hence my question. As document co-editor, let me say definitively: this document does *not* update RFC 5892. The filename is an artifact of the early consideration and, as you know, disappears once the document is published as an RFC. Note the information at https://datatracker.ietf.org/doc/draft-faltstrom-5892bis/: this is what the IESG is going on. There is no mention of updates anywhere there. Thanks for sharing your view. Earlier discussion suggested that the decision of document status would be punted to the IESG, but it seems they will only make an aggregate decision about the entire document. /Simon If the document does not update RFC 5892 (or some other document), I support publishing this document because it will not affect my implementation of RFC 5892. It is always nice to hear support from actual implementers. :-) --Paul Hoffman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and APIs
Dave CROCKER d...@dcrocker.net writes: The Other Dave C's highlighting the possibility of an abstract API is also worth considering. Yes. Today I would prefer to define abstract APIs in the IETF and let implementers or other organizations map them to their language or environment of choice. The IETF is not the best place to go for implementation wisdom these days, unfortunately. Specifying APIs could make more API designers come to the IETF, which would be good, but I fear the IETF will just produce poor APIs until a sufficient mass of clueful people have joined. I don't want to see another GSS-API. A compromise could be to specify one abstract APIs on the standards track and allow multiple rendition of the abstract APIs in various programming languges. Then if someone dislikes a particular concrete API enough, they could propose a better approach. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Clarification for Copyright to referred material in IETF draft
Julian Reschke julian.resc...@gmx.de writes: On 14.12.2010 10:57, Dearlove, Christopher (UK) wrote: I would not consider that a link to Wikipedia is ever appropriate in an IETF draft. If it were, then an exact date and time would need to be included in the reference, but I'd be unhappy even with that. (This is not for copyright reasons.) ... Out of curiosity, and because there may be drafts in the pipeline having links like that...: for which reasons? (I see why we wouldn't want to cite anything *normatively* there, so you don't need to explain that part...) There is a bunch of RFCs with references to Wikipedia: j...@latte:~/rfc$ rgrep wikipedia rfc*.txt rfc4824.txt:en.wikipedia.org/wiki/Semaphore#Modern_semaphore. rfc4984.txt:Wikipedia http://en.wikipedia.org/wiki/Moore's_law, rfc5290.txt: http://en.wikipedia.org/wiki/Net_neutrality;. rfc5345.txt: [1] http://en.wikipedia.org/wiki/Pcap rfc5456.txt: but [wikipedia] lists thirteen other publicly available rfc5456.txt: [wikipedia] Wikipedia, Inter-Asterisk eXchange, rfc5456.txt:http://en.wikipedia.org/wiki/IAX. rfc5638.txt: http://en.wikipedia.org/wiki/Rich_Internet_Applications. rfc5687.txt: en.wikipedia.org/wiki/Cisco_Discovery_Protocol. rfc5975.txt: http://en.wikipedia.org/wiki/Endianness. j...@latte:~/rfc$ All are informational RFCs, except for RFC 5975 which is Experimental but the reference is informational only. I don't see a problem with this. If there are better references, that is great and they should be preferred, but Wikipedia has useful information and stable URLs, which makes it on par or better than other external references. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Clarification for Copyright to referred material in IETF draft
Dearlove, Christopher (UK) chris.dearl...@baesystems.com writes: Without a date and time, a link to Wikipedia is to something that anyone could change, at any time, to anything. (Unless locked, but that's unlikely to be the case here.) A link to any external site is to something that _someone_ could change, at any time, to anything. I don't see how replacing 'someone' with 'anyone' makes a significant difference here, rather to the contrary since it means you or anyone inclined can improve it to restore its usefulness. External references always comes with the price of creating obsolete or incorrect links. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Keys In DNS (kidns)
I believe the KIDNS charter is generally good and I support forming this WG to work on this topic, however I have one important concern: Specify mechanisms and techniques that allow Internet applications to establish cryptographically secured communications by using information distributed through the DNS and authenticated using DNSSEC to obtain public keys which are associated with a service located at a domain name. I fear this wording will lead to a standards that _requires_ people to adopt the sloppy security practice to use the same credential for two (or more) unrelated services. By only locating services by domain name, the separation between ports (e.g., 443 or 587) and transport protocols (UDP vs TCP) are lost. I object to that limitation. I believe it is important that any solution in this space supports different certificates for different ports/protocols on the same host. My experience with how protocols are deployed is that it is common for both web (HTTPS) and e-mail (SMTP with STARTTLS) to be hosted on the same domain name but with different certificates. For example, the host lists.debian.org is reachable with HTTPS (with a matching certificate) and also through SMTP with STARTTLS (also with a matching certificate). The services are using different certificates! There are other examples, lists.ubuntu.com and even mail.ietf.org, even if not all appear to support SMTP+STARTTLS. Thus, I'd like to see the charter clarify that services are located at a distinct port/protocol/domain-name rather than only at a domain-name. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Keys In DNS (kidns)
Jeffrey A. Williams jwkck...@ix.netcom.com writes: I object to that limitation. I believe it is important that any solution in this space supports different certificates for different ports/protocols on the same host. Whynot have both. One being a shared cert as acceptable and the option of one for each? My experience with how protocols are deployed is that it is common for both web (HTTPS) and e-mail (SMTP with STARTTLS) to be hosted on the same domain name but with different certificates. For example, the host lists.debian.org is reachable with HTTPS (with a matching certificate) and also through SMTP with STARTTLS (also with a matching certificate). The services are using different certificates! i see nothing wrong with this and conversly nothing wrong with both using a shared cert for each. Good point -- let me clarify that I believe it should be up to each administrator to decide whether to use one certificate for multiple services or use one certificate per service. A standard in this area should not rule out one alternative. Both alternatives are too common for that. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
comments on draft-turner-md4-to-historic-03
Thanks for this document. Re RFC 2289 it says: o The initial One-Time Password systems, based on [RFC2289], have ostensibly been replaced by HMAC based mechanism, as specified in HOTP: An HMAC-Based One-Time Password Algorithm [RFC4226]. [RFC4226] suggests following recommendations in [RFC4086] for random input, and in [RFC4086] weakness of MD4 are discussed. This sounds as if we should deprecate RFC 2289, and recommend RFC 4226 instead. However RFC 4226 is not on the standards track. Should it be advanced to the standard track? HOTP doesn't have exactly the same properties as S/KEY, but for practical purposes the are close enough. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Attendance by continent
Michael Richardson m...@sandelman.ca writes: Michael == Michael StJohns mstjo...@comcast.net writes: Michael Fred said this much more eloquently than I could. Michael On the IETF78 attendees list there's been a lot of Michael discussion about where to meet - with the primary Michael consideration seeming to be pretty and small. I may be Michael in the minority, but I'd really rather the IETF go places Michael where the ability to get work done is the primary Michael consideration. Yeah, I'm all for meeting in Europe once a year, but does it have to be in the peak of Summer? Seriously. As long as I'm in a hotel conference centre all day, I might as well be north of the Artic Circle in November. +1. Peak of summer happens to be peak of vacation time for many europeans, and making room for an IETF conference during vacation periods can be difficult even if it is in the same continent. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Attendance by continent
Fred Baker f...@cisco.com writes: On Aug 8, 2010, at 11:48 PM, Simon Josefsson wrote: +1. Peak of summer happens to be peak of vacation time for many europeans, and making room for an IETF conference during vacation periods can be difficult even if it is in the same continent. Peak of summer is when Americans with children are on vacation too. What is your intention here - to skip the summer meeting? My point is that Europe doesn't have to be over-represented as the summer continent. For the last 15 years, 7 out of 11 of the July meetings has been in Europe. I can only find three non-July EU meetings in the last 15 years, and two of them were held in early August. This timing has made it difficult for me to attend the meetings. j...@mocca:~$ elinks -dump http://www.ietf.org/meeting/past.html|grep July|head -11 July 25-30, 2010; Maastricht, July 26-31, 2009; Stockholm, July 27-August 1, 2008; Dublin, July 22-27, 2007; Chicago, IL, USA; July 9-14, 2006; Montreal, Quebec, July 31-August 5, 2005; Paris, July 13-18, 2003; Vienna, Austria; July 14-19, 2002; Yokohama, Japan; July 31-August 4, 2000; Pittsburgh, July 11-16, 1999; Oslo, Norway; July 17-21, 1995; Stockholm, j...@mocca:~$ /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-kitten-gssapi-naming-exts (GSS-API Naming Extensions) to Proposed Standard
The IESG iesg-secret...@ietf.org writes: The IESG has received a request from the Kitten (GSS-API Next Generation) WG (kitten) to consider the following document: - 'GSS-API Naming Extensions ' draft-ietf-kitten-gssapi-naming-exts-08.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-07-23. 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-kitten-gssapi-naming-exts-08.txt Here are my comments: 1) Section 3 says: An attribute is 'authenticated' iff there is a secure association I suggest expanding iff for clarity. 2) Section 7 defines several new APIs, but I cannot find discussion about who is responsible for de-allocating the output buffers: the caller or the GSS-API implementation. For example, in section 7.1 the 'display_name' parameter is defined as: o display_name STRING First, it should probably be OCTET STRING, not STRING, at least I cannot find any type called only STRING in RFC 2743. Secondly, also compare how RFC 2743 clarifies who is responsible for memory de-allocation like this: o interprocess_token OCTET STRING -- caller must release -- with GSS_Release_buffer() Something similar is needed. 3) The C-binding sections are not complete, they need to describe semantics for the function and its parameters. Compare how RFC 2744 defines each function and discusses each parameter. For the interprocess_token above, there is this text: interprocess_token buffer, opaque, modify token to be transferred to target process. Storage associated with this token must be freed by the application after use with a call to gss_release_buffer(). I expect similar text for each C function and its parameters. 4) The mapping of PKIX subjectAltNames to values is fuzzily described in section 6.2: PKIX certificate subjectAltNames MUST be mapped as *authenticated* GSS-API name attributes. The values SHOULD be the values of the subjectAltName represented as OCTET STRINGs if the type of the subjectAltName supports a unique loss-less representation as string values. Specifically dnsName, ipAddress, uniformResourceLocator and emailAddress MUST be returned using the corresponding string representation of those data types. 6.2.2. Other PKIX Certificate Extensions and Attributes Any X.509 certificate extension not covered above SHOULD be represented as GSS-API name attributes with the OID of the X.509 extension and with OCTET STRING values containing the encoded value of the extension. Is supports a unique loss-less representation intended to _only_ mean dnsName+ipAddress+uniformResourceLocator+emailAddress or are other types also intended to be covered if they, decided by each implementer, can be uniquely and loss-lessly converted? For good interop, I believe the document should clarify for each supported type exactly how translation should work, and not leave this aspect implementation defined. For example, the ipAddress extension holds binary data (of arbitrary length, for IPv4+IPv6), and there are several data formats permitted (127.0.0.1, 127.1, 127::1, etc). It should specify a unique data format. Further, the text above is not clear how the commonly used XMPP subjectAltName extension is translated because that uses an SubjectAltName otherName type. Again, these problems would be solved if the document contains an explicit list of SAN types that are supported and describe exactly how they are converted to string values. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: review of draft-sheffer-emu-eap-eke-06
Dan Harkins dhark...@lounge.org writes: Hi Simon, On Mon, May 3, 2010 3:32 pm, Simon Josefsson wrote: Dan Harkins dhark...@lounge.org writes: Issues with prf and prf+ - In sections 5.1 and 5.2 the password is passed directly into prf+ (which is the same as the one from RFC 2409 and uses HMAC-SHA1 or HMAC-SHA256). This is a key derivation type function and assumes it has been passed a key having properties, like a uniformly random distribution, that a low-entropy password does not have. I recommend deriving a key for Encr() in a 2-step process using and extractor and expander KDF. It might also be good to mention that the first, leftmost, length-of-cipher-key bits are used as the cipher key. I agree with your comments. However would not salting and an iterative design, as provided by PKCS#5 PBKDF2, be more appropriate than extract-and-expand? See section 4 of the extract-and-expand document to see why it is not always appropriate for passwords. I don't believe so. PBKDF2 does 1000 iterations of HMAC-ing to increase the work factor of brute force guessing the password. This is useful when the protocol using the password is not based on a zero knowledge proof. In this case it is, and an active attacker gets only one guess at the password per attack (a passive attacker gets zero guesses) and that would be the case even if the password is used directly as a key to an HMAC-based KDF. Section 4 of the extract-and-expand document says, In the case of password-based KDFs, a main goal is to slow down dictionary attacks using two ingredients: a salt value and the intentional slowing of the key derivation computation. HKDF naturally accommodates the use of salt; however, a slowing down mechanism is not part of this specification. But in the case of EAP-EKE a dictionary attack is foiled outright by the protocol. There is no need to use a KDF to slow one down. Right. I agree. Issues with elliptic curves cryptography This raises a question. What is the patent status of the technologies used by this document? I recall concerns with some non-HMAC-based password based authentication protocols. I believe it has been submitted: https://datatracker.ietf.org/ipr/1071/ Thanks for the pointer. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: review of draft-sheffer-emu-eap-eke-06
Dan Harkins dhark...@lounge.org writes: Issues with prf and prf+ - In sections 5.1 and 5.2 the password is passed directly into prf+ (which is the same as the one from RFC 2409 and uses HMAC-SHA1 or HMAC-SHA256). This is a key derivation type function and assumes it has been passed a key having properties, like a uniformly random distribution, that a low-entropy password does not have. I recommend deriving a key for Encr() in a 2-step process using and extractor and expander KDF. It might also be good to mention that the first, leftmost, length-of-cipher-key bits are used as the cipher key. I agree with your comments. However would not salting and an iterative design, as provided by PKCS#5 PBKDF2, be more appropriate than extract-and-expand? See section 4 of the extract-and-expand document to see why it is not always appropriate for passwords. - Section 5.1 says If the password is non-ASCII, it SHOULD be normalized by the sender before the EAP-EKE message is constructed. The normalization method is SASLprep, [RFC4013]. Note that the password is not null-terminated. I don't think this will work. The SHOULD should be a MUST and the mention of SASLprep should use normative language-- i.e. it MUST be SASLprep. Is there a mandatory-to-implement format? Is support for ASCII a MUST? Also, there's no mention of unassigned code points? What happens if one of these is hit during normalization? I don't believe the text as written will assure interoperability and it will also be a DISCUSS target, said using the voice of experience :-) I agree strongly with this comment as well. Issues with elliptic curves cryptography This raises a question. What is the patent status of the technologies used by this document? I recall concerns with some non-HMAC-based password based authentication protocols. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [KEYPROV] Second Last Call: draft-ietf-keyprov-symmetrickeyformat (Symmetric Key Package Content Type) to Proposed Standard
The IESG iesg-secret...@ietf.org writes: The IESG has received a request from the Provisioning of Symmetric Keys WG (keyprov) to consider the following document: - 'Symmetric Key Package Content Type ' draft-ietf-keyprov-symmetrickeyformat-08.txt as a Proposed Standard ... The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-keyprov-symmetrickeyformat-08.txt This document appears to have a normative reference to a patent: 7.1. Normative References [FIPS197]National Institute of Standards. FIPS Pub 197: Advanced Encryption Standard (AES), 26 November 2001. [LUHN] Luhn, H., Luhn algorithm, US Patent 2950048, August 1960, http://patft.uspto.gov/netacgi/nph- Parser?patentnumber=2950048. I cannot find a patent disclosure about this on file with the IETF: https://datatracker.ietf.org/ipr/search/?option=document_searchdocument_search=draft-ietf-keyprov-symmetrickeyformat I believe the authors should file a patent disclosure about this in order to comply with the spirit of RFC 3979 section 6.1.3. Was the patent concern discussed by the WG before the last call? I don't recall any discussion about this, but I may have missed it. What is the licensing for this patent? Use of the LUHN algorithm does not appear essential for this document, thus I would prefer that some other non patent encumbered algorithm were used. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [KEYPROV] Second Last Call: draft-ietf-keyprov-symmetrickeyformat (Symmetric Key Package Content Type) to Proposed Standard
Sam Hartman hartmans-i...@mit.edu writes: Simon == Simon Josefsson si...@josefsson.org writes: Simon This document appears to have a normative reference to a Simon patent: Simon[LUHN] Luhn, H., Luhn algorithm, US Patent 2950048, Simon August 1960, http://patft.uspto.gov/netacgi/nph- Simon Parser?patentnumber=2950048. Simon I cannot find a patent disclosure about this on file with the Simon IETF: Simon https://datatracker.ietf.org/ipr/search/?option=document_searchdocument_search=draft-ietf-keyprov-symmetrickeyformat Simon I believe the authors should file a patent disclosure about Simon this in order to comply with the spirit of RFC 3979 section Simon 6.1.3. Simon, I'm not sure what the letter of that BCP says, but I think the spirit of the requirements is that we should have disclosures regarding any IPR that may pose concerns for implementation. As far as I can tell, this is an August 1960 patent. It's old enough that no license is required. I do not see any concerns this poses. Am I missing something. I did not notice the date. More worrisome, I cannot read the reference. The link goes to a page which says 'Full text is not available for this patent. Click on Images button above to view full patent' and when I click on Images I get nothing because the page appears to require some non-standard plugin that I don't have installed. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Post-Last-Call document-RFC Changes
Bob Braden bra...@isi.edu writes: If I may comment from my position as ex-RSE, the RFC Editor's policy for at least the past 10 years has been to fuss at authors who ask for substantive changes in AUTH48, but then to follow the dictum: better to get it right than get it early. In other words, the RFC Editor did push back but generally did not refuse suhstantive changes in AUTH48. This doesn't appear to be what is happening today -- I haven't heard any fuss from the RFC Editor for the GS2 changes. /Simon Bob Braden John Klensin wrote, in part: The one change that, IMO, might be worth making in this regard would be to explicitly empower the RFC Editor to push back, if necessary by going back to the community, if, in their judgment, substantive changes that deviate from the approved document are requested at AUTH48. My own view is that they have always had the ability to do that although I don't believe it has been exercised since the AUTH48 procedures were created. I have no opinion as to whether there are cases in which it should have been. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
Paul Hoffman paul.hoff...@vpnc.org writes: Hi again. It appears that people have a hard time with the additional random extension because it has limited applicability but I cannot fully state what that is. The purpose here is to help fix problems that shouldn't happen, and to be harmless when the bad situation doesn't happen. This has led some people to think that an implementer will therefore feel free to code more carelessly. I have a higher respect for TLS implementers, but maybe I shouldn't. I am not sure that I can convince people of what seems like an obvious fact: the PRNG on a system might fail in a way that the TLS implementation cannot detect. If it could detect the failure, of course it should shut down, screaming. But lots of PNRG failures seem undetectable to the implementation but possibly detectable to an attacker. Remedying that was the motivation for these drafts. If that problem is not of interest, or is considered to induce developers to do a worse job, I can see why people would not want these drafts to move forwards. I still believe that this extension itself is harmless in all cases, and helpful in limited ones; I have not seen anyone directly prove otherwise. Having said that, I'm of course willing to go along with IETF consensus if people think that the mere standardization of this extension will somehow weaken existing implementations. I disagree with your description of people's objections. My impression is that people actually have been arguing precisely that the draft does not solve the problem you describe. My main concern with the document is that the problem you describe isn't sufficiently well explained in the document itself for implementers and application protocol designers to understand when use of the extension is warranted. If the PRNG is broken, your draft does not solve the many other places in TLS that requires a working PRNG to provide a secure protocol: key generation, CBC IV, random record padding, etc. If you have 5 weak links in a chain, making one of them stronger is not terribly relevant. I sympathize with the goals of the draft, and I believe it would help in theoretical proofs about entropy flows in secure protocols. I don't believe implementing and enabling the draft would have any overall positive effect on security on the Internet when all things are considered, therefor I'm having a problem with it going on the standards track. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
Paul Hoffman paul.hoff...@vpnc.org writes: At 12:51 AM +0200 4/22/10, Simon Josefsson wrote: In which environments is the extension useful? The only motivation in the document that I can find is this: In some application environments, it is desirable to have the client and/or the server be able to input more random material in the master key calculation than is allowed by the fixed-length Random value. I believe more justification than that is required for Proposed Standard. In particular, what I'd like to see is references to some application environments where the extension is desirable, and the rationale why it is desirable in that environment. Without a rationale for when the extension is useful, it is impossible for implementers to know when use of this extension is warranted or not. The environment I described in the earlier thread is TLS with Diffie-Hellman. I thought that saying that was sufficient, but I guess it wasn't. People shouldn't have to read the mailing list to understand the applicability, so please describe some environments in the document. In Diffie-Hellman key establishment with static keys, even if the PRNG of one side is bad, the resulting pre-master secret is still sound. Neither side knows whether or not the PRNG of the other side is bad, so each side wants to supply sufficient randomness for the master secret even if the other side's PRNG is bad. If a side with a bad PRNG adds its own input, it doesn't hurt the randomness of the result, but a side with a good PRNG can bring up the amount of randomness. Are you saying that the 28 bytes of randomness provided in the client and server hello is not sufficient? I did not want to list this as the justification because there may be other reasons to use the extension, and I don't want readers to think that this is the only one. For example, future types of TLS key establishment might have similar properties as static-static Diffie-Hellman. Does that help? This information certainly helps, but it belongs in the document. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Pointing to IANA registries
Julian Reschke julian.resc...@gmx.de writes: On 22.04.2010 07:59, Yoav Nir wrote: When RFC-5746 was recently published, the URL from an extremely useful informative reference apparently got stripped by the RFC Editor: draft -03: [Ray09]Ray, M., Authentication Gap in TLS Renegotiation, November 2009,http://extendedsubset.com/?p=8. [SSLv3]Freier, A., Karlton, P., and P. Kocher, The SSL Protocol Version 3.0, November 1996,http://www.mozilla.org/ projects/security/pki/nss/ssl/draft302.txt. RFC-5746: [Ray09]Ray, M., Authentication Gap in TLS Renegotiation, November 2009,http://extendedsubset.com/?p=8. [SSLv3]Freier, A., Karlton, P., and P. Kocher, The SSL Protocol Version 3.0, Work in Progress, November 1996. Nice, so they took out the link to a draft that has been there forever, but left a link to somebody's blog (even if that someone is the document author) Well, this was approved by the authors during AUTH48, no? It is easy to fail to catch a change like that, even if you are an author. The RFC Editor modified SASL GS2 (still in RFC Editor's queue) in a similar way: they replaced a reference to an old I-D with the final RFC, but the reference to that particular old I-D was intentional. How about a IETF48 review period? The to-be-published RFC is published again as a new I-D and the entire community can do final review of the changes introduced during the RFC editing process. Right now, the I-D approved by the community and the IESG can be considerably different from what is published as an RFC. There is a risk that errors are introduced. For example, compare SCRAM and GS2 changes: http://tools.ietf.org/rfcdiff?url2=http://www.rfc-editor.org/authors/rfc5802.txturl1=draft-ietf-sasl-scram-11 http://tools.ietf.org/rfcdiff?url2=http://www.rfc-editor.org/authors/rfc5801.txturl1=draft-ietf-sasl-gs2-20 There is a bunch of quite technical changes in there that we really want to get right, and the review of these modifications have been limited. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
Paul Hoffman paul.hoff...@vpnc.org writes: At 12:05 AM +0200 4/22/10, Martin Rex wrote: The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Additional Random Extension to TLS ' draft-hoffman-tls-additional-random-ext-01.txt as a Proposed Standard I'm somewhat confused to see a Last Call for this proposal. We had a discussion on this document on the TLS WG mailing list and determined that this proposal is completely unable to achieve the stated goal. This extension is completely bogus. You came to that conclusion; many other folks disagreed. You stated that you thought it was not useful in some environments, namely with RSA authentication where the client has a broken PRNG. If that is the only environment you care about, then this extension is not useful. TLS is used in many other environments, of course. In which environments is the extension useful? The only motivation in the document that I can find is this: In some application environments, it is desirable to have the client and/or the server be able to input more random material in the master key calculation than is allowed by the fixed-length Random value. I believe more justification than that is required for Proposed Standard. In particular, what I'd like to see is references to some application environments where the extension is desirable, and the rationale why it is desirable in that environment. Without a rationale for when the extension is useful, it is impossible for implementers to know when use of this extension is warranted or not. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: T-shirts?
Mark Atwood m...@pobox.com writes: On Mon, Mar 29, 2010 at 11:19 PM, Lars Eggert lars.egg...@nokia.com wrote: On 2010-3-27, at 13:41, Ray Pelletier wrote: We have been working with an online vendor to allow t-shirts and other paraphernalia (coffee mugs, ball caps, etc) to be purchased. The rock concert design has been a particular challenge. why is this harder than uploading the various artwork to cafepress.com? Their quality is not that great, and they want too big of a cut. Is the alternative -- i.e., no t-shirt and no revenue for IETF -- better? /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Patent disclosure in draft-shin-augmented-pake-00.txt
Hi. This document [1] contains the following section: 6. Intellectual Property The National Institute of Advanced Industrial Science and Technology (AIST) has submitted a patent application about the AugPAKE protocol, described in this document. For details of the patent application and its status, please contact the authors of this document. That by itself does not fulfill the IETF procedures regarding patent disclosure. Please read section 6.1 of RFC 3979: http://tools.ietf.org/html/rfc3979#section-6.1 Searching for a patent disclosure on this document suggests that none has been filed (yet): https://datatracker.ietf.org/ipr/search/?option=document_searchdocument_search=draft-shin-augmented-pake Therefor you need to file the proper patent disclosure for your submission to comply with the IETF rules. To make your technology benefit Internet applications everywhere, please consider licensing your patent in a liberal way. One example what I believe is a friendly patent license would be this one: https://datatracker.ietf.org/ipr/941/ Writing a patent license in friendly way is complicated, if you are interested I can work with you and the Free Software Foundation or the Software Freedom Law Center to help you write a good license. Thanks, /Simon [1] http://www.ietf.org/internet-drafts/draft-shin-augmented-pake-00.txt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-sasl-gs2-18
Spencer Dawkins spen...@wonderhamster.org writes: Summary: This document is almost ready for publication as a Proposed Standard. I did have one minor question about 13.3 (in my LATE review), but it should not be difficult to resolve, if an AD agrees with my question. Hi Spencer. Thank you for your careful review. I'm now applying your comments to the document. I did tag a fair number of nits, but these aren't part of the Gen-ART review, and are simply included as a convenience for anyone else who edits the document. This is appreciated! 1. Introduction The GS1 bridge failed to gain wide deployment for any GSS-API mechanism other than The Kerberos V5 GSS-API mechanism [RFC1964] Spencer (nit): s/The Kerberos/The Kerberos/ Fixed. [RFC4121], and has a number of problems that lead us to desire a new Spencer (nit): s/lead/led/ Fixed. bridge. Specifically: a) GS1 was not round-trip optimized, b) GS1 did not support channel binding [RFC5056]. These problems and the opportunity to create the next SASL password-based mechanism, SCRAM Spencer (nit): please expand SCRAM on first use. Fixed. [I-D.ietf-sasl-scram], as a GSS-API mechanism used by SASL applications via GS2, provide the motivation for GS2. In particular, the current consensus of the SASL community appears to be that SASL security layers (i.e., confidentiality and integrity protection of application data after authentication) are too complex and, since SASL applications tend to have an option to run over a Transport Layer Security (TLS) [RFC5246] channel, redundant and best replaced with channel binding. Spencer (nit): it's a LONG way from too complex to redundant in this sentence ;-) suggest moving redundant before the subclause, just for readability. Fixed. 3.3. Examples The last step translate each decimal value using table 3 in Base32 Spencer (nit): s/translate/translates/? Fixed. [RFC4648]. Thus the SASL mechanism name for the SPKM-1 GSSAPI mechanism is GS2-DT4PIK22T6A. 8. GSS-API Parameters The mutual_req_flag MUST be set. If channel binding is used then the client MUST check that the corresponding ret_flag is set when the context is fully establish, else authentication MUST fail. Spencer (nit): s/establish/established/ This paragraph was rewritten completely due to other changes, so this doesn't apply any more. Use or non-use of deleg_req_flag and anon_req_flag is an implementation-specific detail. SASL and GS2 implementors are encouraged to provide programming interfaces by which clients may choose to delegate credentials and by which servers may receive them. SASL and GS2 implementors are encouraged to provide programming interfaces which provide a good mapping of GSS-API naming options. 11. GSS_Inquire_mech_for_SASLname call To allow SASL clients to more efficiently identify which GSS-API mechanism a particular SASL mechanism name refers to we specify a new GSS-API utility function for this purpose. Spencer (nit): whew! hard to parse. Suggest We specify a new GSS-API utility function to allow SASL clients to more efficiently identify the GSS-API mechanism that a particular SASL mechanism name refers to, or something like that? I agreed, and used your text after a s/clients/implementations/ -- it is not SASL clients that may want to use the new GSS-API interface, but the actual SASL GS2 implementations. SASL clients (e.g., applications) will (hopefully) never need to worry about the GSS-API interface. 13.3. Additional Recommendations If the application requires security layers then it MUST prefer the SASL GSSAPI mechanism over GS2-KRB5 or GS2-KRB5-PLUS. Spencer (minor): If prefer the mechanism is the right way to describe this, I apologize, but I don't know what the MUST means in practice - if this needs to be at MUST strength, I'd expect text like MUST use X and MUST NOT use Y or Z, or MUST use X unless the server doesn't support X. Good point. After reading the discussion between Nico and Alexey, I changed the paragraph into: If the application requires SASL security layers then it MUST use the SASL GSSAPI mechanism [RFC4752] instead of GS2-KRB5 or GS2-KRB5- PLUS. I believe this captures the intent more clearly. 14. GSS-API Mechanisms that negotiate other mechanisms A GSS-API mechanism that negotiate other mechanisms interact badly Spencer (nit): s/negotiate/negotiates/, and probably s/interact/will interact/ ? Fixed. with the SASL mechanism negotiation. There are two problems. The first is an interoperability problem and the second is a security concern. The problems are described and resolved below. 14.1. The interoperability problem If a client implement GSS-API mechanism X, potentially negotiated through a GSS-API mechanism Y, and the server also implement GSS-API Spencer (nit): s/implement/implements/ Fixed. mechanism X
Re: Gen-ART review of draft-ietf-sasl-gs2-18
Nicolas Williams nicolas.willi...@sun.com writes: In particular, the current consensus of the SASL community appears to be that SASL security layers (i.e., confidentiality and integrity protection of application data after authentication) are too complex and, since SASL applications tend to have an option to run over a Transport Layer Security (TLS) [RFC5246] channel, redundant and best replaced with channel binding. Spencer (nit): it's a LONG way from too complex to redundant in this sentence ;-) suggest moving redundant before the subclause, just for readability. Good point. The and best replaced with channel binding can be a separate sentence too (Use of SASL security layers is best replaced with channel binding to a TLS channel.). I've made this change too. 16. Security Considerations GS2 does not directly use any cryptographic algorithms, therefore it is automatically algorithm agile, or, as agile as the GSS-API mechanisms that are available for use in SASL applications via GS2. The exception is the use of SHA-1 for deriving SASL mechanism names, but no cryptographic properties are required. The required property Spencer (nit): I would suggest SHA-1 is used to derive SASL mechanism names, but no cryptographic properties are required - the current text says we don't use crypto, except when we do :-) :) How about: GS2 does not directly use any cryptographic algorithms for security features, therefore it is automatically algorithm agile, ... GS2 does use SHA-1 for deriving SASL mechanism names from GSS-API mechanism OIDs, but this use of SHA-1 is not security-relevant. Thanks! I used the slightly more verbose: SHA-1 is used to derive SASL mechanism names, but no traditional cryptographic properties are required -- the required property is that the truncated output for distinct inputs are different for practical input values. GS2 does not use any other cryptographic algorithm. Therefor GS2 is algorithm agile, or, as agile as the GSS-API mechanisms that are available for use in SASL applications via GS2. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-sasl-gs2-18
Alexey Melnikov alexey.melni...@isode.com writes: The I-D says: The original GSS-API-SASL mechanism bridge was specified by [RFC], now [RFC4752]; we shall sometimes refer to the original bridge as GS1 in this document. I don't see anything wrong with that. Very well. I forgot about that. There's good reason, even, to want to use GS1 to refer to RFC4572: RFC/4572's use of GSSAPI to refer to the Kerberos V5 GSS-API mechanism is wrong and confusing. Avoiding confusion is a good thing. Personally I dislike unnecessary indirection, as it allows for extra confusion as well. There is only 1 mechanism in GS1 family (ignoring GSS-SPNEGO), it is called GSSAPI. So I think the original text is actually better, if we add a reference and change prefer to use: If the application requires SASL security layers then it MUST use the SASL GSSAPI mechanism [RFC4572] instead of GS2-KRB5 or GS2-KRB5-PLUS. Opinions? I used this text too. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
Brian E Carpenter brian.e.carpen...@gmail.com writes: On 2009-12-01 23:57, Simon Josefsson wrote: Scott Brim scott.b...@gmail.com writes: Simon Josefsson allegedly wrote on 11/30/2009 10:11 AM: There is no requirement in the IETF process for organizations to disclose patents as far as I can see. The current approach of only having people participate, and disclose patents, in the IETF is easy to work around by having two persons in an organization doing different things: one works on specifying and standardizing technology, and the other is working on patenting the technology. Simon, from rfc3979: l. Reasonably and personally known: means something an individual knows personally or, because of the job the individual holds, would reasonably be expected to know. This wording is used to indicate that an organization cannot purposely keep an individual in the dark about patents or patent applications just to avoid the disclosure requirement. But this requirement should not be interpreted as requiring the IETF Contributor or participant (or his or her represented organization, if any) to perform a patent search to find applicable IPR. I don't see how this modifies anything? The legal obligation is on the IETF participant, not on the organization. The organization is not bound by this text. IANAL. But if the participant is acting as an agent of the employer, it seems to me that the employer is bound. In any case, you'd have to be a brave or reckless employee not to assume that to be the case. You'd also have to be a very obtuse employer to fund your employees to participate if you didn't like the IETF's rules. Now you are moving the responsibility on to the organizations. I can't see how that modify my assertion that the IETF does not have any legal means to pressure organization to file patent disclosures. Either the IETF has a legal ability to apply pressure on organizations, or it does not. I don't see why that is a controversial statement. Nothing in the IETF history suggests it even wants to have a legal link to organizations who sends participants to the IETF. The text in RFC 3979 and other documents suggests strongly that this approach is intentional. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
Scott Brim scott.b...@gmail.com writes: Simon Josefsson allegedly wrote on 11/30/2009 10:11 AM: There is no requirement in the IETF process for organizations to disclose patents as far as I can see. The current approach of only having people participate, and disclose patents, in the IETF is easy to work around by having two persons in an organization doing different things: one works on specifying and standardizing technology, and the other is working on patenting the technology. Simon, from rfc3979: l. Reasonably and personally known: means something an individual knows personally or, because of the job the individual holds, would reasonably be expected to know. This wording is used to indicate that an organization cannot purposely keep an individual in the dark about patents or patent applications just to avoid the disclosure requirement. But this requirement should not be interpreted as requiring the IETF Contributor or participant (or his or her represented organization, if any) to perform a patent search to find applicable IPR. I don't see how this modifies anything? The legal obligation is on the IETF participant, not on the organization. The organization is not bound by this text. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
Brian E Carpenter brian.e.carpen...@gmail.com writes: On 2009-11-24 06:44, Steven M. Bellovin wrote: On Mon, 23 Nov 2009 08:16:49 -0500 Scott Brim scott.b...@gmail.com wrote: Simon Josefsson allegedly wrote on 11/23/2009 5:03 AM: John-Luc said he is bound by confidentiality obligations from his company, and I think the same applies to most employees of larger organizations. There is nothing explicit in BCP 79 to protect against this apparent conflict of interest, or is there? Since disclosure is required for anyone submitting documents or participating in IETF discussions, a person who does not disclose IPR for this reason, or any other reason, must not contribute to or participate in IETF activities with respect to technologies that he or she reasonably and personally knows to be Covered by IPR which he or she will not disclose. Precisely. The conflict Simon mentions was of course known to most of the WG; that's one reason we have that clause. IMHO, BCP79 creates no particular problem for corporate lawyers who are instructed by their corporate management to ensure that the company behaves as a good citizen in its standards activities. This is strongly in the company's interests, anyway, since failure to disclose when required by a standards process threatens the validity of the patent. There is no requirement in the IETF process for organizations to disclose patents as far as I can see. The current approach of only having people participate, and disclose patents, in the IETF is easy to work around by having two persons in an organization doing different things: one works on specifying and standardizing technology, and the other is working on patenting the technology. It really is not the IETF's problem. It is a problem for a company that chooses not to behave as a good citizen. The situation remains that the IETF does not have any mechanism to apply pressure on organizations to disclose patent information. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
Arnt Gulbrandsen a...@gulbrandsen.priv.no writes: Simon Josefsson writes: There is no requirement in the IETF process for organizations to disclose patents as far as I can see. The current approach of only having people participate, and disclose patents, in the IETF is easy to work around by having two persons in an organization doing different things: one works on specifying and standardizing technology, and the other is working on patenting the technology. How can you practically avoid the first person knowing about it? Make sure (through confidentiality agreements) that the second one do not talk with the first? Putting them in different continents helps. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
Russ Housley hous...@vigilsec.com writes: John-Luc: I am sending this note to help you understand the IETF IPR policies; they are fully described in BCP 79 (http://www.ietf.org/rfc/bcp/bcp79.txt). I hope this note clarifies the responsibilities of RIM employees (and anyone else) who participate in IETF. IETF participants engage as individuals, not as representatives of their employers (See Section B.1 of RFC 4677; http://www.ietf.org/rfc/rfc4677.txt). The obligation to follow the IPR policies in BCP 79 is an individual one, not a corporate one. Section 6.1of BCP 79 is quite clear; IETF Participants are required to disclose IPR which they reasonably and personally know applies to a Contribution. The BCP specifically excludes cases in which a participant is unaware of IPR held by their employer. John-Luc said he is bound by confidentiality obligations from his company, and I think the same applies to most employees of larger organizations. There is nothing explicit in BCP 79 to protect against this apparent conflict of interest, or is there? /Simon Please do not hesitate to contact me if you need further clarification. Russ Housley IETF Chair At 06:46 PM 11/19/2009, John-Luc Bakker wrote: Dear all, With regard to the recent discussion regarding RIM's recent IPR disclosures, I understand the community's concerns regarding the timeliness of the disclosure. As employees of companies we are bound by confidentiality obligations and, in addition, cannot always control our company's internal processes. The community's concerns have been brought to the attention of my employer and they are in the process of evaluating the concerns. My company has asked for your patience while they take the time to evaluate the concerns and determine if there is an appropriate course of action in this matter to alleviate the concerns of the community. Your understanding is appreciated. Kind regards, John-Luc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
Dave Cridland d...@cridland.net writes: On Mon Nov 23 10:03:25 2009, Simon Josefsson wrote: John-Luc said he is bound by confidentiality obligations from his company, and I think the same applies to most employees of larger organizations. There is nothing explicit in BCP 79 to protect against this apparent conflict of interest, or is there? Being horribly naïve, I'd have thought that it was obvious that if you cannot satisfy both your obligations as an employee, and your obligations as an IETF participant, then one or other rôle has to be dropped - ie, either you quit your job, or cease to participate within the IETF. I simply don't see what other solution there is, or could be, and I don't see what on earth BCP 79 could usefully say. The document could say just that, if that is indeed the general opinion. It may be useful for employees to be able to point at such text when discussing the IETF rules internally with their organization. I'm not sure if that text would have helped in this instance because it is not clear whether the RIM employees were unaware of the obligations in the IETF rules, or if they decided (or were ordered) to pursue anyway. Referring to confidentiality obligations suggests the latter to me, though, because otherwise you could simply have said you weren't aware of the rules instead. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sasl-gs2 (Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family) to Proposed Standard
Alexey Melnikov alexey.melni...@isode.com writes: The IESG wrote: The IESG has received a request from the Simple Authentication and Security Layer WG (sasl) to consider the following document: - 'Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family ' draft-ietf-sasl-gs2-17.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 2009-11-18. 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. I would like to suggest a clarification to the IANA registration for GS2-* family of SASL mechanisms: In Section 15, 3rd paragraph: OLD: The IANA is advised that SASL mechanism names starting with GS2- are reserved for SASL mechanisms which conform to this document. The IANA is directed to place a statement to that effect in the sasl- mechanisms registry. NEW: The IANA is advised that SASL mechanism names starting with GS2- are reserved for SASL mechanisms which conform to this document. The IANA is directed to place a statement to that effect in the sasl- mechanisms registry. With the exception of GS2-KRB5 and GS2-KRB5-PLUS (registered later in this section), all other mechanism names in this family are constructed as defined in section 3.1. Opinions? This forces future GSS-API mechanisms that provide a SASL mechanism name to use a SASL name outside of the GS2-* prefix. Was that your intention? I thought it would be nice to allow a future GSS-API mechanism, called say FOOBAR, to be able to register the SASL mechanism name GS2-FOOBAR. But having them register FOOBAR instead is of course fine too. I'm fine with adding the text if this situation was what you intended. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART Telechat Review of draft-ietf-sasl-scram-10
Ben Campbell b...@estacado.net writes: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-sasl-scram-10 Reviewer: Ben Campbell Review Date: 19 Oct 2009 IESG Telechat date: 22 Oct 2009 Summary: This draft is ready for publication as a draft standard. Did you mean proposed standard? Major issues: None Minor issues: None Nits/editorial comments: None. That is the shortest gen-art review I have seen. Good work, SCRAM authors! :-) /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-gennai-smime-cnipa-pec (Certified Electronic Mail) to Proposed Standard
The IESG iesg-secret...@ietf.org writes: - 'Certified Electronic Mail ' draft-gennai-smime-cnipa-pec-05.txt as a Proposed Standard This documents appears to utilize several e-mail header fields: X-Ricevuta X-Riferimento-Message-ID X-VerificaSicurezza X-Trasporto Is that a good idea? The header field names are translated in Appendix A (X-Notification, X-Reference-Message-ID, etc) but it is not clear if they are required to be equivalent or not. Also the minimum requirements are: o support for ISO-8859-1 (Latin-1) character set; Isn't UTF-8 be a better choice, if we want this to be an Internet standard? According to the abstract, the document is a report describing the system as it is at the moment of writing. I wonder generally if maybe Informational or Experimental wouldn't be better categories for the document? /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [CHANNEL-BINDING] Last Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard
I support the goal of this document, i.e. to publish the text in the IANA repository as an RFC. There are differences between the text in the current IANA repository and the document. These differences are not spelled out in the document for the 'tls-server-end-point' channel binding. The document says: Note that the only material changes from the original registration should be: the owner (now the IESG), the contacts, the published specfication, and a note indicating that the published specification should be consulted for applicability advice. That is not correct, compare the content registered with IANA The hash of the TLS server's end entity certificate as it appears, octet for octet, in the server's Certificate message (note that the Certificate message contains a certificate_list, the first element of which is the server's end entity certificate.) The hash function to be selected is as follows: if the certificate's signature hash algorithm is either MD5 or SHA-1, then use SHA-256, otherwise use the certificate's signature hash algorithm. The reason for using a hash of the certificate is that some implementations need to track the channel binding of a TLS session in kernel-mode memory, which is often at a premium. with what the document says: The hash of the TLS server's certificate [RFC5280] as it appears, octet for octet, in the server's Certificate message (note that the Certificate message contains a certificate_list, the first element of which is the server's certificate). The hash function is to be selected as follows: o if the certificate's signatureAlgorithm uses a single hash function, and that hash function is either MD5 [RFC1321] or SHA-1 [RFC3174] then use SHA-256 [FIPS-180-2]; o if the certificate's signatureAlgorithm uses a single hash function and that hash function neither MD5 nor SHA-1, then use the hash function associated with the certificate's signatureAlgorithm; o if the certificate's signatureAlgorithm uses no hash functions or multiple hash functions, then this channel binding type's channel bindings are undefined at this time (updates to is channel binding type may occur to address this issue if it ever arises). The reason for using a hash of the certificate is that some implementations need to track the channel binding of a TLS session in kernel-mode memory, which is often at a premium. I suggest that the first paragraph quoted above from section 4 is modified like this: OLD: Note that the only material changes from the original registration should be: the owner (now the IESG), the contacts, the published specfication, and a note indicating that the published specification should be consulted for applicability advice. NEW: Note that the only material changes from the original registration should be: the owner (now the IESG), the contacts, the published specfication, and a clarification to the description related to certificate's that do not use hash functions or use multiple hash functions. We also added a note indicating that this specification contains applicability advice, and we moved security considerations notes to the security considerations section of this document. The last sentence is copied from section 3 for consistency. Also missing is in section 3 and section 5 is a note that references were added to the text. I suggest: OLD: ...security considerations section of this document. All other fields of the registration are copied here for the convenience of readers. NEW: ...security considerations section of this document. References were added to the description. All other fields of the registration are copied here for the convenience of readers. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-idnabis-bidi (Right-to-left scripts for IDNA) to Draft Standard
I object to publishing these IDNA documents as a Draft Standard. I don't view IDNA2008 as a revision of the earlier IDNA2003 protocol. The design goals have changed since the first IDNA version. Finally, there have been little implementation experience with the new protocol. I would support publication as Proposed Standard. /Simon The IESG iesg-secret...@ietf.org writes: The IESG has received a request from the Internationalized Domain Names in Applications, Revised WG (idnabis) to consider the following document: - 'Right-to-left scripts for IDNA ' draft-ietf-idnabis-bidi-06.txt as a Draft 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 2009-10-13. 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-idnabis-bidi-06.txt Implementation Report can be accessed at http://www.ietf.org/iesg/implementation.html IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17284rfc_flag=0 The IESG iesg-secret...@ietf.org writes: The IESG has received a request from the Internationalized Domain Names in Applications, Revised WG (idnabis) to consider the following document: - 'Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework ' draft-ietf-idnabis-defs-11.txt as a Draft 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 2009-10-13. 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-idnabis-defs-11.txt Implementation Report can be accessed at http://www.ietf.org/iesg/implementation.html IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17772rfc_flag=0 The IESG iesg-secret...@ietf.org writes: The IESG has received a request from the Internationalized Domain Names in Applications, Revised WG (idnabis) to consider the following document: - 'Internationalized Domain Names in Applications (IDNA): Protocol ' draft-ietf-idnabis-protocol-16.txt as a Draft 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 2009-10-13. 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-idnabis-protocol-16.txt Implementation Report can be accessed at http://www.ietf.org/iesg/implementation.html IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17268rfc_flag=0 The IESG iesg-secret...@ietf.org writes: The IESG has received a request from the Internationalized Domain Names in Applications, Revised WG (idnabis) to consider the following document: - 'The Unicode code points and IDNA ' draft-ietf-idnabis-tables-07.txt as a Draft 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 2009-10-13. 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-idnabis-tables-07.txt Implementation Report can be accessed at http://www.ietf.org/iesg/implementation.html IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17234rfc_flag=0 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-idnabis-bidi (Right-to-left scripts for IDNA) to Draft Standard
Lisa Dusseault lisa.dussea...@gmail.com writes: On Thu, Oct 1, 2009 at 3:42 AM, Simon Josefsson si...@josefsson.org wrote: I object to publishing these IDNA documents as a Draft Standard. Â I don't view IDNA2008 as a revision of the earlier IDNA2003 protocol. Â The design goals have changed since the first IDNA version. Â Finally, there have been little implementation experience with the new protocol. I would support publication as Proposed Standard. You are absolutely correct and this is a pilot error on my part. I didn't notice the documents were automatically listed as going for Draft Standard in the tracking tools when I issued the Last Call. SM pointed out that the Last Call announcement mentioned implementation reports but I didn't realize what caused that error. I will look into fixing this and reissuing the Last Call announcements. Thanks -- I didn't read the discussion on the mailing list about the mistake until now, and I assumed the intention really was to go for Draft Standard. I am happy that it was just a mistake and I am sorry if my comment felt confrontational. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer
Joseph Salowey (jsalowey) jsalo...@cisco.com writes: It seems that this is really up to the application. Both server names are authenticated under the same session. It seems an application server may require them to be the same or allow them to be different. I would agree if the draft wouldn't prevent clients from requesting a different server name at the application layer: negotiated in the application protocol. If the server_name is established in the TLS session handshake, the client SHOULD NOT attempt to request a different server name at the application layer. At least that is how I read it. /Simon -Original Message- From: tls-boun...@ietf.org [mailto:tls-boun...@ietf.org] On Behalf Of Michael D'Errico Sent: Tuesday, September 29, 2009 4:48 PM To: martin@sap.com Cc: si...@josefsson.org; ietf@ietf.org; t...@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer I do not see why you consider this a vulnerability in the _server_! Because a malicious client could theoretically establish a secure connection using one server domain and then ask for pages from a different domain. If the server does not check for this, it could potentially leak sensitive information. You're barking up the wrong tree. If the client did not use TLS, the server wouldn't even know that. You must be talking about a particular server implementation that has this shortcomings. There is nothing inherent in TLS that prevents a server from knowing when it is used. Your library and/ or use of that library is the problem. It is inappropriate to assume that virtual hosting provides seperation of content and draw a conclusion that, when accesses via HTTPS, will provide a secure seperation of content instead. I'm not assuming anything; I have written a TLS library and an HTTP server that provides the separation of content that you deny is possible. If the lack of such a server-side check is a problem for your server, then your server problably has a severe design flaw in its session management. I never said my server suffered from this problem And I'm curious: why do you call matching the commonName weak? Because in the vast majority of situatins it is the last step in a long row of flawed assumptions. OK, so you are complaining about the entirety of e-commerce on the web. Do you have any proposed solutions to these problems? Mike Security is only as strong as its weakest link. The authentication process based on a DNSName involves a number of very weak authentications. DNS domain names are not very genuine, and it is very non-obvious which domain names are used by the business or peer someone is looking for and which are used by others (different businesses with the same name, cybersquatters or attackers). Most HTTPS-URLs opened by Web Browsers are served through plaintext HTTP pages. Then most Browser PKIs come with a hundred or more trusted CAs preconfigured, and browsers trust them equally. Whether or how secure the authentication is that the CA performs before issuing a certificate is another flawed assumption that weakens the rfc-2818 server endpoint authentication. A final flaw that is still present in most browsers is the lack of memory. Not memorizing the certificate that a server presented on the last contact perpetuates the weakness of the original authentication. Personally, I think that deriving a server endpoint identifier from a network address is the most flawed assumption of all. That is like asserting that if someone opens on a random door on which you knock, and shows you an ID card with the correct street address -- then he must be a GOOD guy. -Martin ___ TLS mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sasl-scram
Nicolas Williams nicolas.willi...@sun.com writes: On Fri, Sep 25, 2009 at 02:00:58PM +0200, Simon Josefsson wrote: I'm hesitant to bring this up because it has so many other concerns, but if you are looking for alternatives, another one is to flag the normalization algorithm used in the protocol. E.g., add a flag 'c=saslprep' or 'c=net-utf-8' or 'c=utf-8'. This makes it possible to apply a better heuristic on the server side. Or treat normalization like the hash algorithm, since it is also an continuously evolving and apparently never-perfected technology, and make the mechanism name SCRAM-SHA-1-SASLPREP or SCRAM-SHA-1-NET-UTF-8. (You can figure out the problems with this approach as good as I can, so I won't go into them..) It doesn't really help because it'd have to be the server telling the client what the user's password's form is -- not the other way around. Chances are the password's been hashed already; recovering from use of a different NF (or just-utf-8) is not going to be feasible. The server can store the password hashed in a couple of different forms, and use the flag to determine which to use. I realize that is possible anyway (just iterate through all locally stored hashes), although without some text in the document I don't think many servers will implement that. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Regarding Internet Connectivity for the proposed IETF Meeting in China
David Morris d...@xpasc.com writes: That aside though, I've not seen a description of the part of the contract provisions and/or venue plans which deal with the 'great firewall' potential impact on the many ways IETF participants expect to use the Internet during meetings. Both from a perspective of attendees as well as those of us unlikely to be present but desiring traditional audio, video, chat, etc. real time access. Given the number of people browsing the web or reading e-mail during meetings, I wonder whether cutting off Internet access beyond internal network services for jabber, presentation materials, etc during IETF meetings wouldn't actually _increase_ productivity. It could make people pay attention to the technical discussions. Some people could even spend the time writing specifications. Or _implement_ the specifications and test them against others, although that might be too far-fetched. /Simon - only half :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sasl-scram
pasi.ero...@nokia.com writes: Simon Josefsson wrote: I'd be happy to help work on a document that analyzed the consequences of replacing SASLprep with just-use-RFC5198 in SASL. But I don't think SCRAM should wait for something like it to materialize. I agree that such work would take time, and we don't want to delay SCRAM. But as the discussion so far has shown, normalization is a very tricky topic, and we can't really expect implementors to understand why just use UTF-8 is problematic. Perhaps we should add a note to the SCRAM draft; something like Informative Note: Implementors are encouraged to create test cases that use both username passwords with non-ASCII characters. In particular, it's useful to test characters whose normalization form C and normalization form KC are different. Some examples of such characters include Vulgar Fraction One Half (U+00BD) and Acute Accent (U+00B4). +1. Do you think this would increase the likelihood of interoperability with non-ASCII passwords? For implementers that decides to use SASLprep but just happens to get things wrong, yes. For those, I think test vectors would be even more useful. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sasl-scram
pasi.ero...@nokia.com writes:
John C Klensin wrote:
Looking http://en.wikipedia.org/wiki/Keyboard_layout, it seems
the Finnish/Swedish layout is not special in any way, and many
other European keyboards would also have some small number of
characters where NFC!=NFKC.
That is important data. It seems to me that it implies:
* if entropy in passwords and/or properly reflecting
keyboards is more important than password
interoperability (whatever that means), then we should
be moving away from NFKC and, hence, from the current
version of SASLprep.
I don't know about the East Asian width variants, but for the ones in the
Finnish/Swedish layout, there is basically no entropy loss. For some
of the characters, there's only one way to enter the NFKC form (so no
entropy is lost); and the number of characters affected is small, and
they're rarely used anyway (so the effect on entropy is extremely small).
Latin-1 0xAA ('ª') and 0xBD ('½') are easy to type on Finnish/Swedish
keyboards (AltGr-A and Shift-§) and the NFC and NFKC forms differs.
There might be other reasons, but the complaint about SASLprep I've
heard most often (implementation complexity -- unless the platform
already has a normalize() call always available, many programmers will
just use UTF-8) applies equally to NFC, too. So I'm not sure if
moving to NFC would really solve anything here...
Agreed.
But just use UTF-8 probably won't lead to good interoperability
when the passwords are hashed (as opposed to sent and compared, like
usernames).
I'm hesitant to bring this up because it has so many other concerns, but
if you are looking for alternatives, another one is to flag the
normalization algorithm used in the protocol. E.g., add a flag
'c=saslprep' or 'c=net-utf-8' or 'c=utf-8'. This makes it possible to
apply a better heuristic on the server side. Or treat normalization
like the hash algorithm, since it is also an continuously evolving and
apparently never-perfected technology, and make the mechanism name
SCRAM-SHA-1-SASLPREP or SCRAM-SHA-1-NET-UTF-8. (You can figure out the
problems with this approach as good as I can, so I won't go into them..)
/Simon
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard
I am aware that the IETF-wide last call has ended, but Daniel Black provided a suggestion (posted on the gnutls-devel list) for the Security Considerations that I agree with and believe can be important. Quoting him, slightly reworded: also maybe 11.1. could say, in response to the last paragraph of section 3, + Server applications SHOULD validate server_name against any application layer equivalent field. The last paragraph of section 3 reads: If an application negotiates a server name using an application protocol and then upgrades to TLS, and if a server_name extension is sent, then the extension SHOULD contain the same name that was negotiated in the application protocol. If the server_name is established in the TLS session handshake, the client SHOULD NOT attempt to request a different server name at the application layer. It appears security relevant for the server to actual verify that the client do not use another server name at the application layer to circumvent authorization decisions. I cannot find any MUST/SHOULD requirement in the document for servers to test this right now. One attack could works like this: 1) Client establish an client-authenticated HTTPS session with a TLS SNI for blog.example.org and sends a HTTP GET with a Host: header for internal-website.example.org. 2) The server TLS code authenticate and authorize the client (using the certificate) for use with the blog.example.org domain. The server HTTP code serves the internal-website.example.org web page to the client. This system would be insecure but still compliant with RFC 4366bis as far as I can tell, which seems suboptimal. Adding a requirement for servers to check for this attack would solve the problem. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sasl-scram
I have noticed an additional problem related to additional data in SCRAM. RFC 4422 section 5 item 2b says: b) An indication of whether the server is expected to provide additional data when indicating a successful outcome. If so, if the server sends the additional data as a challenge, the specification MUST indicate that the response to this challenge is an empty response. As far as I can tell, SCRAM does not specify that the response to a server-final sent as a challenge MUST be an empty client response. This violates the requirements in RFC 4422 for new mechanisms. Review section 3 of RFC 4422 before reading on. SCRAM negotiations in general will look like: C: Request authentication exchange S: Empty Challenge C: SCRAM client-first S: SCRAM server-first C: SCRAM client-final S: SCRAM server-final C: Empty Response S: Outcome of authentication exchange (Four round-trips, ouch!) If the application protocol supports additional data together with outcome of authentication exchange, the negotiation will look like: C: Request authentication exchange S: Empty Challenge C: SCRAM client-first S: SCRAM server-first C: SCRAM client-final S: Outcome of authentication exchange with SCRAM server-final If the application protocol supports optional initial responses, the negotiation will look like: C: Request authentication exchange with SCRAM client-first S: SCRAM server-first C: SCRAM client-final S: SCRAM server-final C: Empty Response S: Outcome of authentication exchange If the application protocol supports both additional data together with outcome of authentication exchange AND optional initial response, the negotiation will look like: C: Request authentication exchange with SCRAM client-first S: SCRAM server-first C: SCRAM client-final S: Outcome of authentication exchange with SCRAM server-final I believe section 5 needs to be rewritten to take all these variants into account. Right now the wordings all assume the last situation. OLD: First, the client sends the client-first-message containing: NEW: If the application protocol does not support optional initial responses, the client will request authentication and the first server challenge MUST be empty. The first non-empty client response is the client-first-message containing: OLD: The server verifies the nonce and the proof, verifies that the authorization identity (if supplied by the client in the first message) is authorized to act as the authentication identity, and, finally, it responds with a server-final-message, concluding the authentication exchange. NEW: The server verifies the nonce and the proof and that the authorization identity (if supplied by the client in the first message) is authorized to act as the authentication identity. If the application protocol supports sending outcome of the authentication exchange, it sends the outcome together with the server-final-message, concluding the exchange. Otherwise, the server sends the server-final-message as a request. OLD: The client then authenticates the server by computing the ServerSignature and comparing it to the value sent by the server. If the two are different, the client MUST consider the authentication exchange to be unsuccessful and it might have to drop the connection. NEW: The client then authenticates the server by computing the ServerSignature and comparing it to the value sent by the server. If the two are different, the client MUST consider the authentication exchange to be unsuccessful and it might have to drop the connection. If the application protocol does not support sending additional data together with the outcome of authentication, the client MUST respond to the server request with a empty response. Note that this problem have consequences for my implementation: the earlier SCRAM traces I posted are incorrect since they do not have a final empty client response. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sasl-scram
John C Klensin john-i...@jck.com writes:
Vulgar Fraction One Half (U+00BD)
Acute Accent (U+00B4)
Diaeresis (U+00A8)
That is important data. It seems to me that it implies:
* if entropy in passwords and/or properly reflecting
keyboards is more important than password
interoperability (whatever that means), then we should
be moving away from NFKC and, hence, from the current
version of SASLprep.
I believe NFKC is sub-optimal for password processing. It reduces
entropy for many non-ambigious characters. For example NFKC('ª') = 'a'
which seems like a clear example of an unwanted conversion.
* if entropy in passwords is less important than
interoperability with any Latin-based (or
Latin-character-containing) keyboard one happens to
encounter, then NFKC should be mandatory. However, one
needs to think about how far to carry that argument
because, if it is taken very far, there is a strong case
for restricting passwords to the basic, undecorated,
Latin letters that appear on all such keyboards.
I don't believe there is a good case for this. Improving entropy in
passwords is important. There shouldn't be any _technical_ reason in
authentication protocols why users cannot use 'ª' in a password to
provide more entropy to the system than using 'a'.
There are many environments where non-ascii characters are a bad idea
from technical or social reasons, but those environments should not
restrict less limited environments. It is fine for a system to validate
passwords against [A-Za-z0-9] if that is required, and that system will
be able to use SCRAM too.
And, of course, it would be possible to decide that we are stuck
with the decisions made in SASLprep. If so, it pretty strongly
suggests to me that we had better get a lot more careful and
conservative about whatever coding decisions we make in the
future.
For SCRAM I believe we are stuck with SASLprep because there are no
drafts to provide a replacement that are close to being mature.
/Simon
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sasl-scram
John C Klensin john-i...@jck.com writes: For SCRAM I believe we are stuck with SASLprep because there are no drafts to provide a replacement that are close to being mature. Here we disagree _very_ slightly. Following part of the theme of draft-iab-idn-encoding, I have become convinced that having many Unicode profiles is a significant cost and involves significant disadvantages. I agree. Replacements for Stringprep profiles, or updates to Stringprep itself, should be, IMO, required to justify the costs and complexity they represent relative to just use NFC or the nearly-equivalent just use RFC 5198. In this case, if maturity of alternate specifications were the issue, one could base SCRAM on NFC alone (which is _very_ mature) if one wanted to start moving away from per-protocol profiles. I really don't know if that is the right choice at this stage, but it certainly is a feasible one. I don't think using NFC is feasible at this point. Noone (or?) have evaluated whether NFC alone is a good chose for preparing passwords. So in that way, NFC is not at all mature. RFC 4422 suggests use of SASLprep. SASLprep is mature in that it exists and have been evaluated for appropriateness. Just because SASLprep is not perfect doesn't mean something else, NFC included, will not be worse. Personally (speaking as one of few SASLprep implementers) I believe using NFC alone would be better from many perspectives than SASLprep for passwords. But I can't point to any substantial document to support that belief, and there are obvious disadvantages with the NFC-approach (less stability because of versioning differences) that would need to be addressed. Given that SCRAM is in last call now, I'm not sure it is feasible to develop a document that analyze NFC from this perspective that we can have good confidence in and gain wide support for. I'd be happy to help work on a document that analyzed the consequences of replacing SASLprep with just-use-RFC5198 in SASL. But I don't think SCRAM should wait for something like it to materialize. Finally a general observation. I believe username and passwords are different beasts when it comes to string preparation. What makes sense for usernames does not always make sense for passwords, and vice versa. Usernames are typically transported in the clear, and thus it makes little sense to enforce strong normalization like NFKC on it. What may be useful is to enforce weaker rules, like NFC, when comparing two username strings for equivalence. Passwords should not be transported in the clear, and are often input to hash functions, and thus it is motivated to require normalization. I'm not convinced NFC is sufficient here. I think conflating username string preparation with password string preparation is one problematic part of SASLprep. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sasl-scram
I support publication of draft-ietf-sasl-scram. I have implemented SCRAM in a beta version of GNU SASL [1], see [2], so I have good confidence that the document is in sufficiently good technical condition. I have not yet managed to do interop testing with anyone else though. Please contact me if you are implementing it and we haven't already spoken about testing. I have two remaining comments on the document: 1) This is an editorial issue. The hashed password that needs to be stored with clients are either both ClientKey and ServerKey OR only the SaltedPassword. The SaltedPassword can be used to compute ClientKey/ServerKey, so it may be preferable in some situations where you only want to store one hash for the user. OLD: client implementation MAY cache SaltedPassword/ClientKey for NEW: client implementation MAY cache ClientKey/ServerKey (or just SaltedPassword) for Also, clients may not need to have access to passwords if they have access to the cached information. OLD: To begin with, the SCRAM client is in possession of a username and password. NEW: To begin with, the SCRAM client is in possession of a username and password (or a ClientKey/ServerKey or SaltedPassword). 2) This is a technical issue. SCRAM does not say anything about the encoding used for the password (e.g., Latin-1, UTF-8) or whether SASLprep should be applied to the string or not. I believe this violates this requirement in RFC 4422: In order to avoid interoperability problems due to differing normalizations, when a mechanism calls for character data (other than the authorization identity string) to be used as input to a cryptographic and/or comparison function, the specification MUST detail precisely how and where (client or server) the character data is to be prepared, including all normalizations, for input into the function to ensure proper operation. For simple user names and/or passwords in authentication credentials, SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation algorithm), SHOULD be specified as the preparation algorithm. For highest interoperability the document could do MUST use UTF-8 and MUST use SASLprep. I understand that some people will not implement SASLprep, and I agree with them that there are valid reasons for not implementing SASLprep (such as it being based on obsolete Unicode versions), so I would be equally happy with MUST use UTF-8 and SHOULD use SASLprep. I don't think the requirement on SASLprep can be relaxed further without breaking the requirements in RFC 4422. Personally, in the long term I would prefer to deprecate SASLprep in favor of Net-UTF-8 (i.e., RFC 5198) for use in SASL applications. I believe SHOULD use SASLprep in SCRAM is a reasonable trade-off considering these factors. For what its worth, my GNU SASL implementation supports SASLprep via GNU Libidn [3] which implements SASLprep. Libidn is free software, so anyone is able to use it if they desire SASLprep support. Thanks, Simon [1] http://www.gnu.org/software/gsasl/ [2] http://lists.gnu.org/archive/html/help-gsasl/2009-09/msg3.html [3] http://www.gnu.org/software/libidn/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sasl-scram
John C Klensin john-i...@jck.com writes: For highest interoperability the document could do MUST use UTF-8 and MUST use SASLprep. I understand that some people will not implement SASLprep, and I agree with them that there are valid reasons for not implementing SASLprep (such as it being based on obsolete Unicode versions), so I would be equally happy with MUST use UTF-8 and SHOULD use SASLprep. I don't think the requirement on SASLprep can be relaxed further without breaking the requirements in RFC 4422. Personally, in the long term I would prefer to deprecate SASLprep in favor of Net-UTF-8 (i.e., RFC 5198) for use in SASL applications. I believe SHOULD use SASLprep in SCRAM is a reasonable trade-off considering these factors. For whatever it is worth, I agree with this analysis. I'm not sure that RFC 5198 is an adequate substitute for SASLprep, but it is far better than unrestricted UTF-8 (which, IMO, we should no longer be recommending in any protocol that requires comparison of strings). Yes, agreed. Because of the unrestricted UTF-8 problem, and without taking a position on deprecating SASLprep, my inclination would be to strengthen Simon's proposed requirement a bit to MUST use UTF-8 and SHOULD use SASLprep or at least Net-UTF-8 or its equivalent. I share Kurt's concern that this opens up for several classes of implementations that may not interoperate well. Alternately, I believe that any string that would successfully come out of SASLprep would conform to Net-UTF-8, i.e., that the set of valid SASLprep strings is a proper subset of the set of valid Net-UTF-8 strings. If that were true -- and someone with significant Unicode normalization and SASLprep knowledge/experience would need to verify it-- then MUST use Net-UTF-8 [RFC 5198] and SHOULD use SASLprep would be an even better formulation (perhaps with a note about that subset relationship). Something along those lines may work, but I think there are serious risks to get the details wrong with a quick fix like that here. If someone has time to study your question that would be useful input nonetheless. Pending something more baked than SASLprep and Net-UTF-8-in-SASL, I continue to believe that MUST UTF-8 and SHOULD SASLprep is a reasonable compromise. Finally, I strongly believe that deferring publication of SCRAM significantly to address this issue in a more thorough way does more harm than good. The state-of-the-art SASL mechanism today either transfer passwords to servers without hashing them first, or they use MD5 for the hash, and neither is acceptable. If we don't publish SCRAM, the SASL framework will be unusable for new protocols. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
Henk Uijterwaal h...@ripe.net writes: Simon Josefsson wrote: Marshall Eubanks t...@americafree.tv writes: Comments sought for: Standard Procedure for Modifying the TLP Is this a solution looking for a problem? RFC 5377 is an example of where the IETF asks the Trust do something. What is wrong with using the same approach in the future? The approach would be that someone writes an I-D, there is IETF-wide last call on it, and it is either approved or not. If it is approved, the Trust needs to act. Correct and this document specifies how the trust will react: it takes the guidance (for example, RFC 5377), modifies the text, gets legal advice and proposes an implementation to the community. The community reviews the changes and checks that what is implemented, is what is requested. I wish that is how it would work. The most recent change of the TLP was not following that process -- instead the Trust proposed the change and implemented it after some delay -- and, for example, it resulted in a change to how BSD licensed portions extracted from IETF documents that is not consistent with common practice. 2. Whoever brings up the problem, writes a problem statement. a. In case 1a: this can be an individual submission ID or a ID from a WG chartered to discuss these items. b. In case 1b: A note from the trust to the community. c. In case 1c: A note from whoever brings up the issue. For 2c, whom is the note to? To only the trust or to the community? If the former, will be trust communicate the request to the community? 2c are cases where the Trust manages something for another stream, so in first order, I'd say that the note is for the trust and that other stream. I don't see a problem sending it else where though. 2c does not seem restricted for non-IETF streams from the writing above. I think it is important that the IETF is notified for issues relating to the IETF stream. 4. Trust (with legal counsel) reviews the issue and comes up with a response: a. No, we don't think changing this is a good idea, because ... b. Yes, we suggest to modify the text as follows ... (perhaps with some background material why this is the answer). I'm strongly concerned that this puts the decision making of what is and what is not a problem into the Trust's hands. No, there is always step 5: review of the new text or decision not to change the text. If a suggestion isn't considered a good idea by the Trust, the reasons for not changing it can be discussed in this step. Step 4 puts a veto for changes into the Trust's hands. Members on the Trust can be removed by the IETF, but I don't believe that is a good way to make the Trust to do something the IETF requests. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
Olaf Kolkman o...@nlnetlabs.nl writes: On Sep 8, 2009, at 2:06 PM, Simon Josefsson wrote: I'm strongly concerned that this puts the decision making of what is and what is not a problem into the Trust's hands. No, there is always step 5: review of the new text or decision not to change the text. If a suggestion isn't considered a good idea by the Trust, the reasons for not changing it can be discussed in this step. Step 4 puts a veto for changes into the Trust's hands. Members on the Trust can be removed by the IETF, but I don't believe that is a good way to make the Trust to do something the IETF requests. As a Trustee I've signed a statement that reads: 3. The undersigned hereby agrees to serve as a Trustee to the Trust and to fulfill the duties of a Trustee in accordance with the terms of the Trust Agreement and all other requirements of law applicable to service as a trustee of a Virginia trust and to comply with all requirements of the Trust Agreement applicable to his/her service as a Trustee If a proposal from the IETF is in conflict with the terms of the Trust Agreement or the law then a Trustee has the obligation to veto it (a fairly academic possibility, I believe). I don't see how that is related to step 4 above. There is plenty of mechanisms left for the Trust to veto changes to become effective -- for example, you can just refuse to approve the change -- however my point is about having the trust be able to cancel the process to modify the TLP even before it has been subject to community discussion. That approach appears contrary to the concept that the Trust carries out the wishes of the IETF and not the other way around. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] Proposed Policy for Modifications to Trust Legal Provisions (TLP)
Henk Uijterwaal h...@ripe.net writes: Simon Josefsson wrote: If a proposal from the IETF is in conflict with the terms of the Trust Agreement or the law then a Trustee has the obligation to veto it (a fairly academic possibility, I believe). I don't see how that is related to step 4 above. There is plenty of mechanisms left for the Trust to veto changes to become effective -- for example, you can just refuse to approve the change -- however my point is about having the trust be able to cancel the process to modify the TLP even before it has been subject to community discussion. That approach appears contrary to the concept that the Trust carries out the wishes of the IETF and not the other way around. I don't see how this is possible: If the community believes that a change should be made, the Trust has to (at least) review it and explain why it believes that this is not a good idea. This brings us to phase 5, community discussion, where one can discuss the arguments for not making the change. Exactly. What step 4 does is to allow the trust to cancel the community review by declaring that it doesn't agree. At this point several things can happen. One possibility is that the community really wants the change but the Trust doesn't. In that case, there is an possibility for appeal. Step 6 allows the trust to evaluate the community request and veto the request if needed. What I'm objecting to is to allow the trust to veto the TLP changes as early as step 4, before there has been community review of the proposal. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Trust response to the appeal by John C Klensin (July 18, 2009
Thomas Narten nar...@us.ibm.com writes: Without taking positions on the specifics of the appeal or the response, I have to say that my take on the response is that it doesn't properly address the appeal and is inadequate. I would have expected the specific issues raised in the appeal to be responded to in a direct manner, with a clear response as to whether the point is agreed to (or not) and what (if any) remedy is forthcoming. Instead, the response smacks of trying not to respond directly to the appeal, but say here is what we have been doing, let's please just move on. IMO, that just doesn't cut it. IMO, an appeal needs to be responded to with directness and with clarity. You saved me the time to compose a lengthier response, and instead I can just +1 yours. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard
I am aware that the last call period has ended, but maybe this comment will aid IESG processing of the document. After having talked to the SFLC and the FSF about the patent threat on this document, I no longer oppose publication of the tls-extractor document on the standards track. It appears as if the patent threat on the document (as I perceived it) was resolved when Certicom's agent clarified their intentions on the mailing list. Thanks to Pasi for nudging me to escalate the issue, and also thanks to the SFLC for giving me advice on the matter. Generally, it appears sub-optimal that implementers needs to review not only the patent disclosure page but also review mailing list archives to be able to evaluate the patent status on a document. Finally, I note that the time period a document is in IETF Last Call, even if the time window is extended as it was for tls-extractor, is too short to allow matters to be resolved that requires coordination between multiple organizations and feedback from legal people. Thanks, /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
Brian E Carpenter brian.e.carpen...@gmail.com writes: On 2009-08-18 07:57, Simon Josefsson wrote: ... This is another reason why the current approach of getting IETF consensus on an RFC and publishing should be preferred. Compare RFC 5377. It is a well defined process, and unless there is consensus that the approach is broken I believe we should use the normal process. Can we start and agree on a problem statement before finding solutions? It would be serious overkill to do this for trivial legal verbiage changes, which is what we've been discussing for the last 9 months. Trivial verbiage changes can have significant practical consequences. If there is consensus around a trivial change, writing an I-D about it and getting it published as an RFC should not be difficult. If it takes 9 month to get that done, something else is broken. I don't see how specifying an alternative publication and consensus gathering path for the Trust will avoid the same problem. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
Marshall Eubanks t...@americafree.tv writes: Comments sought for: Standard Procedure for Modifying the TLP Is this a solution looking for a problem? RFC 5377 is an example of where the IETF asks the Trust do something. What is wrong with using the same approach in the future? The approach would be that someone writes an I-D, there is IETF-wide last call on it, and it is either approved or not. If it is approved, the Trust needs to act. I would like to understand why you believe this approach is not a more suitable one than what you propose. 2. Whoever brings up the problem, writes a problem statement. a. In case 1a: this can be an individual submission ID or a ID from a WG chartered to discuss these items. b. In case 1b: A note from the trust to the community. c. In case 1c: A note from whoever brings up the issue. For 2c, whom is the note to? To only the trust or to the community? If the former, will be trust communicate the request to the community? 4. Trust (with legal counsel) reviews the issue and comes up with a response: a. No, we don't think changing this is a good idea, because ... b. Yes, we suggest to modify the text as follows ... (perhaps with some background material why this is the answer). I'm strongly concerned that this puts the decision making of what is and what is not a problem into the Trust's hands. I don't believe this was the intention when the Trust was formed. As far as I understood the background for the Trust, it was not to control the IETF, it was to cater for the wishes of the IETF in (mostly) copyright areas. The approach here appears contrary to this role. Announcements: All announcements to go to the ietf-announce list plus the equivalent for the other streams. Discussion will take place on the TLP mailing list. Does this list exists now? Emergencies. An emergency is defined as there is a problem with the TLP that is likely to be abused. In these cases, the trust can publish a modified text for a 2 week review period, then modify the TLP. The Trust must explain the reason for the change. I believe it needs be explicit that the reason has to be explained to the community, not to only a smaller group. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
Marc Blanchet marc.blanc...@viagenie.ca writes: Marshall Eubanks a écrit : On Aug 17, 2009, at 11:25 AM, Marc Blanchet wrote: Marshall Eubanks a écrit : Emergencies. An emergency is defined as there is a problem with the TLP that is likely to be abused. In these cases, the trust can publish a modified text for a 2 week review period, then modify the TLP. The Trust must explain the reason for the change. I have a hard time thinking of an emergency that can be fixed by a timely change in the TLP which would likely require a lot of heavy legal advice and related work and coordination. Changes in policies may have important impacts over time that would probably require enough time to review. To me, the TLP should be a pretty stable document. However, I might think of an emergency for a immediate legal action, but not sure about an emergency change in the TLP. I guess I need to be educated on the use case for the emergency track. My personal feeling is that we won't really know until we have had a few, which hopefully will take a very long time. But, it seems worthwhile to have some sort of in case of emergency, break glass procedure. the other side of the argument is being: the TLP is so central and important that if one wants to change it, it has to go through a somewhat not fast concensus-based process. i.e. this is a stable document and we don't want to change it over night. This is another reason why the current approach of getting IETF consensus on an RFC and publishing should be preferred. Compare RFC 5377. It is a well defined process, and unless there is consensus that the approach is broken I believe we should use the normal process. Can we start and agree on a problem statement before finding solutions? /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Obnoxious license
Joel M. Halpern j...@joelhalpern.com writes: 1) There is no need to put licenses in the RFC at all. In fact, the trust document says clearly that putting license text in RFCs is a bad idea. Really? I'm sure the tools team will be delighted to hear that they no longer needs to spend time on syncing the license text generated by their tools. Alas, I don't think what you are saying is correct. The trust documents appears to me clearly require that license texts are put in RFCs depending on the circumstances. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Obnoxious license
Rick el...@spinics.net writes: In article 6.2.5.6.2.20090813134034.0331e...@elandnews.com, SM s...@resistor.net wrote: I was discussing RFC 5617 with someone and the person mentioned that the copyright in the middle of the document is obnoxious. The copyright statement for the code is 32 lines while the code (ABNF) is only five lines. Can a copyright even be valid for just five lines of code? I'm told that in some jurisdictions even one line of code is sufficient. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF74 T-Shirt Art Donated to IETF Trust
Gregory M. Lebovitz gregory.i...@gmail.com writes: I have been asked about this several times this week, so I'd like to clarify here for all. Juniper has donated the art for the highly popular IETF74 San Francisco T-shirt (brown, IPv6 World Tour, concert concept) to the IETF Trust. This was done because a) many people wanted to buy more of these shirts, b) the IETF expressed an interest in fulfilling those requests. We hope this art can be leveraged to spread the message about IPv6 transition broadly across the Internet community, in a fun and cool way . The ball is now in Ray (and team's) court. Great, thanks! I suggest the Trust considers T-shirt designs as code components so that the BSD license applies to it. :-) /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Retention of blue sheets
Eliot Lear l...@cisco.com writes: Unless the sobpeonas pose a substantial burden to the secretariat, I would prefer that we do not throw away history. These are public meetings, after all. Perhaps there are different definitions of public, but I wouldn't call anything that required registration, payment, and legal obligations (NOTE WELL) to be called a public meeting. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard
David Morris d...@xpasc.com writes: On Thu, 23 Jul 2009, Richard Stallman wrote: Generally speaking, standards are useful, because they enable people to converge what they are doing. But that ceases to be true when the use of the standard is patented. It is better to have no standard than have a standard that invites people into danger. An opinion with which I would differ ... patent encumbered documented behavior is ALWAYS better than no public documentation for commonly used protocols. As a person with frequent exposure to the operational troubleshooting side of networks, lack of accessible documentation is intolerable. I agree, but I don't see anyone making an argument against that. What the question here is about is to classify this (already accessible) documentation as an Internet Standard. That sends a message that the document is what the IETF recommends to use. There is a significant difference. There is no trap when an SDO documents a protocol and publishes that documentation with a caveat that includes documentation of one or more patent claims related to the published protocol. Any fool who implements the protocol without resolving those issues deserves what the get. The trap is the case where the patent or other IP claim isn't revealed. I believe the problem with this patent disclosure is that it isn't clear what is claimed. People are trying to resolve the issue, and this is what the IETF process is about: we need to evaluate things on a document-by-document basis. Fear of patent claims have been successfully used as arguments to publish documents as Informational instead of Proposed Standard before, compare, e.g., RFC 5054 on TLS-SRP. Thanks, Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard
With the caveat that I have recently returned from vacation, and consequently may have missed some clarifications or paged out some context: If the #1154 IPR disclosure is the final word from Certicom on this document, I don't support advancing this document on the standards track. My concern remains that Certicom claims they have IPR that covers the document -- that is what the #1154 disclosure says (section IV). The additional information provided in the PDF is not helping: it grants a license for use together with ECC. It doesn't say anything about the use without ECC. The way I see it, TLS implementers and the broader Internet does not gain something significant by having this document published. Other IETF documents can use the TLS PRF to derive keying material. On the contrary, it seems both TLS implementers and the broader Internet community would be hurt by publishing the document since having patent threats looming over widely used techniques has stability and interoperability impacts. I recall that Certicom was positive about clarifying their intentions so maybe we can continue that discussion and get something more useful than the recent disclosure. Speaking as TLS implementer of the document and document [1] author that reference this document, /Simon [1] http://tools.ietf.org/html/draft-josefsson-krb5starttls-bootstrap-02 The IESG iesg-secret...@ietf.org writes: The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Keying Material Exporters for Transport Layer Security (TLS) ' draft-ietf-tls-extractor-06.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 2009-08-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16821rfc_flag=0 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tls-extractor (Keying Material Exportersfor Transport Layer Security (TLS)) to Proposed Standard
Let's go back to RFC 3979: 6.4. What Must be in a Disclosure? 6.4.1. The disclosure must list the numbers of any issued patents or published patent applications or indicate that the claim is based on unpublished patent applications. The disclosure must also list the specific IETF or RFC Editor Document(s) or activity affected. The draft-ietf-tls-extractor-06 name is mentioned in the disclosure. For what it's worth, the PDF referenced in the disclosure also mentions draft-ietf-tls-extractor-06. Together, I can't read this in any other way that Certicom believes they have some patents covering draft-ietf-tls-extractor-06 and have followed the RFC 3979 rules and informed the IETF about this. If Certicom didn't intend to claim they believe they own patents that they believe covers draft-ietf-tls-extractor-06 they need to supersede the disclosure with one that does not mention that document. The reason for this situation may be the poor terminology used by the IETF IPR web pages. I understand and appreciate that Certicom has tried to clarify the situation, but to me the updated form does not improve the situation. Perhaps Certicom would be able to more easily create a disclosure that matches RFC 3979 rules if the web pages were improved. /Simon Joseph Salowey (jsalowey) jsalo...@cisco.com writes: While I see that draft-ietf-tls-extractor is listed in section IV of #1154 IPR disclosure as related material, I see that it is explicitly not listed in section V part C which lists what is specifically covered by the disclosure. I don't think Certicom is claiming IPR on draft-ietf-tls-extractor because it is not among the list of documents in section V. Joe -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Simon Josefsson Sent: Wednesday, July 22, 2009 12:32 PM To: ietf@ietf.org; t...@ietf.org Subject: Re: Last Call: draft-ietf-tls-extractor (Keying Material Exportersfor Transport Layer Security (TLS)) to Proposed Standard With the caveat that I have recently returned from vacation, and consequently may have missed some clarifications or paged out some context: If the #1154 IPR disclosure is the final word from Certicom on this document, I don't support advancing this document on the standards track. My concern remains that Certicom claims they have IPR that covers the document -- that is what the #1154 disclosure says (section IV). The additional information provided in the PDF is not helping: it grants a license for use together with ECC. It doesn't say anything about the use without ECC. The way I see it, TLS implementers and the broader Internet does not gain something significant by having this document published. Other IETF documents can use the TLS PRF to derive keying material. On the contrary, it seems both TLS implementers and the broader Internet community would be hurt by publishing the document since having patent threats looming over widely used techniques has stability and interoperability impacts. I recall that Certicom was positive about clarifying their intentions so maybe we can continue that discussion and get something more useful than the recent disclosure. Speaking as TLS implementer of the document and document [1] author that reference this document, /Simon [1] http://tools.ietf.org/html/draft-josefsson-krb5starttls-bootstrap-02 The IESG iesg-secret...@ietf.org writes: The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Keying Material Exporters for Transport Layer Security (TLS) ' draft-ietf-tls-extractor-06.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 2009-08-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTa g=16821rfc_flag=0 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)
Tom.Petch sisyp...@dial.pipex.com writes: Original Message - From: Simon Josefsson si...@josefsson.org Sent: Tuesday, June 23, 2009 5:30 PM John C Klensin john-i...@jck.com writes: Assuming that I'm not the only one who sees the recent patterns as problematic I don't think you are alone with that impression. The process you outline (posting preliminary versions in draft-* form) sounds great to me. M ... I think that one thing that the ipr working group got absolutey right was the decision not to try and craft legally suitable wording for intellectual property rights, rather delegating that task. This sounds like a suggestion to restart the ipr wg, perhaps in the hope of getting a different outcome:-) I don't think that is the intention at all. This is about the process used by the IETF Trust. Publishing material early and improving them incrementally is something the IETF has been good at. I would however agree with the suggestion that a complicated (to me as a lay person) document should be accompanied by a non-legally binding lay explanation, eg as to why it is thought suitable to cut the review period from 28 to 14 days, or why a reference to the BSD licence should be thought adequate. The problem with these non-binding documents is that they are often inaccurate and it is difficult to reach closure on what should be in them. It may be better to keep the legally binding document as clear as possible, and to get as many as possible to review and understand them. /Simon Tom Petch I suggested it earlier, and the IETF Trust response was at least not negative to the idea. Hopefully it can be implemented. This would also solve the problem of recording the history of document drafts, and making sure documents are readily available via IETF mirrors even if the main site is down or material is removed from it, which is another concern today. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)
Marshall Eubanks t...@americafree.tv writes: 2.e -- the review period for TLP changes has been changed from 30 to 14 days, which is consistent with the last-call period for other IETF documents John gave several reasons why this isn't good justification, and I agree with them. Reading his thoughts, my opinion is that changing the time frame from 30 to 14 days is a change in the wrong direction considering that these documents are not developed in an open way and that the IETF community may want to ask their lawyers to review the changes before responding. In my experience, getting those answers takes significantly more time than 14 days. 4.e -- this new section clarifies the legend requirements for Code Components that are used in software under the BSD License. In short, the user must include the full BSD License text or a shorter pointer to it (which is set forth in Section 6.d) ... 6.d -- the BSD legend/pointer described in 4.e above The text in 6.d doesn't work. Part of the BSD license (quoted in your document) is this paragraph: Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. If you replace the BSD license with a pointer, you would violate that part of the BSD license. To avoid simple mistakes when changing things related to the BSD license (which now appears to be the norm rather than the exception) I believe it would be a good idea for the IETF Trust to talk with people and organizations who understands open source licensing. I'm sure the Software Freedom Law Center could help here. If the process to develop drafts were open and done on a mailing list, I could have pointed out this earlier. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)
John C Klensin john-i...@jck.com writes: Assuming that I'm not the only one who sees the recent patterns as problematic I don't think you are alone with that impression. The process you outline (posting preliminary versions in draft-* form) sounds great to me. I suggested it earlier, and the IETF Trust response was at least not negative to the idea. Hopefully it can be implemented. This would also solve the problem of recording the history of document drafts, and making sure documents are readily available via IETF mirrors even if the main site is down or material is removed from it, which is another concern today. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)
Yaakov Stein yaako...@rad.com writes: Could you change the wording BSD License to revised BSD License to avoid confusion with the original BSD license that contained the infamous advertising clause ? I support making that change too. (It was pointed out earlier.) /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [Trustees] Proposed Revisions to the IETF Trust LegalProvisions (TLP)
Marshall Eubanks t...@americafree.tv writes: Simon asked that this go to the IETF list. Thanks for moving this back to the IETF list. I believe these discussions should be public. Many considerations appears to have been made that the wider IETF community is unaware of. I would expect information like this to be part of the IETF Trust minutes, but it seems no minutes have been published since September 2008: http://trustee.ietf.org/minutes.html Begin forwarded message: From: Marshall Eubanks t...@americafree.tv Date: June 23, 2009 11:30:50 AM EDT To: Simon Josefsson si...@josefsson.org Cc: Trustees trust...@ietf.org Subject: Re: [Trustees] Proposed Revisions to the IETF Trust LegalProvisions (TLP) On Jun 23, 2009, at 10:18 AM, Simon Josefsson wrote: Contreras, Jorge jorge.contre...@wilmerhale.com writes: 4.e -- this new section clarifies the legend requirements for Code Components that are used in software under the BSD License. In short, the user must include the full BSD License text or a shorter pointer to it (which is set forth in Section 6.d) ... 6.d -- the BSD legend/pointer described in 4.e above The text in 6.d doesn't work. Part of the BSD license (quoted in your document) is this paragraph: Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. If you replace the BSD license with a pointer, you would violate that part of the BSD license. To avoid simple mistakes when changing things related to the BSD license (which now appears to be the norm rather than the exception) I believe it would be a good idea for the IETF Trust to talk with people and organizations who understands open source licensing. I'm sure the Software Freedom Law Center could help here. Simon (removing the large cc list): This language was added after extensive review and consultation with open source experts, including members of the IESG. There are several open source projects (including some run by Yahoo) that use a pointer for the BSD license, rather than the full text. We do not think this is a violation of the BSD language. You may disagree, which is why there is a public comment period for these documents. But please don't assume that these decisions were taken rashly or without serious consideration. Can you name the open source projects that operate like this? I've never heard of a model like this before, and I'm interested to learn about it if it is used successfully. Dear Simon; There was a lot of discussion about this inside the Trust, and I was originally in favor of sticking with the BSD 15 line template and was very dubious about a license by reference approach. However, there was push-back on the length of this (from, e.g. Pasi Eronen), and then Russ found out that for YAHOO the Before continuing the response, should we understand that the rationale for this change is to shorten the license text that has to be included in derived works? Did the Trust do anything to identify whether the wider IETF community feels this is a problem? In other words: on whose behalf is this change made? If that is the rationale, has an alternative to the BSD license been considered? The GNU All Permissive (GAP) license is comparable in size to the excerpt in 6.d. The entire GAP license reads: Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. Another option is to describe the common practice that many open source packages are using: include a short blurb in the file or function that contains the derived work, pointing to a file included in the distribution. YUI JavaScript library and the Django web framework (used in datatracker.ietf.org) don't include the license terms in every file. The code contain this: /* Copyright (c) 2009, Yahoo! Inc. All rights reserved. Code licensed under the BSD License: http://developer.yahoo.net/yui/license.txt It is not hard to find examples of this, both within Yahoo and without. See, e.g., http://developer.yahoo.com/yui/docs/AttributeProvider.js.html This usage is typical and fine. In general, there are two reasons why this usage is fine. Only one condition needs to hold: 1) The publisher of the material is not a redistributor of the code under the BSD license. 2) The copyright holder includes the BSD license in the package. Note that Yahoo includes the entire copy of the BSD license where it has used others code in the YUI package. The new IETF policy text suggests that recipients redistribute code components under the BSD license when they include only the notification text in section 6.d. I.e., not the entire BSD license text. Doing that would violate the letter of the BSD license
Re: Fwd: [Trustees] Proposed Revisions to the IETF Trust LegalProvisions (TLP)
This is another side-discussion that may be useful to do publicly, forwarded with Sam's permission. This discussion brings up another (subtler) point about allowing re-licensing between works licensed under the BSD license directly and works licensed under the newly proposed BSD-license-via-IETF-pointer. If the new Trust text allowed recipients to re-license code back to the original BSD licensed code, and not the BSD-license-via-IETF-pointer license, I would not object to the new text. It would allow me to do what I prefer, and allowing others to do what they prefer. I would continue to feel that the new text is mis-guided and opens for solutions that I believe are sub-optimal, but if others believe they want that option, I would not be against having that option (as long as I can use their BSD-license-via-IETF-pointer derived work under the original BSD license). /Simon Sam Hartman hartmans-i...@mit.edu writes: Simon, I appreciate your concern about the BSD license. However, I'm not entirely sure why it matters. There are apparently some lawyers out there who believe the pointer approach is reasonable. What's the harm in the trust permitting this? If your legal advice suggests that using that option would produce inconsistent results, then you can simply include the full text. I'll admit that I'd be totally happy with the GAP license or (given growing frustrations) the WTFPL as a license for ietf documents or as large a subset of IETF documents as we can get. So, I'm not really bothered by options that some might view as inconsistent, provided that 1) I don't have to use them 2) If someone else uses them and I'm using their code I can go change it to something reasonable. Simon Josefsson si...@josefsson.org writes: Sam Hartman hartmans-i...@mit.edu writes: Simon, I appreciate your concern about the BSD license. However, I'm not entirely sure why it matters. There are apparently some lawyers out there who believe the pointer approach is reasonable. What's the harm in the trust permitting this? I haven't seen any references to lawyers that believe redistributing others BSD works and replacing the BSD license with a pointer is OK -- do you have any links? The BSD license has peculiar wordings here (Redistributions in binary form must reproduce ... this list of conditions ... in the documentation and/or other materials provided with the distribution), so a general opinion about replacing licenses with a pointer would not apply as far as I can tell. If there are lawyers that really do believe the situation wrt BSD is OK, I'm fine with the trust allowing either case. I'm basing my opinion on the assumption that there aren't any. If your legal advice suggests that using that option would produce inconsistent results, then you can simply include the full text. I couldn't if I receive the derived work from someone that didn't include the entire BSD license. I'll admit that I'd be totally happy with the GAP license or (given growing frustrations) the WTFPL as a license for ietf documents or as large a subset of IETF documents as we can get. So, I'm not really bothered by options that some might view as inconsistent, provided that 1) I don't have to use them Me too. 2) If someone else uses them and I'm using their code I can go change it to something reasonable. I'm not sure you could do that in this situation. You received their code under a license that points to some document for the BSD lciense, and that document does not allow you to change the license of that derived work. So you are struck with the IETF pointer license. /Simon Sam Hartman hartmans-i...@mit.edu writes: Simon, thanks for explaining your concern. I agree that if I cannot replace the poinrter with the full text of the BSD license, then the trust language is problematic. I'd suggest that allowing this replacement might be an easy way to make progress. Although I seem to have written to you individually, which is not my intent. If you think it would be beneficial, feel free to forward our conversation to a wider audience. Hmm, perhaps I should have added code begin and code end tags to this IETF contribution:-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Andrew Sullivan a...@shinkuro.com writes: On Fri, Jun 05, 2009 at 08:10:55AM +0900, Masataka Ohta wrote: In general, registries welcome DNSSEC, no matter how secure it is, as long as its complicated operation works as an excuse to increase (or not to reduce) registration charge and registries' revenue. That is a serious charge. I've seen no evidence that DNSSEC represents a revenue opportunity for registries. On the contrary, so far as I've seen, most registries are introducing it without any fee, even though it represents a substantial additional operational cost. The organization operating .SE charges for DNSSEC. According to [1] it costs 250 SEK annually (~22 EUR or ~30 USD) extra per year to protect a domain name with DNSSEC. /Simon [1] http://www.iis.se/docs/se-dnssec_-_broschyr_eng_ny_.pdf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Mans Nilsson mansa...@besserwisser.org writes: Subject: Re: DNSSEC is NOT secure end to end Date: Mon, Jun 08, 2009 at 11:25:36AM +0200 Quoting Simon Josefsson (si...@josefsson.org): The organization operating .SE charges for DNSSEC. According to [1] it costs 250 SEK annually (~22 EUR or ~30 USD) extra per year to protect a domain name with DNSSEC. Not anymore; it is included with the registration since .SE went to a registry-registrar model a year ago. However, the registrar may choose to charge for the work associated with doing DNSSEC. That is good to hear. It would be better if the web pages would reflect the new order. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: jabber URL at the bottom of mailing list traffic?
Keith Moore mo...@network-heretics.com writes: while we're on the subject of better integration between mailing lists and jabber, how about having the trailer at the bottom of every message that is posted to an IETF WG list, include a URL that points to the jabber chat room for that WG? Is more boiler plate texts the answer to everything? I believe Jabber comments are legally IETF contributions, so posting the jabber log to every WG after the IETF week (or more often) seems like a good thing to make jabber statements archived and searchable in a better way. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ANNOUNCEMENT: New FAQ on IETF Copyright Policy available (FYI)
Ed Juskevicius edj@gmail.com writes: FYI, a well-written new FAQ has just been posted to the IETF Trust website. Thank you! This may sound as nit-picking, but is there any particular reason why IETF Trust documents aren't written using the excellent xml2rfc tool? I find the output from xml2rfc is more readable. These documents could also be submitted as proper I-D's, to provide better archival, searching, and cross-referencing of the documents. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
Tim Polk tim.p...@nist.gov writes: 1. Last Call demonstrates that the community does not support progression of this document on the standards track, but sufficient support exists for publication as an Experimental RFC. How can that support be demonstrated? I don't see how we can say anything about support for experimental unless the community is asked to answer that question. That question has been asked in an earlier last call: http://article.gmane.org/gmane.ietf.announce/21152 Presumably, no support for publishing on experimental could be demonstrated at that time. Btw, the patent disclaimer #833 is still not available from the IETF web site. The community can no longer evaluate the complete patent license history around the document. I believe this violates BCP79: Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. By removing earlier disclaimers, I believe the IETF has moved into the territory of making decision about the validity of patent related claims. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
Harald Alvestrand har...@alvestrand.no writes: Simon Josefsson wrote: actually that's intended to be permitted by RFC 5377 section 4.2: 4.2. Rights Granted for Quoting from IETF Contributions There is rough consensus that it is useful to permit quoting without modification of excerpts from IETF Contributions. Such excerpts may be of any length and in any context. Translation of quotations is also to be permitted. All such quotations should be attributed properly to the IETF and the IETF Contribution from which they are taken. You're not permitted to modify the text. You are permitted to use it. Exactly, and disallowing modifications prevents using the text of an RFC as a comment in implementations licensed under free software licenses. For short excerpts, one can use the text anyway and claim fair use, but larger excerpts can be useful to quote in comments or documentation and then there is a problem. I consider the inability to include immutable text in software released under the GPL a bug in the GPL. Nobody forces you to use the GPL, so if you perceive a problem I suggest to use another license for your program. However, the IETF should not prevent implementers from using the GPL, for the same reasons IETF should not prevent Microsoft from using its EULA as the license. BTW, this means that at least one program I have released under the GPL is illegal; it includes the GPL as a part of the source code, and since the GPL text is immutable according to the GPL, it is illegal (by this logic) to include it in source code, since the source has to be free of restrictions upon its modification. I don't see how that makes the program illegal. It just makes it harder for others to redistribute it safely because the licensing information is unclear. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
Steven M. Bellovin s...@cs.columbia.edu writes: On Thu, 12 Feb 2009 21:38:44 +0100 Simon Josefsson si...@josefsson.org wrote: The discussion started by Stephan suggesting that free software authors publish their work as free standards in the IETF. My point was that since the IETF disallow publishing standards under a license that is compatible with free software licensing (e.g., allows modification), it is not possible for free software authors to do this. Thus, to me, this discussion is not related to comments in source code at all. My understanding of IETF policy is that the IETF will publish I-Ds that are in the public domain. Nothing is freer than that. You're perfectly free to put your text in the public domain before submitting it for publication as an RFC. Sure, but I can also put the text under the Microsoft EULA before submitting it for publication as an RFC. The IETF still requires some assurances from me as contributor, and those assurances go beyond both what the public domain and the Microsoft EULA implies. A more interesting question is if you can submit somebody else's public domain work to the IETF. I don't know the answer to that. It seems clear that I can't take a work licensed under the Microsoft EULA and submit it to the IETF though. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Including the GPL in GPL code (Re: IETF and open source license compatibility)
This is getting off-topic, and seems like typical FAQ material, but I'll reply briefly. I suggest using, e.g., discuss...@fsfeurope.org to get other people's interpretations. If you want a more authoritative answer, talk to licens...@gnu.org. Harald Alvestrand har...@alvestrand.no writes: BTW, this means that at least one program I have released under the GPL is illegal; it includes the GPL as a part of the source code, and since the GPL text is immutable according to the GPL, it is illegal (by this logic) to include it in source code, since the source has to be free of restrictions upon its modification. I don't see how that makes the program illegal. It just makes it harder for others to redistribute it safely because the licensing information is unclear. Simon, the example is at http://counter.li.org/scripts/machine-update. Take a look. There is a single file that contains both the program source and the GPL. I want to release this under the GPL. You can't release the text of the GPL under the GPL license, since you are not the copyright holder of the text in the GPL license. Further, the license of the GPL text does not permit re-licensing, or even modifications. Now, I have three possible interpretations: 1 - The words of the GPL that say Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. don't really apply in this case. That interpretation seems clearly bogus to me. 2 - The words of the GPL that say You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above don't apply to modifications of the portion of the Program that is the GPL This seems more or less correct, even though it may sound surprising at first. More generally, and more clearly expressed, it can be stated as this: The license for a piece of work applies to the piece of work, it does not apply to the license itself. The license of a work is not normally not considered part of the work; it is metadata about the work. 3 - I'm breaking the GPL That may hold as well, but without further elaboration I can't tell for sure. I compared the part of your work that consists of the GPL text with the canonical version [1]. It seems that someone has modified the license text: the section 'How to Apply These Terms to Your New Programs' is missing. If you had read that section, you would know of a better way to explain the licensing conditions to users that would have avoided the problem. I believe this violate the license on the GPL itself, so you may want to fix it. However, I don't think the FSF will care significantly about that problem. For more information, see: http://www.gnu.org/licenses/gpl-howto.html Now, with your extensive knowledge of what the GPL means for included text which is it? Your question comes up and is answered in Debian mailing lists from time to time: some people claim that Debian cannot distribute the GPL license text because it is not licensed under a free software license. /Simon [1] http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Including the GPL in GPL code (Re: IETF and open source license compatibility)
pasi.ero...@nokia.com writes: Simon Josefsson wrote: Generally, however, I think this question is very different from where this thread started. It started, as far as I consider, with Stephan suggesting that free software authors publish free (as in licensed under a free software license) standards in the IETF. That is not possible, and is unrelated to the question we discuss here. BTW, why cannot a free software author license some particular standards text under both RFC 5378 terms, and some other license (a free software license, or even GPL)? Presumably, he/she owns the copyright, and 5378 terms are non-exclusive. Obviously, for collaborative efforts this may require that all copyright holders agree, and that may make this unpractical. But I wonder if there was some other reason? No, that approach works fine as far as I can see. It has been used for some documents, and parts of some documents, already. That doesn't make the standard published by the IETF free as in free software licensed though. I admit this is a subtle distinction, and given the discussion, I must have explained this poorly. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: On the best use of IETF resources with respect to IPR
Paul Hoffman paul.hoff...@vpnc.org writes: I am aware that battle is already lost, so I have mixed feelings about discussing this further. ...so you launched dozens of people with much less understanding than you into sending one-way comments on the topic. In the future, please check your mix of feelings more carefully. Paul, I won't respond to the rest of your e-mail since I believe my position is already clear, however blaming me for the FSF campaign is unfair. I am not responsible for that. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-tls-authz-extns-07
Thierry Moreau thierry.mor...@connotech.com writes: Simon Josefsson wrote: When evaluating whether to implement a particular technology, you need to evaluate all the risks. The text of patent (applications) helps in the evaluation. My point is that the actions of patent holders is significantly more relevant. Dear Simon: Interesting, and completely new to me. Do you have any guidelines / methodology / evaluation criteria / sources of precedents or any other sources of law? According to those, one could turn emprircal-observations-of-patent-holder-actions into a) an evaluation whether to implement and/or b) an evaluation whether to adopt as an IETF document (standards track / informational / experimental). Perhaps there is some form of non written IPR etiquette. See RFC 3669, it contains good discussion and interesting examples. The evaluation done in the examples of RFC 3669 does not generally seem to be of what's in the actual patent text. Instead people have evaluated the actions taken (or not taken) by patent holders. This re-inforces my point. Perhaps you have an intuitive talent at this type of analysis and you are the Oracle in the present instance, i.e. you made the evaluation and then the FSF started its campaign. Heh. I have been careful to avoid reading any patent text or make any judgement of the patent disclaimer and licensing conditions. That is not my field of expertise. I do not have any influence over what the FSF does or decides here. One person can't reliable make a decision like this, it needs to be discussed by the community and people can provide their thoughts on the topic. Eventually, after hearing what people have said, everyone can form their own opinion of the situation. This is what I've done, and I have also made my opinion publicly known in this discussion. That doesn't mean I cannot be convinced otherwise. There are two things I believe are critical in this discussion: 1) how widely the patent filer believes their patent applies, and 2) the licensing conditions offered by the patent filer. Item 2) has apparently been evaluated by the FSF and they found that the conditions doesn't allow wide use of implementations. Reading the patent disclaimer myself, I don't see anything that invalidates this evaluation, and I see things that re-inforce the evaluation. The FSF has access to legal aid and has a track record in working in this area. Some engineers, like Pasi and Sam seems to believe the opposite. However, the FSF takes the legal risk if I re-add the tls-authz implementation to GnuTLS. So to me the FSFs evaluation carry more weight. Item 1) is, alas, difficult to judge without the vulcan mind melt, but it is warranted to be conservative. The licensing conditions demanded for certain uses also gives some indication of the scope of the perceived applicability. As far as I can tell, the simplest approach to resolve the problem would be to offer the technology for free use to anyone without limitation. This solves item 2) and makes the more difficult to judge item 1) irrelevant. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: yet another comment on draft-housley-tls-authz-extns-07.txt
Stephan Wenger st...@stewe.org writes: Hi Simon, On 2/11/09 4:43 PM, Simon Josefsson si...@josefsson.org wrote: Stephan Wenger st...@stewe.org writes: [...] The way to address this misalignment is to work in the IETF towards an FSF-compatible patent regime, and not rant about one specific draft that somehow got on the FSF's campaign radar. The best way, IMO, to work towards such a regime, would be that FSF activists, instead of wasting their time on mailbombing, invent great new concepts, protocols, and write them down in the form of Internet drafts, and make them freely available in the IETF and elsewhere. That's not possible because the IETF policies does not permit free software compatible licensing on Internet drafts published by the IETF. /Simon I don't understand why inventing, designing protocols, and writing their specification down in the form of Internet Drafts according to the IETF policies would necessarily be incompatible with what some people call free software. See RFC 5378: It is also important to note that additional copyright notices are not permitted in IETF Documents except in the case where such document is the product of a joint development effort between the IETF and another standards development organization or is a republication of the work of another standards development organization. Such exceptions must be approved on an individual basis by the IAB. The IETF copying conditions are not compatible with free software licenses (modification is not allowed), and additional copyright notices are not permitted. The vast majority of free software licenses is built on the concept of copyright notices and requires preserving the copyright notice. It is possible for authors to release the document outside of the IETF, but the point above was that it is not possible to do within the IETF. With a bit of flexibility and good will on both sides, I view this as entirely possible. The IETF can conduct process experiments if those were required, including an experiment of temporarily suspending certain features of its policies. And, perhaps, the free software people could be a little bit more relaxed in insisting on licensing terms of their initial phases of contributions to the IETF. I'm personally willing to support such an effort, even I do not see an immediate benefit for myself. I would support an experiment like this as well. It could for example work by allowing contributors to license their contribution under the BSD license. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
Jari Arkko jari.ar...@piuha.net writes: Simon, That's not possible because the IETF policies does not permit free software compatible licensing on Internet drafts published by the IETF. ... See RFC 5378: It is also important to note that additional copyright notices are not permitted in IETF Documents except ... ... The IETF copying conditions are not compatible with free software licenses (modification is not allowed), and additional copyright notices are not permitted. The vast majority of free software licenses is built on the concept of copyright notices and requires preserving the copyright notice. I agree that there are problematic case, but I believe I hope everyone realizes this is only the case if the RFC in question has code. Otherwise it really does not matter. Only some RFCs have code. I don't realize that, and completely disagree. If you want free software authors to publish free standards (as in free software compatible) in the IETF, the IETF needs to allow free software compatible licensing of their work. Right now, the IETF disallow standards published through the IETF to be licensed under a free software compatible license. The only alternative for these authors is to release their work outside of the IETF. This may result in some free software authors doesn't bother publishing their work in the IETF because the licensing models are incompatible. I support experiments in this space, though. And it would be really good to get more of the open source folk participate in IETF specification work. There are many important open source extensions and protocols that fit in IETF's scope but were never documented. Even if source code is freely available, you could have several implementations, commercial vs. open source interoperability issues, etc. I agree. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
Jari Arkko jari.ar...@piuha.net writes: Harald, Margaret, and Simon, Harald wrote actually that's intended to be permitted by RFC 5377 section 4.2: and Margaret wrote: However, I don't think that anyone actually believes that the IETF will track down people who copy RFC text into comments and sue them or attempt to get injunctions against them. (2) Even if the IETF did try to sue you for copying sections of RFC text into your source code comments, they'd almost certainly lose So it seems that we actually do have at least some ability to deal with comment-style use of RFCs fragments in free software. Simon, do you see any residual issues that we need to solve, or were your concerns in areas other than comments? The discussion started by Stephan suggesting that free software authors publish their work as free standards in the IETF. My point was that since the IETF disallow publishing standards under a license that is compatible with free software licensing (e.g., allows modification), it is not possible for free software authors to do this. Thus, to me, this discussion is not related to comments in source code at all. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
Joel M. Halpern j...@joelhalpern.com writes: I disagree Simon. Free Software authors (for any variety of free software I know of) are free to submit I-Ds describing protocols that they define. Sure. And some do... They can not take their licensed code, with license restrictions, and put it in the RFC. Right. The primary reason for this restriction, in my view, is that some of the licenses out there would actually interfere with commercial implementations of the RFC if such double-licensing were allowed and done. And just as we want to allow free implementations of the RFCs, we also want to allow commercial implementations of RFCs, for a wide range of commercial goals (just as there are a wide range of free rules and goals.) Right. (However, that doesn't explain why the IETF disallows BSD licensed code in IETF documents.) Preventing folks from putting code with non-IETF licenses into RFCs allows everyone to write RFCs, and allows a wide range of code to be included in RFCs. Making sure that code which is included in RFCs can be used by any implementator, as they need to, is important and useful. Extra licenses distinctly interfere with that. (We do permit references to licensed code in our documents, including specific URLs.) Agreed. And having a restriction that folks can not take and modify large blocks of text from the RFC does not prevent them from either writing RFCs or implementing protocols defined in RFCs. Right. Please re-read what I said earlier, because I don't see any disagreement with what I've claimed before. My claim has been that authors cannot publish free, as in licensed under a free software compatible licensed, documents through the IETF. You explained again that this is the case, and you gave the reasons for this. So we seem to agree. /Simon Yours, Joel Simon Josefsson wrote: Jari Arkko jari.ar...@piuha.net writes: Simon, That's not possible because the IETF policies does not permit free software compatible licensing on Internet drafts published by the IETF. ... See RFC 5378: It is also important to note that additional copyright notices are not permitted in IETF Documents except ... ... The IETF copying conditions are not compatible with free software licenses (modification is not allowed), and additional copyright notices are not permitted. The vast majority of free software licenses is built on the concept of copyright notices and requires preserving the copyright notice. I agree that there are problematic case, but I believe I hope everyone realizes this is only the case if the RFC in question has code. Otherwise it really does not matter. Only some RFCs have code. I don't realize that, and completely disagree. If you want free software authors to publish free standards (as in free software compatible) in the IETF, the IETF needs to allow free software compatible licensing of their work. Right now, the IETF disallow standards published through the IETF to be licensed under a free software compatible license. The only alternative for these authors is to release their work outside of the IETF. This may result in some free software authors doesn't bother publishing their work in the IETF because the licensing models are incompatible. I support experiments in this space, though. And it would be really good to get more of the open source folk participate in IETF specification work. There are many important open source extensions and protocols that fit in IETF's scope but were never documented. Even if source code is freely available, you could have several implementations, commercial vs. open source interoperability issues, etc. I agree. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-tls-authz-extns-07
Thierry Moreau thierry.mor...@connotech.com writes: You seem to assume that patent rights are created by the IPR disclosure, while they are created by the *patent* (in this case still at the application stage) that you didn't study. I've seen you claim this a few times, and I wish to attempt to refute the argument. What we are evaluating here is how the patent status around the technology affects deployment and smooth operations of the Internet. While the claims in a patent (application) is relevant, it is not the only thing that is relevant. There are many patents out there that, if enforced, would make it impossible to implement core Internet protocols. I'm told the TLS protocol itself is covered by several patents, for example. We don't care as much about those patents because nobody appears to enforce them. That proves that the claims made in patents aren't the only thing we must look at. The actions taken by the patent filer, and the licensing conditions demanded by the patent filer is usually more interesting. There are organizations that use patents as a threat to sue other organizations. In these cases, the patent is not as important as the legal threat. It is possible to threaten to sue even if the patent is irrelevant to the case at hand, for anyone sufficiently familiar with the technology. That doesn't change the legal risk. When evaluating whether to implement a particular technology, you need to evaluate all the risks. The text of patent (applications) helps in the evaluation. My point is that the actions of patent holders is significantly more relevant. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: yet another comment on draft-housley-tls-authz-extns-07.txt
Stephan Wenger st...@stewe.org writes: Hi, On 2/11/09 3:21 PM, Bob Jolliffe bobjolli...@gmail.com wrote: [...] I think (I hope) their is a general consensus that IETF standards should be freely implementable and usable for the manner in which they are intended. The phrase freely implementable and usable may be the key misconception/misunderstanding by the FSF people. As several hundred IPR disclosures with RAND terms against issued standards track RFCs show, the consensus (at least in those cases) in the IETF has been, and still is, that IETF RFCs do not necessarily have to be royalty-free or unencumbered. Personally, I view those as free just as well; my definition of freedom is somewhat different than the FSF's definition. I fully understand that this is not aligned with FSF's position on standards in general. The way to address this misalignment is to work in the IETF towards an FSF-compatible patent regime, and not rant about one specific draft that somehow got on the FSF's campaign radar. The best way, IMO, to work towards such a regime, would be that FSF activists, instead of wasting their time on mailbombing, invent great new concepts, protocols, and write them down in the form of Internet drafts, and make them freely available in the IETF and elsewhere. That's not possible because the IETF policies does not permit free software compatible licensing on Internet drafts published by the IETF. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: patent threat for draft-housley-tls-authz-extns-07
Clint Chaplin clint.chap...@gmail.com writes: Undergoing a ballot? Is it possible these people believe that they're stuffing a ballot box? Shows they do not understand what an IETF last call is about. The term ballot is used in several places to describe the IESG decision process, for example: https://datatracker.ietf.org/idtracker/draft-housley-tls-authz-extns/ https://datatracker.ietf.org/idtracker/ballot/2081/ http://www.ietf.org/rfc/rfc4677.txt http://www.ietf.org/rfc/rfc4858.txt That may be what the original authors was referring to. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
