Re: An Antitrust Policy for the IETF
I support the general approach you outline in terms of process. However it would really help me if you could write a non-normative paragraph describing what you think is involved in an anti-trust policy? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: An Antitrust Policy for the IETF
Russ == Russ Housley hous...@vigilsec.com writes: Russ Sam: I looked at the antitrust policies of other SDOs. They Russ state the things that are prohibited from discussion at their Russ meetings and on their mail lists. OK, that sounds good. I definitely think we could use such a thing. And again, your process sounds like a reasonable way to go. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: An Antitrust Policy for the IETF
Michael == Michael Richardson m...@sandelman.ca writes: Michael I'm still lost. Michael What kind of things would the IETF have to prohibit Michael discussion of, and specifically things that would involve Michael anti-trust. Cisco and Juniper folks form a design-team including a WG chair and excluding vendor x. There was a discussion of how licensing practices affect the availability of technology in KARP that was on the border of what's acceptable. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Requirement to go to meetings
Dave == Dave CROCKER d...@dcrocker.net writes: Dave On 10/21/2011 7:58 PM, Melinda Shore wrote: It's increasingly the case that if you want to do work at the IETF, you need to go to meetings. I'd have considerable reservations about asking for the kind of money you're suggesting. Dave Melinda, Dave I've changed the subject line because the point you raise is Dave orthogonal to the main thread, but since you raise it, it's Dave worth exploring a bit (since I happen to agree with your Dave observation.) Dave, count this as another area where something you seem to find obvious is not obvious to me and kind of goes against my observations. I think that if you want to chair a working group or bring new work to the IETF you probably need to attend the face-to-face meetings. I haven't seen much of a change in the above. Nor have I personally witnessed a decline in the influence of people who attend remotely. In working groups I follow a number of key individuals attend the meetings less.. Some of them also spend less time on the IETF; they do seem to have lost influence, but others who still spend significant time do not seem to have lost influence. So, I'm curious what observations lead people to this conclusion. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Olaf == Olaf Kolkman o...@nlnetlabs.nl writes: Olaf Dear Colleagues, Olaf I have just chartered a very short draft that intends to Olaf update BCP101. It can be found at: Olaf http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership Olaf The draft is very short and contains only a few sentences of Olaf substance: OlafThe IETF chair, the IAB chair, and the ISOC President/CEO Olaf may delegate their responsibilities to other persons. The Olaf delegations by the IETF chair and the IAB chair need to be Olaf confirmed by the IESG and IAB respectively. The terms of Olaf delegation is for a longer term for instance aligned with the Olaf IESG and IAB appointment cycles (roughly anual). I'm strongly in favor of the principle behind this draft. Presumably the delegate would be subject to recall through the normal recall process (as are all IAOC members today except for the ISOC president) You should spell out things like whether the delegating IAOC member may recall their delegation and whether the body (IAB/IESG) may recall the delegate. You should consider whether the IAOC needs to accept the delegate. I think the above issues should be considered. No specific results to the consideration of those issues would be blocking for me. I think this is a great idea! I do think a mechanism like this could be used badly. So we should be responsible:-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
I think the draft would be improved by explicitly considering these issues and not remaining silent, even if the decision is to say that these are full members; existing processes for recall etc apply; at the time of writing that means blah. I think that would lead to better discussion and review of these issues than remaining silent. I don't have a particular problem if the answer is that the recall procedure can be used, these people can vote against the interests of the person whose place they are taking, the IAOC need not accept them, etc. I would prefer the issues be discussed by the community and that written down, possibly in a non-normative section rather than the draft remain silent. I would strongly prefer that if we restate things implied from other documents we do so in a non-normative manner. Again, my primary point remains this is a great idea! ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
Dave == Dave CROCKER d...@dcrocker.net writes: Dave On 9/19/2011 8:35 AM, Spencer Dawkins wrote: Anything that the IETF can do, to make the IAB and IETF Chair positions less of a full-time (or more) job, is a good thing. Dave Anything? I believe you do not believe that statement, but I Dave think it accurately summarizes the focus of this thread, so Dave far. Dave The problem is with how absolute your language is. It Dave declares one criterion as entirely dominating all others. Dave, thanks for a very thoughtful response to the issue. I think you brig up s that we should carefully consider. I believe that I had considered issues generally similar to yours before indicating support for the proposal. I've considered your specific concerns and that does not change my belief that providing the IAB and IETF chairs this tool is a good idea. I think they should be evaluated in part on whether they use the tool responsibly, but I'm happy to trust them to do so. However I do believe these are important things to think about. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Conclusion of the last call on draft-housley-two-maturity-levels
Keith == Keith Moore mo...@network-heretics.com writes: Keith 2) This will not do any good Keith IMO, that is a valid objection. Stability in our process is Keith desirable; therefore change merely for the sake of change is Keith undesirable. This will not do any good, stability is important, so this should not be done, is an objection. This will not do any good, is neutral. You believe that stability is important. Others believe that forward progress and being seen to do something are good. I do tend to come down on your side, and if I think something isn't going to do do good I'm likely to actually state an objection. However for a lot of reasons, I think the IESG should actually require people to present something that is constructionally supportive or an objection before counting it as such. This will not do any good, is not such. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Conclusion of the last call on draft-housley-two-maturity-levels
Hi. I feel it's reasonable for me to speak up since I have not done so in over a year on this document so my opinion probably has not been counted. 1) I support moving to a two level process. 2) I've generally supported versions of this document I have read. I have not read this version in detail. In regard to more global issues. I do not think the following types of comments should be considered as objections when judging this sort of consensus: 1) You are not solving the most important problem 2) This will not do any good Statements of those forms can be combined with objections. This will not do any good and might do harm so I don't support it, clearly is an objection. Objections can be as simple and non-specific as I don't like it, or more actionable. More thought out objections carry more weight in some senses. I certainly would hate to see us block on someone simply saying I don't like it. Either enough people say that that we fail to have rough consensus or not enough people say that and we move on. More detailed objections may be worth blocking on for a time to try and resolve; we seem to be past point of diminishing returns here. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Eric == Eric Burger ebur...@standardstrack.com writes: Eric This highlights an interesting issue as an RFC goes from PS to Eric IS. I would offer that most SHOULDs in a document will, if Eric there are real implementations out there, migrate to MUST or Eric MUST NOT. Eric On Aug 31, 2011, at 9:57 AM, hector wrote: Hmm. Most of the times I use SHOULD I'd expect them to stay SHOULD. SHOULD doesn't mean this feature is desired, it means do this unless you have justification for doing something else. There are a few cases (new algorithms) where you mean SHOULD+ (we'll move to MUST in the future) but often you mean do this unless you're in a constrained environment, or you know you won't need it or something like that. In those cases, SHOULDS tend to stay SHOULDS. ___ 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: Why should we require that alg-ids be registered URIs? That's not my concern - the existing first paragraph of the IANA considerations section in the draft requires IANA registration (or at least tries to) by pointing to the PSKC registry. My concern is that if this is going to be done, it needs to be done right (duh!), and the current text is insufficient. Please take the issue of whether to use IANA for this purpose up with Gareth and the WG. I have no problem with the IETF registering its algorithms there, or us encouraging people to register them there, but it's a URI. What purpose is served by forcing registration? Hmm - more than one URI for the same algorithm might cause interoperability problems. gSome 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 don't really care so just fix the current text to resolve David's concern. My point was simply that whatever spec tells you how to use some algorithm with Kerberos can provide a unique URI and I'm unconvinced that it matters where that URI is drawn so long as everyone agrees on the URI. Having a registry for everything the IETF does is fine; reusing an existing registry is better. Constraining what non-IETF people do seems kind of silly but they will not listen to us anyway, so no harm is done. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
What information required by the PSC registry do we not need? The only thing I see is the XML information, but it looks like that could be blank. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
Henry == Henry B Hotz h...@jpl.nasa.gov writes: Henry I was thinking that if it's a proprietary OTP, we can still Henry use it even if the algorithm is secret. If we know we're Henry getting a clear text OTP value and we have an (unspecified) Henry method of verifying it against some external infrastructure, Henry that's enough to use otp-preauth. However I don't think this Henry actually requires a complete registry. A single Henry undefined/external entry for the existing PSKC registry would Henry be sufficient, wouldn't it? It's exactly the proprietary OTPs where I think they should specify their own URI in their own namespace. ___ 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: Could we add a URI list to draft-lha-krb-wg-some-numbers-to-iana? We could do that. Doing so would be a very inefficient way of moving the OTP document forward. I'd recommend that we use an existing registry. If we cannot do that, we'll need to do the registry in the OTP document. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
Hadriel If we use actual *attendance* as a form of voting, Hadriel Minneapolis would lose big time. I don't think using actual attendance is the right metric. Actual attendance of people who submitted internet drafts or chaired meetings would be closer, but is also problematic. My goals are to: 1) Make IETFs easy for people doing current technical work within the organization 2) Ease getting involved in doing technical work in the organization I'm not sure what metric is best for judging things, but I have low confidence that raw attendance maps onto those two goals. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
Melinda == Melinda Shore melinda.sh...@gmail.com writes: Melinda On 08/24/2011 07:47 AM, Keith Moore wrote: Maybe they don't realize it, but at that point they're actively working to exclude participation from those not supported by large companies or governments. Melinda It seems to me that this is a very, very important point. I'd like to underscore this poin. I'd like to make two others. 1) We don't have to go to any particular location. There has been an assumption made by people in this discussion that sometimes when we pick locations with particularly expensive hotels, we'll get particularly expensive meetings. That's great except that we were the ones who chose to go to those locations. If we can't meet our cost targets at a location, go somewhere else. 2) If I had to say yes or no in a parliamentary vote of confidence in the IAOC, today my answer would probably be no. I feel that a lot of concerns have been raised, and I don't find the responses very convincing. When I've looked into issues with the IAOC, I haven't found the visibility necessary to really evaluate things. That to me is not a good combination. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
Dave == Dave CROCKER d...@dcrocker.net writes: Dave ps. As a personal aside, I'll note that I've lobbied rather Dave vigorously for venues that entail less travel effort, by Dave eliminating the additional hop needed to get from a major hub. Dave Note that that has gotten essentially zero support from the Dave community. The community has vigrously expressed a preference Dave for interesting venues rather than ones that are chosen Dave solely for logistics convenience. Can you start by backing up the assertion that the community has vigrously expressed a preference for interesting venues? I may just need a new IETF community:-) ___ 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
david.bl...@emc.com writes: [1] In section 6.1 at the top of p.28, I don't believe that the use of lower case recommended is a strong enough warning about the danger in using anonymous PKINIT because it exposes the OTP value: It is therefore recommended that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC and that careful consideration be made of the security implications before it is used with other algorithms such as those with short OTP values. At a minimum, that warning should be in upper-case: It is therefore RECOMMENDED that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. Beyond that, the security issue in the first sentence may be severe enough to justify a prohibition, so the following would also be acceptable: Therefore anonymous PKINIT SHALL NOT be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. I definitely agree that we should use RFC 2119 language. Note that WG participants have questioned this text in last call for other reasons. Many implementations use anonymous pkinit in a mode where the KDC's certificate is verified--that is the client is anonymous but the KDC is identified through a PKI. WG participants believe (and I agree) that the security concern does not apply at all in this case. So, the text needs reworking. [2] In section 5, the first paragraph in the IANA considerations is unclear, and following its reference to section 4.1, I don't see any clarifying text there either. I think Sections 4.1 and 4.2 need to say that the value of otp-algID is a URI obtained from the PSKC Algorithm URI Registry, and the first paragraph in section 5 should say that URIs for otp-algID are to be registered in that registry, see RFC 6030. Why should we require that alg-ids be registered URIs? I.E. what is wrong with me using http://algorithms.painless-security.com/otp/best-thing-since-unsliced-bread (or a tag URI if you like) for my OTP algorithm? I have no problem with the IETF registering its algorithms there, or us encouraging people to register them them, but it's a URI. What purpose is served by forcing registration? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discussing a DISCUSS - down-refs in draft-ietf-yam-rfc4409bis-02
SM == SM s...@resistor.net writes: SM There is currently a DISCUSS for draft-ietf-yam-rfc4409bis-02: SM process weenie= SM The IETF LC SM (https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=934k2=9680tid=1314107697) SM did not call out the downrefs to RFC 4954 and 5321. There is no SM doubt in my mind that no one will object to these downrefs, but SM they need to be explicitly called out in the IETF LC. SM /process SM The intent of this message is to discuss the DISCUSS as there SM seems to be a misunderstanding about down-refs. I do not SM consider it as inappropriate for the AD to have lodged the above SM DISCUSS. SM The argument for this DISCUSS is that the downrefs to RFC 4954 SM and 5321 have not been called out during the IETF Last Call. SM The quick fix is to rerun the Last Call. That approach would SM not materially affect the outcome. SM I have pointed out during the Last Call that there are down-refs SM [1] and provided a justification for them. Appendix B of SM draft-ietf-yam-rfc4409bis-02 contains a RFC 4897 statement/ SM disclaimer. Hey, I think I read RFC 4897 once. Someone's actually trying to use that? Who knew! Seriously, section 3.1 of RFC 4897 makes it clear that an RFC 4897 downward reference does not need an RFC 3967-style comment in the IETF last call. As best I can tell, this discuss should be cleared because The AD is confused about what BCP is being applied here. Really this is one of those situations where we're all sitting around the table playing a nice game of publish that doc and people have to get out their copy of the IETF rules, the IETF rules erata and the IETF player's magazine articles with rules commentary and figure out what is going on.:-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Ietf-krb-wg] AD review of draft-ietf-krb-wg-otp-preauth
Greg == Greg Hudson ghud...@mit.edu writes: 87 Greg On Fri, 2011-08-19 at 08:53 -0400, gareth.richa...@rsa.com wrote: I had always thought the same way as Sam, that clients would be required to implement all of the options since there appears to be no other way for them to support different disconnected token types. The specification was intended to be token independent and the assumption was always that the clients would also be. Greg I agree, at least at the general level and for disconnected Greg tokens. (Does nextOTP make any sense for disconnected Greg tokens?) I think you prompt the person to hit the next value button ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Ietf-krb-wg] AD review of draft-ietf-krb-wg-otp-preauth
My take as an individual is that most of the people who have read the draft and commented here read it the same way. It's up to the AD to decide if things are clear enough but I'm not pushing for any specific change and would be happy if no change were made on this point. I would not push back against any clarity the AD or IESG request in this space. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: AD review of draft-ietf-krb-wg-otp-preauth
Simon == Simon Josefsson si...@josefsson.org writes: Simon Sam Hartman hartmans-i...@mit.edu writes: Actually, I have a question about interoperability here. It's my assumption that a client of this specification needs to implement basically all the options: * encrypted OTP values and values used for key derivation * separate pins and pins that are together * at least 4 pass mode So that the server has flexibility to implement what its OTP token requires. Are people assuming that it is acceptable to implement a client that only implements the facilities needed by one particular OTP token? Simon Yes, and I believe that is unavoidable -- there is no way to Simon properly test all features of any implementation without Simon having some OTP token that excercises each feature. OK. That makes me very uncomfortable. As an individual I'd prefer that this draft not be published without a mandatory-to-implement subset. My assumption was that the client needed to implement everything. If that's not globally held I think we have much more work to do. Please consider this an individual last call comment, not as a comment as a chair. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-ospf-auth-trailer-ospfv3-05.txt (Supporting Authentication Trailer for OSPFv3) to Proposed Standard
Hi. I've reviewed the draft-ietf-ospf-auth-trailer-ospfv3-05 for consistency with draft-ietf-karp-ospf-analysis. KARP is chartered to figure out what improvements we need in routing protocol authenticationq. While draft-ietf-karp-ospf-analysis has not been approved by the WG, I think it's fairly close to our current thinking on what needs to be done to OSPF authentication. I believe we should either be consistent with that thinking or if during the discussion we discover that what we're doing in KARP is incorrect decide to update the KARP document. Based on this review I have a few recommendations for the OSPF v3 authentication trailers document. 1) The v3 authentication trailer takes a step back in the ability to rekey security associations both from OSPF v2, from IPsec for OSPF v3 and from draft-ietf-karp-crypto-tables. At the top of page 231 of RFC 2328, OSPF v2 security associations are defined with four lifetimes: KeyStartGenerate, KeyStartAccept, KeyStopGenerate and KeyStopAccept. Similarly, RFC 4301 defines a lifetime value for the SAs used by OSPFv3; in that case, whether an SA is an outbound or inbound SA controls whether it can be used for reception, generation or both at the current time. In the KARP crypto tables, lifetimes related to when packets can be sent are included: SAs are deleted from the crypto table to prevent reception. However the V3 auth trailer draft leaves this all up to implementation defined behavior. draft-ietf-karp-ospf-analysis indicates that we're going to remind people of the existing OSPF requirements for keylifetimes because they are necessary for key rollover. I believe that draft-ietf-ospf-auth-trailer-ospfv3-05 needs to be revised to require implementation behavior at least as flexible as draft-ietf-karp-crypto-tables. That is, associated with each security association is a time for when sending packets can start with a given SA and for when it must stop. Infinity and 0 should of course be supported for the appropriate times. 2) I notice terminology inconsistency between key identifier and security association identifier. This should probably be cleaned up, although it's not that big of a deal. 3) draft-ietf-ospf-analysis says that we are going to solve related protocol attacks. That is, we recognize that it's quite likely that some people will use the same preshared key both for OSPF authentication and for something else. We need to mix something into the key or hash or something that is unlikely to appear in any other use in order to make it cryptographically unlikely for the resulting OSPF authentication hash to be a hash useful in some other protocol or for the hash from some other protocol to be useful in OSPF. This draft does not do that. One possible way to solve this would be to prepend a constant in front of the key in the key preparation step or a constant in front of every packet that gets hashed. The constant should be the same for OSPFv3 and not used for any other purpose. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Ietf-krb-wg] Last Call: draft-ietf-krb-wg-otp-preauth-18.txt (OTP Pre-authentication) to Proposed Standard
Hi. Just around the time that this document was sent to the IESG, a discussion started surrounding the nonce text in this draft in the Kerberos working group. All the participants seemed to agree that the discussion was non-blocking: if consensus on a change was not found before ietf last call ended, then the existing text would stand. So, I did not ask our AD to block the draft. However, the Kerberos working group did reach a consensus on new text. We'd like to propose to the IETF that The text in section 4.1 is changed from: This nonce string MUST be as long as the longest key length of the symmetric key types that the KDC supports and MUST be chosen randomly. to This nonce string MUST contain a randomly chosen component at least as long as the armor key length. The KDC can then compose a nonce out of a random component and a timestamp. This change has already reached consensus within the working group. If there are no objections (especially including objections from our AD) I'll ask the authors to make this change. If there are objections then our AD will judge consensus as usual. Sam hartman Kerberos Co-chair ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-ietf-msec-gdoi-update
Brian == Brian Weis b...@cisco.com writes: Brian Hi Sam, Thanks for your review. Brian Your first comment is pointing out a typo (groupkey-pull Brian should be groupkey-push), which I've fixed. Brian The anti-replay description in Section 3.3 should not say Brian that the push message sequence number will be reset to Brian 1. Text earlier in this section says that the SEQ payload Brian carries the next expected sequence number, and so when the Brian KEK is installed that is the number that should be Brian installed. I've adjusted the text to say this: If this group Brian has a KEK, the KEK policy and keys are marked as ready for Brian use and the GM knows to expect a sequence number not less Brian than the one distributed in the SEQ payload. Let me know if Brian that change sufficiently clears up the confusion. Yes, all looks good. The typo plus the text in 3e.3 caused me to wonder whether something more complex than I had anticipated was going on with replay. The new text is quite clear. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review of draft-ietf-msec-gdoi-update
This update to the GDOI specification significantly improves clarity and readability. However, there is one issue that I think should be addressed prior to publication: At the top of page 11, the spec claims that a seq payload protects against group members responding to groupkey-pull messages sent prior to joining the group. I'm reasonably sure that should be groupkey-push messages; I believe the nonce payloads provide replay protection for the pull exchange. Actually, it's more complicated than that. Section 3.3 also seems to believe the sequence number is about pull exchanges. However it says that a GM should always expect the push message sequence number to be reset to 1. Why is that reasonable? If a group is ongoing, don't we want to tell new members what the sequence number currently is rather than having them assume it is 1? The push message is multicast, so we cannot maintain a separate sequence number for each member. I think either there is some sort of error with the description of the replay mechanisms or it requires significantly more explanation. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Drafts Submissions cut-off
I think removing the cutoff is the right approach here. I'd prefer that some date remain on the list of important meeting dates to remind ourselves that revisions should be in in time for people to read them. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Drafts Submissions cut-off
Keith == Keith Moore mo...@network-heretics.com writes: Keith On Aug 1, 2011, at 3:59 PM, Sam Hartman wrote: I think removing the cutoff is the right approach here. I'd prefer that some date remain on the list of important meeting dates to remind ourselves that revisions should be in in time for people to read them. Keith If memory serves, the original purpose of the cutoff was to Keith avoid overtaxing the resources of the Secretariat in the Keith period immediately prior to IETF meetings. But it has also Keith come in handy for ADs and others who feel the need to keep up Keith with large numbers of documents from a variety of working Keith groups. I wouldn't blame any AD or WG chair for imposing a Keith no drafts submitted after the cutoff can be discussed at the Keith meeting rule. Right. I'd expect chairs to do something along these lines, moderated for their group. Having something on the important meeting dates as a general reminder seems like a good idea to me. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed text for IESG Handling of Historic Status
I'd prefer that we not clutter abstracts with instructions to the RFC editor and prefer that the IESG only recommend such statements in the introduction. I'm OK with whatever here though: the IESG should go do something intelligent in this space. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
Stephen == Stephen Kent k...@bbn.com writes: Stephen The BGPSEC protocol being defined does not pass around ROAs Stephen or other RPKI repository objects. It defines two new, Stephen signed objects that are passed in UPDATE messages, and are Stephen not stored in the repository. These objects are verified Stephen using RPKI certs and CRLs, so there is a linkage. OK, so how will the upgrade work for these signed objects? In particular during phase 2, when both old and new certs (under the old and new profile) are in use, what happens with these signed objects? Can a party generate both old and new signed objects? If so, will the protocol scale appropriately? If not, how does a party know which signed object to generate? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
Stephen == Stephen Kent k...@bbn.com writes: Stephen At 7:48 AM -0400 5/4/11, Sam Hartman wrote: Stephen == Stephen Kent k...@bbn.com writes: Stephen The BGPSEC protocol being defined does not pass around ROAs Stephen or other RPKI repository objects. It defines two new, Stephen signed objects that are passed in UPDATE messages, and are Stephen not stored in the repository. These objects are verified Stephen using RPKI certs and CRLs, so there is a linkage. OK, so how will the upgrade work for these signed objects? In particular during phase 2, when both old and new certs (under the old and new profile) are in use, what happens with these signed objects? Can a party generate both old and new signed objects? If so, will the protocol scale appropriately? If not, how does a party know which signed object to generate? Stephen Sam, Stephen The BGPSEC protocol will have to accommodate changes in the Stephen algs used to validate BGPSEC signed objects, and changes in Stephen algs used to validate RPKI objects, and key (not alg) Stephen changes in the RPKI objects, especially the certs Stephen associated with routers. So, format changes are just Stephen another example of a change in the RPKI that BGPSEC will Stephen have to accommodate. This is a legitimate discussion point Stephen for the BGPSEC protocol design discussions that will take Stephen place in SIDR. It is out of scope for the current set of Stephen docs, since they deal only with origin AS validation. Let me see if I can summarize where we are: You've describe an upgrade strategey for the origin validation in the current set of docs. It depends on the ability to store multiple certs, ROAs and other objects in the repository. You agree that when SIDR looks at using RPKI objects in the newly adopted work it will need some upgrade strategy for format, keys and algorithms. There are probably a number of options for how to accomplish this. Even if the working group did decide to update processing of RPKI objects at that point, requiring new behavior from parties implementing a new protocol would be possible. Is that a reasonable summary? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
Steve, I'd like to thank you for working through these issues with me. I think the new texxt you added before approval is very helpful. You indicated you could add an additional sentence pointing out that multiple signed objects would need to be used in order to deal with phase 2 for end-entity certificates. While I think that would be reasonable to add, I also don't think it is necessary. I'm sorry the upgrade approach was not more obvious from the beginning. Stephen == Stephen Kent k...@bbn.com writes: Stephen I find your last sentence above confusing. I would say Stephen that the BGPSEC protocol will have to define how it deals Stephen with alg changes for the signed objects it defines, with Stephen key changes for RPKI certs, with alg changes for all RPKI Stephen objects, and with format changes for RPKI objects and for Stephen its own objects. Excellent. Please consider it early input to the WG process that how the protocol deals with all of these issues should be documented. The sort of structure you adopted for the text added to cert profile seems like a fine style to use, although of course there are others that would also work. What I think is important is that the IESG and community at large be able to evaluate these transition issues when the protocol comes up for IETf review. In conclusion, thanks again for your help. I see you're giving a talk next Thursday on these issues at an ISOC chapter meeting; I hope to attend and better come up to speed. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
Let me make sure I'm understanding what you're saying. I can have multiple ROAs for the same set of prefixes in the repository and valid at the same time: one signed by a new certificate and one signed by a previous certificate? If so, I think I now begin to understand why the SIDR working group believes this is a reasonable strategy. I guess the only question I'd have remaining is whether ROAs or other signed objects are intended to be used in other protocols besides simply living in the SIDR repository? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
Stephen == Stephen Kent k...@bbn.com writes: I guess the only question I'd have remaining is whether ROAs or other signed objects are intended to be used in other protocols besides simply living in the SIDR repository? Stephen The RPKI repository is designed to support a specific, Stephen narrow set of apps. That's what the CP says, and we try to Stephen make these certs unattractive for other apps, e.g., by use Stephen of the non-meaningful names. You had mentioned that about the PKI before. Now, though I'm focusing on the ROAs and other signed objects, not the certificates and CRLs. Do these narrow applications involve simply storing these objects in the repository, or are there plans to use ROAs or other signed objects as elements in protocols? At least years ago, for example, there was discussion of carrying signatures of objects in BGP. I understand that's not within SIDR's current charter, but is SIDR intended to support that style of use, or have things been narrowed to a point where that would require reworking details of the repository and PKI? If the answer is that those sorts of uses are not in scope for the SIDR architecture, then I think you've basically resolved my concerns. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
Steve, thanks for your note. I realize the certificate resource profile document has been approved, but I'd still like to understand what is happening here. I'm having trouble reconciling the new text you've added to the document with draft-ietf-sidr-signed-object. 2- During phase 2 CAs MUST issue certificates under the new profile, and these certificates MUST co-exist with certificates issued under the old format. (CAs will continue to issue certificates under the old OID/format as well.) The old and new certificates MUST be identical, except for the policy OID and any new extensions, encodings, etc. Relying parties MAY make use of the old or the new certificate formats when processing signed objects retrieved from the RPKI repository system. During this phase, a relying party that elects to process both formats will acquire the same values for all certificate fields that overlap between the old and new formats. Thus if either certificate format is verifiable, the relying party accepts the data from that certificate. This allows CAs to issue certificates under However, when I look at section 2.1.4 in the signed-object document , the signer can only include one certificate. How does that work during phase 2 when some of the RPs support the new format and some only support the old format? Your text above suggests that RPs grab the certificates from the RPKI repository, but it seems at least for end entity certificates they are included in the signed object. What happens for end entity certificates during this form of upgrade? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-05
Russ == Russ Housley hous...@vigilsec.com writes: Russ The 6 months starts with RFC publication. Please say that in the draft then. I had a different take away from the last version of this discussion I participated in. I don't care much what the answer is, but it seems clear that it requires documentation. Apologies if it is already stated elsewhere in the draft: I have not read 05 yet. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF and APIs
At the mic at the technical plenary last night, I made a comment that I strongly supported the IETF doing API work. I've realized that people may have assumed I meant that it would be appropriate for the IETF to specify an API and not a protocol for some given task. That's not what I meant, so I am writing to clarify. I think that multiple levels of interoperability will be required for building blocks used in platforms including the web platform. we're the IETF. We should definitely specify protocols for the building blocks we create. However, one problem that hurts interoperability is when platforms provide different APIs or abstract interfaces to applications. As an example, when we worked on TLS channel bindings to other protocols, we realized that not all TLS implementations provided access to the information we need to construct these channel bindings. Especially as people are trying to build IETF technologies into platforms, it would be strongly desirable to specify what interfaces applications can depend on. I think that we should move more into that business. I see no problem with actually specifying a language-specific API when the WG involved has the skills to do a good job. When we do not, specifying abstract interfaces we expect platforms to provide still has significant value. That, rather than APIs instead of protocols, is what I advocate. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and APIs
Dave == Dave CROCKER d...@dcrocker.net writes: Dave On 3/29/2011 10:13 AM, Sam Hartman wrote: At the mic at the technical plenary last night, I made a comment that I strongly supported the IETF doing API work. I've realized that people may have assumed I meant that it would be appropriate for the IETF to specify an API and not a protocol for some given task. That's not what I meant, so I am writing to clarify. I think that multiple levels of interoperability will be required for building blocks used in platforms including the web platform. Dave Multiple levels of interoperability sounds interesting, and Dave very possibly quite important. One level is the traditional protocol interoperability we normally discuss. Another level shows up when you want to write a cross-platform application. It's not good enough if Windows has some API. I want to have confidence that functionality is available on Windows, OSX, Linux and some of the mobile platforms before I depend on that functionality in a cross-platform API. Within the web platform, I want to make sure functionality is available on multiple browsers before I depend on it in my cross-browser application. we're the IETF. We should definitely specify protocols for the building blocks we create. However, one problem that hurts interoperability is when platforms provide different APIs or abstract interfaces to applications. Dave ... I think that we should move more into that business. I see no problem with actually specifying a language-specific API when the WG involved has the skills to do a good job. Dave Wow. What is the list of languages we should work on? C, Dave C++, Javascript, Java, Python, ...? Any of the above when it makes sense for a WG to do the work. I'd expect that typically you'd only specify one or two language bindings for a given interface. You should have a need to do the work, have the necessary skills to have probable success, have the necessary skills to get review and have people volunteer to do the work. Dave Which is not to deny the problem you cite: APIs differ and Dave this hurts interoperability. Dave One approach to solving it is, indeed, to specify /all/ of the Dave APIs that map to the protocol. Dave Another is to do more and better interoperability testing and Dave let the API developers see their deficiencies and fix them. Dave The benefit of this is that it moves the problem to the folks Dave with the knowledge and incentives to work on it and it takes Dave this very expensive specification task out of the IETF's Dave critical path. My experience is that protocol interoperability testing does not actually lead to cross-platform interoperability. This is especially true for building blocks intended to be used by components that are developed later. The issue is that the people doing interoperability testing at the protocol layer don't tend to be testing for whether things work the same way between platforms. It is when you try and build something on top of a building block that you notice the problem. You tend to notice at one of two layers. The first is if you standardize the higher level item and have participants familiar with multiple platforms involved in the standardization. You can then discover that you don't have sufficient overlapping functionality on platforms to do what you want. Another case where you discover the problem is when you implement and people discover that they cannot do so. Factors that contribute to cross-platform interoperability issues include the following. Often, the people designing and implementing the building block are not the same as the people using the building block. Often, there is separation in time between building block design and building block usage. Often, various factors complicate changing the platform to expose new functionality. In conclusion, in cases where these types of issues are likely to be important, I believe we should do work. Work can include work on abstract interfaces, which will be easier to justify. Work can include concrete APIs which will sometimes be appropriate. I would prefer that this work be standards track not information. Discussions of how to advance MIBs, GSS-API and other standards-track elements already give us approaches to judge interoperability for such elements. --Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and APIs
Marc On 03/29/2011 01:28 PM, Eric Burger wrote: Would we not be better off just asking (mandating?) at least one open source implementation? That effort would produce a de facto API. Marc What you need is a reference implementation (i.e. an Marc inefficient but complete implementation, with a license that Marc permits at least to see the source and generate a binary) AND Marc a test suite. Others have pointed out some of the issues with this approach. However, having been involved in a fairly widely used reference implementation (MIT Kerberos) for over 10 years and having watched it try and evolve from a reference implementation to a platform component, I do not believe that the sorts of things you want out of a reference implementation are what you want out of a platform component. A reference implementation focuses on demonstrating a protocol and being able to develop and debug that protocol and understand it. A platform component focuses on extensibly making the aspects of the protocol that can be building blocks available to the platform. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Secdir review of draft-ietf-sidr-res-certs
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a certificate profile for resource certificates in the RPKI. That is, this is a profile of RFC 5280 that describes behavior for CAs and RPs in the RPKI with regard to resource certificates. I have one large issue I'd like to call to the IETF's attention; I think the WG has made an incorrect technical decision and I'd like the IESG both to review whether they believe that decision is correct and to see if that decision has sufficient support in the broader security and routing community. The basic issue surrounds extensibility and extensions. The working group concluded that they want to closely control how resource certificates are used. To me, that seems like a reasonable decision. So, they mandate that only a specific set of options from RFC 5280 are permitted in resource certificates. This is a constraint on the behavior of CAs. A CA could not for example generate a certificate useful both as a resource certificate and for a purpose requiring a specific subjectAlternativeName. Again, doing so seems entirely reasonable. The document also requires that relying parties reject certificates that include unknown extensions. The rationale explained in section 8 is that it is undesirable to have a situation where if an RP implemented more extensions it would reject certificates that a more minimal RP would accept. In other words the profile picks security and minimalism over extensibility. I'm a fan of security, but I believe this decision is misplaced because I believe it provides the IETF insufficient flexibility to correct errors or evolve the RPKI in the future. Remember that CAs are trusted entities typically within an organization or that you have a contract with. Examples of CAs in the RPKI include RIRs, your ISP and potentially a RPKI CA within your organization. We're saying that the possibility that one of these entities would include an unexpected extension and cause some harm is worth giving up the mechanisms we'd likely use to fix problems or deploy additions to the RPKI in a backward compatible manner. How realistic is it that we would end up finding errors?Well let's take a look at changes in information managed by the RPKI over the last few years. The most obvious change I can think of is that we've moved from 16-bit AS numbers to 32-bit AS numbers (or at least we're trying to get there.) Now it turns out that RFC 3779 handles this correctly and that we don't have a problem in this area. It's also likely given that RFC 3779 uses an unconstrained ASN.1 integer that we wouldn't have run across this specific problem. However I argue that if we've had a transition that could potentially have issues that's a good argument that we need to have a strategy for dealing with errors. There is no discussion in draft-ietf-sidr-arch or draft-ietf-sidr-res-certs that I was able to find out explaining how we'll add information to the RPKI if we find we need to do so in a backward compatible manner. I believe that this needs to be considered by the WG. I also recommend that the restrictions in draft-ietf-sidr-res-certs be relaxed. The restrictions on certificate issuance should remain. The restrictions on validation should be relaxed to permit unknown non-critical Extensions. If we decide that for some certificate we do wish to break backward compatibility we can always introduce a critical Extension. Nothing in section 8 of draft-ietf-sidr-res-certs causes me to believe that the extensibility model of the RPKI is significantly differnt than the model already described in RFC 5280. There's also a consistency problem between RFC 5280 and draft-ietf-sidr-res-certs. Section 4.6 and 4.7 describe validFrom and ValidTo elements. Shouldn't these be notBefore and notAfter? Thanks, --Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Secdir review of draft-ietf-sidr-res-certs
Paul == Paul Hoffman paul.hoff...@vpnc.org writes: Paul On 3/10/11 9:37 AM, Sam Hartman wrote: The document also requires that relying parties reject certificates that include unknown extensions. The rationale explained in section 8 is that it is undesirable to have a situation where if an RP implemented more extensions it would reject certificates that a more minimal RP would accept. In other words the profile picks security and minimalism over extensibility. Paul This statement is too narrow, and it causes your analysis to Paul come to a too narrow conclusion. The profile picks security Paul and minimalism over extensibility *of this profile only*. If a Paul flaw is later found that requires an extension, that extension Paul will be written up in a standards-track document that will Paul obsolete this profile. An implementation that conforms to that Paul new profile will use the extension. Thus, errors can be Paul corrected with new profiles, and the RPKI will have multiple Paul profiles running on it, just as the Internet has multiple Paul versions of some protocols running on it. Paul, that's a great argument for why it's OK to prohibit issuing certificates with new extensions in this profile. We absolutely can change CA behavior with a new profile. However, I don't think your argument makes sense for RP behavior. Under this profile, if an RP is presented with a certificate issued under a new RPKI profile, it will reject that certificate. So, it sounds a lot like you'd need to upgrade all the RPs that might need to rely on a particular resource certificate before you could issue that certificate under a new profile. Given that resource certificates can be used by a lot of RPs--for example anyone who needs to verify origins of a route presumably--that's a long wait. I think that's unjustified. One of us is clearly missing something. I would be happy if it's me. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Secdir review of draft-ietf-sidr-res-certs
Paul == Paul Hoffman paul.hoff...@vpnc.org writes: Paul I don't think either of us is missing something, we just Paul disagree about what needs to happen if a fix that changes the Paul semantics of the certs needs to be made to the system as a Paul whole. For changes that don't change the semantics, you change Paul an existing extension or other part of the certificate; for Paul changes that need to change the system's semantics, you change Paul the certificates in a way that relying parties that don't Paul understand the change won't accept the certificate. Paul Maybe you and I are envisioning different choices being made Paul about those changes. I trust the IETF not to make a change Paul that will cause a lot of relying parties to fail unless the Paul IETF really thinks that is necessary; you may have less faith Paul than I do. (You were on the IESG, so you get to be in the Paul sausage-making more than I have...) I do trust the IETF, which is why I think the current document is very broken. I want to give the IETF the *future* opportunity to balance breaking RPs against confusing behavior. I hate to get into a specific example, because it's very easy to attack the example without the general point. However in the interests of trying to explore our difference, I'd like to come up with a specific example. I may drop the discussion if I feel that we're focusing on the example rather than the general point. So let's pretend that we'd been much more efficient about SIDR and that the RPKI was done prior to 32-bit ASes being a significant issue. Let's pretend that RFC 3779 managed to specify the AS constraint in such a way that 32-bit ASes were excluded. Perhaps there is an ASN.1 constraint on the size of the AS that happens to be rigorously enforced by widely deployed RPs. Regardless of how it happened, assume that we cannot encode 32-bit ASes in the existing extension. In the current model, we have to come up with a new extension. I think this means you need a new independent CA hierarchy for the 32-bit AS certificates. New RPs can use that hierarchy for 32-bit ASes, all RPs use the old hierarchy for the 16-bit AS certs and to the extent they are combined IP certs. In theory we could some day combine these hierarchies when all the RPs support 32-bit ASes. In practice we probably wouldn't because someone out there would implement an RP that broke when the hierarchies were combined and even though it would simplify things the risk of breakage would not justify combining the hierarchies. I'm not sure if this model works: I'd need to analyze whether you can have multiple signatures on an RPKI object, whether you need to claim both an AS and an IP address in signing a route, etc etc. If we're going to go forward with the current model we need at least convince ourselves that even if we did have to duplicate the RPKI to deploy some feature we could do so and not also duplicate the instances of the protocols signing RPKI objects. However, if we had a relaxed model, we'd give the IETF another option. The IETF could also provide a new version of the AS extension for 32-bit ASes. There are huge tradeoffs here. Only new RPs will validate the 32-bit ASes. So you can get into a situation where an RP who is unaware of 32-bit ASes accepts a certificate that a newer RP would reject. However, the 16-bit ASes in that certificate would validate. The IP addresses in that certificate would validate. An appropriately authorized trust anchor would need to create a certificate with a valid certification path that passed all the checks in the old profile. Such a certificate could only be used by an old-profile RP to validate objects permitted under the old profile. An RP that understood 32-bit ASes would be required to understand the 32-bit AS validation. I don't know what the right choice would be in this situation. However in similar situations I'd prefer to make that choice in the future when the IETF is in a position to evaluate the tradeoffs rather than forcing our hand now. Similarly you could imagine a desire to add information to a certificate for auditing, debugging or the like, where validation rules were not changed. Again, I'd prefer to allow the IETF to decide whether breaking RPs should be required to make such changes in the future rather than now. Again, because of extension criticality, we always have the option to force RPs to reject new things they don't understand. The question is whether we want options beyond that. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Cullen, there's a lot of history with port registrations. As you're probably aware in the past, there was a procedure for experts to sign an NDA before reviewing port requests. It's my understanding that is no longer done. However, it does suggest there's strong desire for proprietary protocol support. So, there's lots of complexity specific to this registry here that I don't know about. However, the general idea of having experts reviews on a public list, or even soliciting comments on a public list is well supported. There's specific discussion of this in RFC 5226. We've done it successfully in a number of cases. So, there's reason to believe that things in this space could be effective for IANA registries. I think soliciting public comments on port requests would be bad; I think your proposal of having the request/response be published would be as far as we should go for this registry at this time. So, I don't have the background to say this would be a good fit for the port registry, but to the extent that my background supports something like this I can support your idea. It's worked elsewhere at lesat. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Joe == Joe Touch to...@isi.edu writes: Joe On 1/27/2011 12:52 AM, Lars Eggert wrote: Joe ... Small Issue #3: I object to anonymous review The current review is anonymous and this draft does not seem to change that. I don't like anonymous review - it's not how we do things at IETF and it encourages really bad behavior. I have several emails with an expert reviewer relayed via IANA where the conversation was going no where - once I knew the name of the reviewer, the whole conversation changed and stuff quickly came back to the realm of sane. I'm not willing to forward these emails to the list as that would just not be kind to anyone but I am happy to forward them to the IESG if they think looking at them is really critical. I can see your point, and I personally have no problem with disclosing the reviewer identity. What do others think? Joe AFAICT, the experts team reports to IANA. We make Joe recommendations to them. They are the ones who have the Joe conversation with the applicant. They can take our advice or Joe not - that's their decision. Joe, the IESG had a fair amount of negative experience with this style of review just before I joined; this type of review was just about out of the process leading to blocking objections when I joined as an AD. I think that being able to discuss concerns with reviewers and being able to consider potential conflicts and other issues mean that an open dialogue with identified reviewers is an important part of our process. Anonymous contributions may have their place in the WG process, but I don't think they should have a place in expert review oor blocking objections to documents. So, as an individual I strongly support making expert reviewers identities public. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Joe == Joe Touch to...@isi.edu writes: Joe On 2/1/2011 11:14 AM, Sam Hartman wrote: Joe ... Joe, the IESG had a fair amount of negative experience with this style of review just before I joined; this type of review was just about out of the process leading to blocking objections when I joined as an AD. I think that being able to discuss concerns with reviewers and being able to consider potential conflicts and other issues mean that an open dialogue with identified reviewers is an important part of our process. Anonymous contributions may have their place in the WG process, but I don't think they should have a place in expert review oor blocking objections to documents. So, as an individual I strongly support making expert reviewers identities public. Joe Such reviews occur elsewhere in the IETF as well; it's not a Joe requirement that every review include a list of all consulted Joe parties. This is no different. IANA is the one making the Joe decision of how to use the advice they receive. Joe, RFC 5226 disagrees with you fairly significantly. I draw your attention in particular to section 3.2, and particularly call our attention to several points made there: * The designated expert is responsible for initiating and coordinating the review. * Designated experts are expected to be able to defend their *decisions* to the IETf community * The process is not intended to be secretive * Experts make a single clear recommendation to IANA * In cases of deadlock IESG may be pulled in to resolve disputes * When IANA receives conflicting advice, chair of pool of experts gives clear *instructions* to IANA. On page 10, the expert review criteria requires approval of a designated expert. I submit based on the above that the experts rather than IANA are making the decision; the expert has the responsibility of justifying and defending their decision. Moreover anonymous expert reviews violate two BCP requirements: they tend to a secretive process and they do not facilitate the expert defending their decision to the IETF community. Having read RFc 5226 my objection to anonymous expert reviews is much stronger than when I first read Cullen's message. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Poster sessions
Dale, I agree! I think the bar of producing an internet draft is low enough. Regardless of what mechanisms we adopt to give people a chance to try and sell their drafts, I think it is critical that we require the drafts to be written. I'm not really interested in lowering the bar too much for someone to put together an idea for consideration. I think we gain a fair bit by asking people to refine their idea a fair bit before the initial presentation. Writing a draft is one way of making sure that happens. Above, I'm commenting on the general problem of presenting an idea, not the more complicated question of what the bar should be for BOFs. I'm not surewhether that bar is in the right place. I'd need to think somewhat more about that. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-turner-md5-seccon-update-07.txt (Updated
Martin == Martin Rex m...@sap.com writes: Martin Sam Hartman wrote: I'm OK with this text. I tried to come up with a way to briefly discuss how error detection is very related to things like protecting against substitution of content (the internet mirror case) but failed to come up with something brief. So, I'm fine with what you have. Martin The use of MD5 _is_ a security problem in integrity Martin protection scenarios. Agreed. My point was close but not identical to yours. My point was that even when you think you're just talking about error detection, it takes effort to tell whether you are really talking about error detection (OK) or integrity protection (not OK). Martin When used for checksums when mirroring sites, a Martin contributor could precompute a collision for a file he Martin contributed in order to perform an MITM attack on specific Martin downloads (substituting a trojaned package with the same Martin md5sum into the download while leaving the file on the Martin Download servers clean. An excellent point! In my original long message on this topic I pointed out that if the checksums are ever separated from the file then you're talking about integrity protection not error detection in most threat models. I was thinking of the case where you have a mastersite listing checksums and a bunch of mirror sites. (That is, the checksums in something like a Debian Packages file are very much integrity checksums not just error detection checksums; there's a reason we no longer rely on MD5.) However you point out that even if there is only one site, when there can be separation--even after the fact--then MD5 may be problematic. Some threat models may reject the case where the original distributor performs a precomputation attack, but for other threat models, this is a realistic attack. After this discussion, I continue to believe that determining whether a particular use of MD5 is safe is quite tricky. Therefore, it is very reasonable to ask that the security assumptions be described and analyzed. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-turner-md5-seccon-update-07.txt (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC
I'm OK with this text. I tried to come up with a way to briefly discuss how error detection is very related to things like protecting against substitution of content (the internet mirror case) but failed to come up with something brief. So, I'm fine with what you have. --Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-turner-md5-seccon-update-07.txt (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC
Francis == Francis Dupont francis.dup...@fdupont.fr writes: Francis In your previous mail you wrote: FrancisI'm OK with this text. I tried to come up with a way to Francis briefly discuss how error detection is very related to Francis things like protecting against substitution of content (the Francis internet mirror case) but failed to come up with something Francis brief. So, I'm fine with what you have. Francis = can I conclude you are in the they are security Francis considerations so don't talk about not-security uses side? No. Especially for something like md5 you need to talk about it enough so that we can evaluate whether it's actually a security use or not. I sent a moderately long message to the ietf list about this. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-isis-trill
Radia == Radia Perlman radiaperl...@gmail.com writes: Radia No objections. Radia Can I get someone to confirm that the text in the proposed sentences is substantially true? I think so but I'm not an IS-IS expert. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-isis-trill
Donald == Donald Eastlake d3e...@gmail.com writes: Donald Hi, Donald On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman hartmans-i...@mit.edu wrote: Radia == Radia Perlman radiaperl...@gmail.com writes: Â Â Radia No objections. Â Radia Can I get someone to confirm that the text in the proposed sentences is substantially true? I think so but I'm not an IS-IS expert. Donald LSPs have sequences number, etc., and are idempotent. I Donald think only Hellos have the potential replay Denial of Donald Service problem. So I would suggest changing to: Donald Even when the IS-IS authentication is used, replays of Donald Hello packets can create denial-of-service conditaions; see Donald RFC 6039 for details. These issues are similar in scope to Donald those discussed in section 6.2 of Donald draft-ietf-trill-rbridge-protocol, and the same mitigations Donald may apply. Based on my understanding your correction is accurate; thanks. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Secdir review of draft-ietf-isis-trill
Hi. I've been asked by the trill authors to clarify what I meant by my secdir review. That's certainly fair. I think there are two issues. The first is that I think that draft-ietf-isis-trill does an adequate job of discussing the security implications of IS-IS on trill. I've read the security considerations section of draft-ietf-trill-rbridge-protocol and I think it doesn't do so either. However, it comes very close. If I understand Is-IS security correctly, the only attack that we would expect a routing protocol to deal with that it does not is replays. (IS-Is is no worse than anything else here.) The impact of replays is a denial of service. If I'm understanding section 6.2 of draft-ietf-trill-rbridge-protocol correctly, similar denial of service attacks are also possible with trill-specific messages. If my understanding of the impact of IS-IS security (even with authentication) is sufficient, I think this concern could be addressed by adding a sentence to the security considerations section of draft-ietf-isis-trill saying something like Even when the IS-IS authentication is used, replays of IS-IS packets can create denial-of-service conditaions; see RFC 6039 for details. These issues are similar in scope to those discussed in section 6.2 of draft-ietf-trill-rbridge-protocol, and the same mitigations may apply. I have a second large issue with the way we've handled trill. First I'd like to compliment the authors of draft-ietf-trill-rbridge-protocol, particularly on the security considerations section, but the document quality of other sections of that document I've looked at is high. They've done a good job of describing what they've done and as far as I can tell delivering what they've said they would deliver. However, something went wrong somewhere. We have some standards that we've agreed to as a community for the security of new work we do. It's my opinion that trill does not meet those standards. The document doesn't claim it does. I think that was wrong, however the mistake was in the review of RFC 5556 (the TRILL problem statement), which clearly sets out what TRILL was going to do. I believe I was on the IESG at a time when that document was reviewed, so I especially don't have room to complain here. So, actually even were I on the IESG, I would not hold up the protocol over this issue. Looking forward to future work, though, I think we should be more consistent about applying our community standards to work we charter. If those standards are wrong, let's revise them. No, TRILL should not have been forced to solve the ethernet control plane security problem. However TRILL should have had a security mechanism that meets current standards so that when the ethernet control plane is updated TRILL never ends up being the weakest link. As best I can tell, TRILL does meet the security goals stated in its problem statement. Also, my comment about document quality was never intended to be blocking. While I don't believe draft-ietf-isis-trill is of as high quality as draft-ietf-trill-rbridge-protocol, I did manage to understand it without the rbridge-protocol document. The authors claim that should not be requried; I think if I had looked at the rbridge-protocol document first I would have concluded that it was more clear than isis-trill, although I think it's also true that I would have been less bothered. Either way, I did manage to follow both documents. --Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Secdir review of draft-ietf-isis-trill
Adrian == Adrian Farrel adrian.far...@huawei.com writes: Adrian Sam, Thanks for your work. Adrian Can I clarify. You wrote: The first is that I think that draft-ietf-isis-trill does an adequate job of discussing the security implications of IS-IS on trill. I've read the security considerations section of draft-ietf-trill-rbridge-protocol and I think it doesn't do so either. Adrian I you have one positive and one negative statement. I think Adrian you meant them to both be negative. Perhaps you could Adrian confirm. You are correct. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Secdir review of draft-ietf-isis-trill
Erik == Erik Nordmark nordm...@acm.org writes: Erik Adding just this sentence to draft-ietf-isis-trill (the code Erik point document) seems odd. Your comment is really a comment on Erik the security of IS-IS, and not specific to TRILL and unrelated Erik to the code points. I don't care much where the text goes. I'm happy if you provide an rfc editor note for draft-ietf-trill-rbridge-protocol if you like that approach better. However, as I read draft-ietf-isis-trill, it defines the interface between TRILL and IS-IS. In my mind, that's where the security consideration appears. You're re-using a component that isn't up to our current standards--we know that; we're working on it in KARP. However in doing that, you need to document the security considerations for your protocol. Since you have a document that specifically is the interface between your protocol and the component you are re-using,that seems like the best place to do the documentation work. however, in decreasing order of priority, I want to call out my concern that we need to be far more careful about what we expect in terms of security from future work we charter and that we should document the specific interactions between IS-IS and TRILL. While I have expressed an opinion above on where I think that documentation should go, feel free to put it where you think is most correct. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Secdir review of draft-ietf-isis-trill
Please treat these as normal last call comments. I found the introduction to draft-ietf-isis-trill inadequate. I'm familiar with the base concepts behind TRILL, roughly understand what was going on and followed the chartering discussions of the WG fairly closely. I have read the requirements document but have not read the protocol document. In an ideal world this document would be significantly easier to follow; I suspect that after reading the protocol document I'd still find this a bit choppy. However, I understand that sometimes you can only spend so much time on a spec and sometimes you reach the point where if someone isn't willing to jump in and volunteer a lot of hours to add clarity, good enough is good enough. This document claims that it adds no new security considerations to IS-IS. That's true. However, TRILL is a new protocol--completely new. It re-uses IS-IS as a building block, but if I were a security AD I'd still insist that TRILL meet our current standards for security, including a strong mandatory-to-implement security mechanism and (where appropriate) automated key management. I definitely think that this specification should at least document how IS-IS+TRILL fall short of standards we'd require for a new protocol today. The big area I can think of is replay handling for hello packets, which I suspect leads to a DOS. If we had more success with multicast key management we'd probably also require automated key management for a protocol like this. However,we don't, so I think that the RFC 4107 analysis would conclude that manual key management is acceptable under the multicast exception. I suspect the sec ADs will not actually require a solution even though it is a new protocol. I think that's a mistake, but I also don't have a lot of time to spend on TRILL, and I'd definitely rather see it get published than bogged down. I think documenting how IS-IS security interacts with TRILL security and IETF security BCPs should only take a relatively short time. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-turner-md5-seccon-update-07.txt (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC
So, I'm sympathetic to the idea that we in the security community can be overly paranoid. however I'm more sympathetic to the idea that it's hard to figure out what uses are security sensitive and what uses are not. At least in the case of md5, where backward compatibility concerns don't dictate otherwise, I'd say that moving away is better than not. Let me take a specific example from earlier in this discussion. The claim was made that using md5 to verify the checksum of ISOs downloaded off the Internet is still good. That depends entirely on what you're trying to protect against. If your concern is simply errors in the download and concerns that the TCP checksum may be inadequate, then I agree. However it's also fairly common to have md5 checksums on an initial page and then direct people to mirrors for the actual ISO. There, you're also protecting against substitution attacks mounted between the original page and the iso. If md5 is used in exactly the same context as the data, I agree it is still fine. However, the moment you separate the checksum from the data--by putting one in e-mail, one on a post-it note, one on a different mirror, you have made the hash security sensitive. For this specific use, I think the extra length of SHA-1 is worth it, and I think it is reasonable for us to recommend that something stronger than MD5 is appropriate. (SHA-2 would be better, although the length of SHA-2 starts to get prohibitive.) It's very easy for the security of a hash function to become important. I at least find it difficult to easily determine whether a particular use of a hash is security sensitive. I find that I disagree with the results from people who claim that this analysis is easy often enough that I'm reluctant to conclude that I'm simply unusually slow at thinking through these sorts of issues. So, I suggest that the problem of deciding whether the security of a hash is important may be a bit tricky. While we should not spread panic and we should be sensitive to these issues, I also would rather us err on the side of security in our recommendation. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The Evils of Informational RFC's
Bob == Bob Braden bra...@isi.edu writes: Bob On 9/8/2010 3:12 PM, Richard Bennett wrote: It seems to me that one of the issues here is that architecture models are published as Informational when they're clearly not in the same level of authority as most Informational RFCs. An architecture document is meant to guide future work on standards track RFCs, and has been regarded historically as more or less binding. Bob ...guide future work on standards track RFCs -- yes. Bob ...historically as more or less binding -- no. Bob, this was certainly an issue that came up when I was on the IESG. At that time, we definitely felt that there were some architectural decisions that the community as a whole had bought into. We believed that departing from such a decision was something that the community as a whole needed to revisit. For example, when a WG was chartered to work on an architecture after the architecture document was approved, it seemed fairly clear that the community had expressed a desire to have a chance to look at that architecture. Other times, however, it seemed to us that a requirements document or architecture document represented the thinking within a single working group. There, it didn't seem like departing from this guidance required as much community review. I'm summarizing a fair bit of discussions, but enough different prospectives and examples were brought into the discussion that I feel confident that while we don't know how large the sample size was, it was more than just that IESG who believed there are times when architecture documents are intended to bind. I know I've often found the informational RFC label inadequate to describe this sort of distinction and found that this distinction is important to capture. --Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Attendance by continent
Noel == Noel Chiappa j...@mercury.lcs.mit.edu writes: I suspect that a more nuanced analysis would have this as 1.7 and shrinking : 1 and stable : 1 and stable. Noel and his conclusion: I would support 2:1:1 for the present, with an intention to review that in 2-3 years. Noel seems to me to be right on, given those 1.7:1:1 numbers - 1.7 is closer to 2 Noel than it is to 1... +1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Attendance by continent
Bob == Bob Hinden bob.hin...@gmail.com writes: Bob A question for you. Should we select meeting venues to Bob minimize the cost/time/etc. of all attendees or just, for Bob example, w.g. chairs? Many people have suggested that the IAOC Bob should be looking at overall attendee costs, but there might be Bob a difference in what group we try to optimize. Bob Personally, I lean toward more openness and would prefer to do Bob optimize for all attendees. I think fairly strongly we should be optimizing for those doing active work in the IETF. Yes, that means that people who wish to get started in the IETF will face a higher bar in terms of meeting costs. In my mind that's OK, they will face a higher bar on a number of other fronts as well. We have a defined mission statement; it's my belief that the best way to accomplish that is to optimize for those who are doing the work while being sufficiently open that people who are willing to spend some effort can get involved. Put another way, we've already decided on our long-term success criteria: high quality specs. If you propose to change what we do in this space, you should make an argument about why what you're doing is the best option for advancing that long-term goal. I believe optimizing for the participants is the best long-term goal because it maximizes the probability that the people doing the work of the IETF are available to take advantage of the face-to-face discussions. It is important not to go so far as to prevent people from joining so that new work can filter into the system. --Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] secdir review of draft-ietf-msec-ipsec-group-counter-modes
Brian == Brian Weis b...@cisco.com writes: Brian There is an I-D for one GKMS (draft-ietf-msec-gdoi-update-06) Brian that includes support for SIDs which could be referenced. It Brian is expected to head to WGLC soon. Would citing that document Brian address your concern? A normative reference to that would definitely address my concern. An informative reference would not. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review of draft-ietf-msec-ipsec-group-counter-modes
This is a secdir review of the above draft. The text looks fine. However, I'm concerned that this specification does not provide sufficient detail for interoperable implementation. It makes it clear that a GKMS needs to allocate SIDs but does not cite any mechanism for a GKMS to do so. I think you need to either add a normative reference to a hopefully already existing description of how to distribute this parameter, or recast this document as an informational document describing a general method but not implementing a protocol. ___ 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
Recently I've tried to use draft-ietf-kitten-gssapi-naming-exts in the design of a GSS-API mechanism. I think this is a good start but is not quite done yet. draft-hartman-gss-eap-naming-00 discusses a couple of problems with naming extensions: * The format of attribute names proposed in this specification is incompatible with several of the things you'd like to name, in my case including SAML attributes. * The description of how to name SAML attributes currently in the document is inconsistent with the SAML base specification * The approach of naming things like SAML attributes entirely with a * The approach of letting a mechanism create authenticated attributes with an arbitrary URI makes the application's life really hard While not mentioned in my existing draft, I've noticed a number of other problems: * The document claims to name Kerberos entities such as authorization data elements but does not actually provide a name for them. * The document does not discuss the encoding of subjectAlternativeName elements. I suspect application authors will assume human-readable text and PKI folks will assume DER. In addition, there is no way to get the identity of the issuer of a name attribute. I've discussed these concerns with one of the authors, Nico Williams. I have also requested time to present my concerns at the kitten meeting at IETF 78. I'm happy to help resolve these concerns up to and including becoming an author of the document and writing significant text. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
Iljitsch == Iljitsch van Beijnum iljit...@muada.com writes: Iljitsch On 7 jul 2010, at 17:23, John Morris wrote: Well, as someone who believes that *all* websites and online-operating organizations should have a clear and accessible privacy policy, I think it is beyond embarrassing that the IETF does not have one. Iljitsch The IETF got along without one for two decades just fine. Generally when I look for an idea of whether work is a good idea I look for a clear statement of benefit. I'll admit that I don't find privacy policies so valuable that I think everyone should have one. So, I'll ask how will or work be improved or what problem are we running into that a privacy policy will solve? If that cannot clearly we be answered, we should not engage in this activity. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
Ole == Ole Jacobsen o...@cisco.com writes: Ole Sam, Ole I view this more or less as standard boilerplate, something Ole you find in a lot of online places. I think it is reasonable Ole to expect that if you register for a meeting your personal info Ole (e-mail address mostly) won't be sold/used/harvested by someone Ole for purposes other than what you think you signed up for. It's Ole probably useful for us to have such a statement. I agree with the above. however, the above doesn't sound like a compelling justification to develop or review such a statement--just a reason why we wouldn't mind having one. For the development cost, I don't care if people who want such a statement go off and build one. however, at least the IAOC has to review it. I don't think that the above justification is sufficient to place the review very high on the priority list, nor do I think that in this instance the fact that someone goes and spends time developing it should raise the review priority. If the IAOC believes it needs to suck the rest of us into a review, I think that pushes the priority even lower. Now, there are things that in my mind would push the priority up: * The IAOC isn't sure whether to use information in some way * The community and IAOC disagree about how information is being used * Something else ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
John == John Morris jmorris-li...@cdt.org writes: John Paul, Sam, I understand your arguments to bascially be we've John never had an internal privacy problem here at the IETF, and as John far as I know no one decides not to participate because of the John lack of a privacy policy, so we have no need to follow basic John standards of privacy hygiene. This is not an accurate characterization of my argument. I substantially agree with Paul's message in response. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Federated Authentication BOF at IETF 78
Hi. I'd like to announce that there will be a BOF on federated authentication beyond the web at IETF 78. we'd like to form a working group to standardize protocols for federated access to applications that are not browser based. Targets include think client applications and some machine-to-machine authentication use cases. At this point we have not focused on requirements imposed by RAI applications. You can see draft specs at http://www.project-moonshot.org/specifications There is a BOF agenda at http://www.project-moonshot.org/bof/agenda We encourage you to join our mailing list, see http://jiscmail.ac.uk/cgi-bin/webadmin?LIST=MOONSHOT-COMMUNITY . To the extent we're able we'd love to collect comments or things people will want to discuss at the BOF now. Hopefully we can get as much as possible out of the way on the list and have a very productive session! We hope to see you there. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [newprep] WG Review: Stringprep after IDNA2008 WG (newprep)
Alexey == Alexey Melnikov alexey.melni...@isode.com writes: Alexey Sam Hartman wrote: Jiankang == Jiankang YAO ya...@cnnic.cn writes: Jiankang If there are many things we must do, we(WGs) normally Jiankang prioritize the things. sometimes, the easier one first; Jiankang sometimes, the difficult one first. Sure. That's fine for the WG to do. I don't think it is good to do in the charter without some fairness criteria. All items brought up by the time external review of the charter concluded seems like a reasonable fairness criteria. Putting the cutoff before that seems unreasonable. Obviously, the WG can internally prioritize (and change its priorities) within its normal administrative processes. Jiankang If peter's list is not ok for you, could you kindly give Jiankang us your list? The list in the charter plus: 1) Considering Kerberos implications for SASLPREP revisions Alexey Sam, I think this is granted. I don't think this needs to be Alexey written into the charter, especially considering that there Alexey is a good deal of overlap between people active in Kerberos Alexey and SASL WGs. I'm totally happy with that interpretation. 2) Considering RFC 4282. Alexey Do you consider RFC 4282 to be a stringprep profile? My Alexey quick scan of the document (in particular Section 2.4) is Alexey not conclusive. It's my read that section 2.4 invokes all of toascii from IDNA 2003, which definitely implies stringprep under the covers. However, I think the spec is kind of broken both for IDNA2003 and IDNA2008; if you take a look at the proposed erata aspects of the AAA community agree. The solution is probably not going to be a stringprep profile, although the solution is probably not going to be any more complicated than something like XMPP's solution. However, I definitely think the AAA community needs to have some internationalization experts to talk to in order to have a chance of success. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [newprep] WG Review: Stringprep after IDNA2008 WG (newprep)
Jiankang == Jiankang YAO ya...@cnnic.cn writes: Jiankang If there are many things we must do, we(WGs) normally Jiankang prioritize the things. sometimes, the easier one first; Jiankang sometimes, the difficult one first. Sure. That's fine for the WG to do. I don't think it is good to do in the charter without some fairness Jiankang criteria. All items brought up by the time external review of the charter Jiankang concluded seems like a reasonable fairness criteria. Putting the cutoff before that seems unreasonable. Obviously, the WG can internally prioritize (and change its priorities) within its normal administrative processes. Jiankang If peter's list is not ok for you, could you kindly give Jiankang us your list? The list in the charter plus: 1) Considering Kerberos implications for SASLPREP revisions 2) Considering RFC 4282. Both of these are stringprep issues. Kerberos has been intending to use SASLPREP; if you revise SASLPREP without considering what happens for Kerberos, then you'll just end up revising it yet again later. NAIs seem to use more of the IDNA2003 rules than just the IDNA 2003 stringprep profile, but they do use that profile as well. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed IAOC Administrative Procedures
IETF == IETF Administrative Director i...@ietf.org writes: IETF 9. Members shall at all times act in a disinterested manner IETF and consider only the benefit to the IETF standards process IETF and community as a whole in discussions and decisions. The IETF Members shall promptly disclose any material conflict of IETF interest and recuse themselves from related decisions. This seems kind of weak to me. In particular , members are not required to make a statement of interests that might potentially become conflicts when they join the IAOC. In addition, it seems like members are only encouraged to discuss a conflict when it reaches a point where they must recuse. I'd recommend amending this to: 1) Require members to make a statement of their interests when they join the IAOC or whenever the contents of their statement would materially change. Specific wording is tricky here, except that a small Google search reveals that at least a ]statement of financial interests is very common and we have many examples of policies to draw from that require such statements. 2) Members should be encouraged to ask other members if a particular issue raises conflicts that might fall within that member's stated interests. 3) Members are encouraged to discuss their own questions about whether they have a conflict with the chair or the IAOC as a whole. I think that without these or similar changes the policy is not strong enough to meet standards our community should require of leaders charged with financial matters for the organization. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [newprep] WG Review: Stringprep after IDNA2008 WG (newprep)
Peter == Peter Saint-Andre stpe...@stpeter.im writes: Peter On 5/19/10 12:36 PM, Sam Hartman wrote: I believe that without explicitly listing the use cases I've brought up in the body of the charter, the additional paragraph Peter I proposed: PeterAlthough the group will seek input from and may provide Peter advice to customers working on other technologies, it will Peter prioritize work on the above-listed stringprep profiles and Peter will take on additional tasks as official milestones only Peter after rechartering. I am actually fine with this if you note in the above text that Kerberos needs to be considered when considering SASLPREP and explicitly add RFC 4282. What I'm objecting to is prioritizing the list of stringprep profiles you've identified to other stringprep profiles that came up during the discussion of the charter. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [newprep] WG Review: Stringprep after IDNA2008 WG (newprep)
I believe that without explicitly listing the use cases I've brought up in the body of the charter, the additional paragraph would be a significant step backward. I would object to chartering the group with that paragraph added without explicitly listing any use cases including the onse I brought up that have come forward in this discussion. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Stringprep after IDNA2008 WG (newprep)
Hi. I think there are two items that should be considered with the scope of this working grou. The first is RFC 4282. RFC 4282 section 2.4 discusses internationalization strategies based on stringprep and IDNA2003. It does not define its own profile. Apparently, in addition to all the reasons you would probably want to update anything based on IDNA 2003, RFC 4282 does not meet the needs of the implementor community. One proposal for addressing RFC 4282 is draft-dekok-radext-nai-01.txt I think any proposal in this space will require both help from newprep and from the radext/aaa community. Based on my past experience in emu, the aaa community, like the rest of the IETF, can use i18n help. Secondly, I'd like to see Kerberos considered as newprep thinks about saslprep. Kerberos's formal internationalization is confused and spotty as a specification level. At the last time that there was active work on this within krb-wg, the plan was to use saslprep; a prior stringprep profile was explicitly dropped in favor of saslprep. For this reason, I think that considering and working with the Kerberos community would be really useful. I'm not sure if either of these needs an explicit charter change; I suspect the first probably does and the second may not. However I think these both are well within the spirit of the proposed charter. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [newprep] WG Review: Stringprep after IDNA2008 WG (newprep)
Marc == Marc Blanchet marc.blanc...@viagenie.ca writes: Marc we had a discussion about the same subject: i.e. should we Marc restrict the scope to a specific set of documents to Marc review/update/... or do we keep some provision for other Marc documents coming in the stream that require help of the Marc newprep. I was arguing for the latter. To me, what you are Marc talking about is the latter. Obviously, some people wanted the Marc charter to be restrictive in order to not go all over the Marc place, and I agree in principle... However, this work is kinda Marc horizontal: touches many areas, so having a more large view of Marc the problem space and documents that depends on this newprep Marc work would be very valuable to the working group Marc work. Therefore, I'm more for opening a bit the charter for Marc the cases like the ones you are talking about. I'm happy with a restrictive charter so long as the work areas identified today (including mine) are included. I'm happy drawing a line in the sand and saying here's what we'll touch first, so long as people who bring up items now get included. I'd probably be happier with a reasonably open charter. I'm not at all happy if the items I bring up or other similar items brought up now are excluded. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: Policy Statement on the Day Pass Experiment
I fairly strongly support the IESG's proposed policy statement on the day pass experiment. I specifically belive that it is counter to our ability to fund our ongoing activities to turn the day pass experiment into a way to reduce the cost of attending IETF on an ongoing basis. We want to do what we can to keep the day pass as a mechanism for bringing in new people and discourage its use for existing participants who want to save a buck. (This from someone whose last few IETFs have been self-funded.) I agree with the IESG's reasoning that members who have not committed to the IETF on an ongoing basis don't make good nomcom members. For these and other reasons I support the IESG's statement. ___ 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
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. --Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Federated Authentication Discussion Tonight at 9 PM in Manhattan room
Folks, I'm looking forward to seeing some of you at the bar bof on federated authentication for non-web applications this evening at 9 PM in the Manhattan room. Please see http://www.painless-security.com/blog/2010/03/25/moonshot3 for a detailed reading list and remote participation instructions. All the material has been sent out previously but I've collected it all into one place for your convenience. We'll be using the moons...@conference.jabber.postel.org chat room and channel 6 on the audio streaming. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review/last call comments for : draft-ogud-iana-protocol-maintenance-words
I have been assigned this draft as part of the secdir review process. I see no security issues with the draft that are really within the scope of a secdir review. I do have significant concerns I'd like to raise as last call comments. In general, I agree with most of the concerns raised about this draft. I believe that an applicability statement is the appropriate way to address what this draft is trying to do. If you're looking to make a process change how about writing a simple proposal for allowing IANA registries to reference applicability statements that describe protocols they cover. You might have a note like For current status of the implementation requirements for these algorithms in dnssec, se RFC xyzzy. The applicability statement could say which registries it links to, and could remove the links of statements it obsoletes. I realize that's somewhat going down the path of including unnecessary information in a registry, but I think it is a reasonable compromise until/unless something broader like ISDs come along. Also, by all means try to put together an ISD-like proposal if you have the energy. I'm one of the people who thought that the last ISD proposal was not sufficiently specified and might run into fundamental problems, but thought there were some really good ideas there, so if you do go down that route I'd be happy to share some concerns while remaining constructive. Stunningly, given the concerns raised so far, I think I have some new ones. First, this draft attempts to establish operational requirements. The term operational requirements is not well defined. In the context of DNSsec, we can imagine what that might mean: zone operators need to use one of the mandatory algorithms to sign their zones in order to guarantee that others can validate it. Especially for Internet-wide protocols it is often appropriate to have best-current-practice recommendations for the operational deployment of those protocols. We have groups like gro and dnsop that develop such recommendations. For other protocols this makes no sense at all. In the past I've worked on VPN deployments for clients. Those clients chose algorithms that were right for their environments. IF within that environment they happened to choose a protocol that was not labeled as MANDATORY by an IANA registry, that's totally fine. Neither the IETF nor the IANA has a good reason to tell people what IPsec algorithms they need to use in their operational environment, nor even what algorithms must be enabled in a given configuration. If we try, we will be ignored. This draft conflates implementation requirements with operations requirements. In many cases we SHOULD NOT specify operations requirements. In other cases, there is no reason to be sure that the implementation and operations requirements will be the same. Others have pointed out the broken definition of mandatory. The definition at the top of 3.1 provides an escape and makes MANDATORY much like SHOULD. However the explanation for what it means for implementations and operations provides no such escape. There is a lack of alignment between the implementation requirement and operations requirement for obsolete: if I'm starting to phase something out, it is too early to say SHOULD NOT implement. This draft fails to adequately describe its relationship to RFC 2119. When should I use MUST? When should I use MANDATORY? Why do I need both? If you're going to introduce new terms, you need to clearly specify their applicability. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
I'll say that I'm in category c: the format issue matters a lot to me and I prefer the status quo. Changing the format issue is difficult, people who want to change it routinely ignore some of the issues, and neither side participates in a constructive discussion. The status quo is acceptable and we could do far worse. Phil I cannot imagine being insulted by a document format, but I feel very uncomfortable with a change being lead by a group of people that feel that strongly. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on appeal to the IESG concerning the approbation of the IDNA2008 document set.
Andrew == Andrew Sullivan a...@shinkuro.com writes: Andrew On Fri, Mar 12, 2010 at 09:02:53AM +1300, Brian E Carpenter wrote: That seems to cover most angles. I can't see why the IESG could be expected to add technical disclaimers to a consensus document. In fact, doing so would probably be a process violation in itself. Andrew Well, ok, and yes it probably would be a violation. But to Andrew defend the appelant, there might be a serious (though in my Andrew view totally wrong) point in the appeal. For what it's worth, I think it is entirely reasonable for the IESG to add text raising technical concerns to a consensus document. The IESG note, unlike the rest of the document reflects IESG consensus, even in cases where the document is intended to reflect IETF consensus. Here's a case where I think it would be entirely appropriate for the IESG to do so. The current process--both internal IESG procedure and RFC 2026 requires some level of agreement from the IESG to publish a document. If we had a case where it was clear that there was strong community support for something that the IESG had serious concerns about, I think it would be far bettor for the IESG to include its concerns in an IESG note than to trigger a governance problem by declining the document. Another option also open to the IESG would be to write up its concerns in an informational document published later. Without knowledge of specifics I cannot comment on which I'd favor. I have not read the current appeal and doubt that adding an IESG note is the right solution to an appeal on technical grounds about a consensus document. I simply don't want a legitimate case where adding an IESG note to come up years later and people dig through this discussion and find no objections to the claim that adding such a note would be a process violation. --Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Bar Bof on Federated Authentication Thursday at 9 PM during IETF week
Folks, I'm trying to get a room for the federated authentication bar BOF Thursday March 25 at 9 PM US Pacific time I've requested a room from the secretariat and Pasi said he would approve the request, so we'll see what their availability is. I plan on starting out with a brief presentation on the problem and solution architecture I'm working with, then we'll open it up to discussion. The goal of the discussion will be to determine if there is sufficient interest to have a BOF at the next IETF and to understand what steps we need to take between now and then. For the announcement of the proposal see http://www.ietf.org/mail-archive/web/emu/current/msg01363.html and for our mailing list see http://jiscmail.ac.uk/cgi-bin/webadmin?LIST=MOONSHOT-COMMUNITY Thanks for your interest, Sam Hartman Painless Security, LLC ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication Using Only A Password) to Informational RFC
Glen, I have to agree with Dorothy's comment. This method should provide for channel binding support. I find your unsubstantiated assertion that doing so wouldbe be absurd uncompelling. You claim that channel bindings are poorly defined. I believe that draft-ietf-emu-chbind brings us most if not all of the way there for some important use cases. However if you take a look at that draft, you'll find that it's a lot better defined for the case where an EAP method will transport the channel binding than for the case where a secure association protocol is used. In particular: 1) The secure association protocol by its nature happens after the access-accept. I've already started a session--told the peer to go ahead with things before channel binding can be confirmed. It's not clear in existing secure association protocols where the EAP server gets to interact with the peer again in order to tell it that channel binding verification has failed. So, it is unclear that the primary purpose of channel binding can be performed in this case. 2) The document does not define sufficient messaging to community with an AAA server to perform channel binding in a secure association protocol. So, basically, I think for channel binding to work it needs to be available in the method. Moreover, whether channel binding is critical in a given deployment is not actually dependent on whether the methods used in that deployment. It's dependent on whether a deployment has multiple situations where a peer could be significantly disadvantaged by authenticating to the wrong NAS. So, I cannot see good criteria for deciding when to add channel binding and when not to add channel binding to new proposed methods. Certainly, part of this is that I'm working on an EAP deployment where channel binding is absolutely critical to the security of the environment. Especially since I don't see how to actually make it work with a secure association protocol, I'm strongly in favor of a requirement to support channel binding in new methods. --Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Proposed bar BOF on federated authentication for non-web applications at IETF 77
I've been working with JaNet(UK) on providing a federation solution for client applications such as mail readers, filesystem clients, XMPP clients and the like. There are fairly good solutions such as Open ID, Information Card and SAML for web applications. Within an enterprise, you have Kerberos. JaNet(UK) runs one of the world's largest SAML federations. As their customers are beginning to take advantage of federated access for web applications they are also asking how they can gain the same flexibility for client-server applications. This customer demand appears to have traction across the entire European academic community. I suspect that it may find traction within enterprises and other environments. We'd like to have a bar BOF at IETF 77 in California with a goal of an actual BOF this summer in Europe at IETF 78. We invite you to join our mailing list at https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=moonshot-community where we can discuss timing. We plan to discuss the general problem and a proposed solution at the bar BOF. I've already prepared a feasibility analysis for JaNet(UK)'s solution; the analysis does discuss the problem some, gives an outline of the solution and discusses technical issues and required standards work in detail. By IETF we'll have a use case paper, an internet draft on the solution,and a slide set. we look forward to your input. You can find a bit more detail on my blog at http://www.painless-security.com/blog/2010/02/12/moonshot1 You can find the feasibility analysis at http://www.painless-security.com/wp/wp-content/uploads/2010/02/moonshot-feasibility-analysis.pdf Thanks, Sam Hartman Painless Security ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [codec] WG Review: Internet Wideband Audio Codec (codec)
Peter == Peter Saint-Andre stpe...@stpeter.im writes: Peter On 1/7/10 9:46 AM, Russ Housley wrote: Andy: Although this preference cannot guarantee that the working group will produce an unencumbered codec, the working group shall attempt to adhere to the spirit of BCP 79. This preference does not explicitly rule out the possibility of adapting encumbered technologies; such decisions will be made in accordance with the rough consensus of the working group. I appreciate the potential difficulty of guaranteeing the unencumbered status of any output of this group. However, I would like this statement to be stronger, saying that this group will only produce a new codec if it is strongly believed by WG rough consensus to either be unencumbered, or freely licensed by the IPR holder(s), if any. I do not think that anyone wants the outcome to be yet another encumbered codec. I think these words are trying to say what you want, but they are also trying to be realistic. Does the following text strike a better balance? Although this preference cannot guarantee that the working group will produce an unencumbered codec, the working group shall follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adapting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties. I agree with the concerns that Stephan expressed. Royalties are only one source of significant problems. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Internet Wideband Audio Codec (codec)
Roni == Roni Even ron.even@gmail.com writes: Roni Hi, I do not think that the IETF should accept any work Roni because people want to do it, if this is the case a group of Roni people can come and ask to start working on any idea they have Roni that has some relation to the Internet. IETF should accept Roni work that is in scope for of the IETF and for which there is Roni enough knowledge to evaluate the work by the participants. I agree. It's quite clear to me that when I read the mission statement of the IETF, this is in scope. My personal belief is that we have or by chartering this work will obtain the necessary experts to evaluate the results. What area this belongs in seems an excellent question for the IESG. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-reverse-servers (Nameservers for IPv4 and IPv6 Reverse Zones) to Proposed Standard
Olafur == Olafur Gudmundsson o...@ogud.com writes: Olafur There is one case where knowledge and special handling of Olafur the name may cause problems: DNS Liers i.e. specialized Olafur DNS resolvers that make all non-existing name exist that do Olafur not generate lie for sink.arpa. Olafur In this case the name can not be used as test of the Olafur resolvers truthful ness. If an application knows about the Olafur name that is not a problem as all that will do is to avoid a Olafur name lookup, and this is exactly the reason we want the name Olafur to be have explicit semantics that can not change and are Olafur under IETF/IAB control not ICANN's. I cannot parse the above. I cannot tell whether you are saying that those who wish to monatize Olafur DNS error traffic (which I believe is part of the tag line Olafur for a popular such service) should or should not return a Olafur result for sink.arpa. Nor can I tell whether you're saying they will do so. I'm quite certain that if someone's business model depends on violating this specification that they will do so. It sounds like you're saying that you want a name to use to test and see if you are getting bogus DNS responses but you're not willing to say that in a spec. If so, I think this will be ultimately ineffective and I think it is misleading to publish a spec without explaining what it's good for. In summary, I'm not strongly objecting. However I do continue to feel that a clear explanation of what's going on here is not being provided and that the uses as I understand them seem ineffective. However this clearly falls into the category of mostly harmless. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Internet Wideband Audio Codec (codec)
I've been thinking about the codec issue for a while. I think it is really desirable for the IETF to charter this group. I don't think the charter should prohibit the working group from selecting some existing codec nor should it prohibit doing new work in this space. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-reverse-servers (Nameservers for IPv4 and IPv6 Reverse Zones) to Proposed Standard
I'm not really particularly happy with Joe's two recent DNS drafts. They give me the impression as a reader that a lot of context is being hidden from me and that the implications of the draft are being carefully obscured so that I as a reviewer not involved in the process won't know what is going on. I suspect the actual cause has more to do with preventing arguments about goals when mechanisms can be agreed to or writing minimal drafts. However I find the documents difficult to review; I do not consider that a good thing. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-jabley-reverse-servers (Nameservers for IPv4 and IPv6 Reverse Zones) to Proposed Standard
Joe == Joe Abley jab...@hopcount.ca writes: Joe On 2010-01-04, at 14:43, Sam Hartman wrote: I'm not really particularly happy with Joe's two recent DNS drafts. Joe If I can help clarify anything, please let me know. So, I think John is asking the questions well about the in-addr.arpa plan. For the sink.arpa, it would be good to explain why we want this name to exist. Also, if your goal is that applications not have special logic for sink.arpa you should *say* that: I read the draft assuming that it was free license to applications to start doing special things with that name and was starting to put together lists trying to figure out what special application semantics motivated the work. I do believe both sets of questions should be answered in the drafts. I don't feel that strongly about it though; if the IESG would rather not, that's fine with me. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Announcement of the new Trust Legal Provisions (TLP 4.0)
Julian == Julian Reschke julian.resc...@gmx.de writes: Julian Marshall Eubanks wrote: ... This message is to announce that the IETF Trustees have adopted on a new version of the Trust Legal Provisions (TLP), to be effective 28 December, 2009. The Grace period for old-boilerplate will begin on that date, and last through 1 February, 2010. ... Julian So, unless xml2rfc gets updated in time, people using that Julian tool won't be able to submit Internet Drafts after February Julian 1 without additional post-processing? Why the early cut-over Julian date, compared to the last change (which had a 2+ month Julian transition period) I'd like to take this a step further: why do we need to update our boiler plate at all? It's my understanding that the incoming rights have not been changed at all here; that should and I think does require a BCP. The trust is updating what rights they give others outside the IETF process. I guess Ic can see why that might affect the boiler plate the RFC editor uses. However, I don't understand why I as an internet draft author should have to join the boiler plate of the month club. I thought one reason we set up the inbound vs outbound split was to avoid exactly this sort of mess. --Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Most bogus news story of the week
Richard == Richard L Barnes rbar...@bbn.com writes: Richard Here's (what the ITU claims is) the specific proposal that Richard has been made to the ITU: An ITU spokesman said: The ITU Richard has no plans to modify the BGP protocol, which is not an Richard ITU-T standard. A proposal has been made, and is being Richard studied, to use BGP routers to collect traffic flow data, Richard which could be used, by bilateral agreement, by operators Richard for billing purposes. Richard Richard Is this disingenuous or has the ITU really not heard of Richard netflow? What's so bogus about wanting to charge for traffic? I mean you might not want to have your traffic go somewhere where it's going to be expensive, but governments have been charging for and taxing things for a long time. If the technical details of how to accomplish this are bogus (and changing BGP to include flow data would be), then perhaps that should be fixed. However judging something on all the things a spokesperson says it is *not* seems counter productive. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Most bogus news story of the week
Olivier == Olivier MJ Crepin-Leblond o...@gih.com writes: Olivier Ole Jacobsen o...@cisco.com wrote: (except it's not a joke) Olivier As someone who has confronted some of these gentle people Olivier at IGF, let me tell you it is not a joke. Olivier I am always flabbergasted about what I hear, and never Olivier understand whom they get their information from. It is Olivier often full of inaccuracies, cognitive biaises, Olivier generalisations, misunderstandings and old world thinking, Olivier which, would you believe it, actually makes up for a rather Olivier amusing view of the Internet. A few years ago I was going to the airport from an IETF and happened to be in a shuttle with some BT folks talking about NGN. It was very amusing to listen to their descriptions of us and our bogus thinking, lack of understanding of critical issues, and how serious work on the NGN could not take place in such an environment. Really though, listening to this discussion, I still cannot bring myself to describe the Chinese desire as most bogus ever. They are wanting to map an existing world view onto something new. It is, as several people have pointed out a very problematic mapping, and one that for various technical, social and political reasons we oppose. That doesn't make someone at a high level most bogus ever, for having the idea, even if we believe we have enough information to conclude they are wrong. We can point and laugh at how wrong-headed someone is, sure in the back of our minds that they are doing the same about us, or we can understand where they are coming from and try to engage. Some days, I'm not sure which option is better:-) Pointing and laughing, is easy and if you're in a group that mostly agrees with you can use the mob mentality to make you feel good and important. Engaging on the other hand often feels like fighting an up-hill battle that never really seems to make as much progress as it must. It does, however, in my view have the moral high ground. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-krb-wg-preauth-framework (A Generalized Framework for Kerberos Pre-Authentication) to Proposed Standard
I hate to be raising last call issues with my own document but such is life. 1) Jim Schaad reports that our ASN.1 module is missing an import statement. 2) Shortly after Jeff submitted the publication request, Tom Yu found some problems with the assigned numbers in the IANA pre-authentication registry that is being created. In response to his last round of comments back in April we moved some things around and apparently left some conflicts in place. The above two are relatively easy to fix. 3) We discovered that the description of ad-authentication-strength at the bottom of page 36 is incorrect. It says that ad-authentication-strength needs to be included in ad-if-relevant. The problem with that is that a client could generate a fake ad-authentication-strength element unless it is integrity protected by the KDC. So, ad-authentication-strength really needs to be included in ad-kdc-issued. In this case, the KDC provides integrity protection for the element, preventing a client from including its own claim about authentication strength. (This is roughly the difference between signed and unsigned attributes in CMS). I need to figure out whether ad-kdc-issued is inherently non-critical or if you need ad-kdc-issued plus ad-if-relevant (and if so, what the order should be) to get a non-critical integrity-protected authorization data element. This change should not be a problem; as far as I'm aware none of the implementations currently include an ad-authentication-strength element. Sorry that the above point is coming out so late. We discovered this when looking at a bug in another protocol and were concerned that we might have something we needed to treat as a product security problem. As it turns out that issue is non-sensitive and I'll be describing it in a separate message to the working group list. I request permission from the chairs and Tim to upload a new draft fixing these three issues once I confirm a resolution for #3 above. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NAT Not Needed To Make Renumbering Easy
Christian == Christian Vogt christian.v...@ericsson.com writes: Christian Right. There is one limitation, though: With stateless Christian NAT'ing alone, failover of active communication Christian sessions between providers is not possible. I agree with this statement. Christian This is Christian because statelessness requires one-to-one address Christian mappings, hence a separate internal prefix for every Christian provider-assigned external prefix. Many-to-one address Christian mapping, such as by mapping a single internal prefix Christian onto multiple external prefixes, would require stateful Christian demultiplexing. I don't think this follows. Statelessness only requires that when a packet crosses from inside to outside, I be able to select the correct external prefix without state. There are a number of ways to do this, including hashing the six-tuple (five tuple plus flow ID) to choose an exit. The return direction does not require state. None of this allows you to fail over a connection. However, maintaining state does not help either. If you have multiple external prefixes most transports will not permit you to change the external address on an ongoing connection. We have a lot of tools if you want multihoming better than that. Some of them, like BGP multihoming, LISP and HIP, work quite nicely with NAT66. Others, like SHIM6, would need some work to work in a NAT66 environment. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt
Jari == Jari Arkko jari.ar...@piuha.net writes: Jari Dave, An accounting assessment of community views, justifying claims of rough consensus, is the usual approach towards resolving this kind of disparity. Jari That sounds like a fine plan. We got most input during the Jari third last call when I asked whether the notes should be Jari optional or mandatory. My notes indicate maybe a dozen Jari people on both sides of that particular question, and that's Jari the basis of my claim that there are people on different Jari sides of this argument. Since then we have had less people Jari participating in the discussion. Jari How would you like us to progress on this then? Do you want Jari me to do a recount :-) I could easily have been wrong. Or is Jari this more about when we are polling people? But I fear that Jari all except the die-hards have left the thread. I certainly have. I listened until I thought I understood the other positions, I wrote until I thought I had done a reasonable job of stating my position, but more back and forth doesn't seem to be productive. So, my only participation at this point is to state from time to time that I think the process is reasonable. ___ 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
SM == SM s...@resistor.net writes: SM Hi John, SM At 18:09 13-10-2009, John C Klensin wrote: This is the part of the review that I don't want to do unless it is clear that it really belongs on Standards Track. If it is an SM I mentioned to the authors of this draft that the changes I SM may suggest for the document to be appropriate as a proposed SM standard would make it incompatible with PEC. As you said, SM this is one of the cases where we have to consider what kind SM of review is appropriate for an I-D. To pick up another element of your comments, RFC 2822 and 5322 discourage the use of X-headers. Even if the Xs were removed, SM This is again a case where existing implementations will be SM used to argue why the X-headers cannot be changed even though SM using such headers for messages on the Internet is bound to SM cause problems. it is not clear to me that the relevant headers are clearly enough defined for a header registry. And, perhaps as part of your internationalization considerations remark, I note that we have never standardized a header field name that is based on Italian, rather than English, words. I can't think of any particular reason why we should not (although there are lots of reasons to not have standard header field names that require non-ASCII strings) but it is a major step that needs some serious consideration... not slipping in the back door via a security document. SM I noticed that some RFC 5322 headers are translated in SM Spanish. It's difficult to say that headers must be in SM English (they are in Italian in the draft). However, if we SM are to have a header field name translated for each language, SM we will end up with an unworkable situation. Yes, I think the things that you, Sam, and I spotted on very quick inspection are probably the tip of the proverbial iceberg, all of which will have to be examined if the document is really standards track. But I also agree with Sam's other main point: if the document is to be processed as an Individual Submission Standards Track spec, it should reflect _at least_ the document quality we expect out of WG documents being similarly processed. It doesn't. SM I didn't see Sam's message. I agree that such documents SM should reflect the document quality we expect out of Working SM Group documents. It was sent only to the IESG and John. It was clearly an IETF contribution so it's entirely reasonable that John is discussing it here. Basically I enumerated a number of reasons that I believe suggest the document is not ready for last call as standards track. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Support for publication of draft-housley-iesg-3932bis
I have reviewed the latest revisions of the update to rfc 3932 and believe that would be a reasonable way forward. Thanks to the IESG and authors for being responsive to the last call concerns. --Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Olaf == Olaf Kolkman o...@nlnetlabs.nl writes: Olaf On Sep 8, 2009, at 6:09 PM, Sam Hartman wrote: Tim, I definitely agree with you that it should be the IETF community that is last called. Normally, the IESG judges IETF consensus. However, if it makes the IAB more comfortable for the IAB chair to do the consensus call, that's fine with me. If we do that we'd need to make it clear how this interacts with the IETF appeals process. Olaf Sam, Olaf the underlying point of my question is that the streams are Olaf independent and that the IETF (stream) has no say about the Olaf other streams. IETF consensus or not. Right; I think I made it fairly clear in my reply to John Klensin that I disagreed fairly strongly with that and argued why I believed that the IETF needs a special role to attach a note to something. No discussion prior or since has changed my mind. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Robert == Robert Elz k...@munnari.oz.au writes: Robert Then note that this is exactly the same ralationship that Robert the RFC editor should have with the IETF. I disagree for reasons I have previously stated. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Tim, I definitely agree with you that it should be the IETF community that is last called. Normally, the IESG judges IETF consensus. However, if it makes the IAB more comfortable for the IAB chair to do the consensus call, that's fine with me. If we do that we'd need to make it clear how this interacts with the IETF appeals process. I'm not thrilled with the appeals process starting with the IAB and only going to the ISOC BOT in case there is no adequate process (6.5.3 in RFC 2026). However I could live with that. I suspect this may be one of those cases where we know we've gotten a good compromise because no one is happy with it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Russ, I think that it is absolutely critical that the IETF be able to attach a note to an RFC and that this note not simply be a recommendation. We can believe all we want that the IETF stream is just one stream and that all other streams are independent. However, the RFC process is very tightly tied to the IETF, and I think it is reasonable for the IESG to be able to raise a note in an exceptional circumstance. I believe that this serves as an important check on the independent stream, just as the independent stream is supposed to serve as an important check on the IETF stream. Part of my thinking is motivated by my belief that the IETF has more structures in place and a broader community of people reviewing its work than the independent stream. I fully understand that there are people who are involved/interested in the independent stream who are not involved in the IETF. I believe that independent+ietf is a broader community than IETF alone. (We assume that it is a significantly broader community; I've never been given data to back up that assumption, but I'm happy to hold it for the moment.) However I doubt that community is sufficiently broader that it should be able to overrule the IETF. Even if the community was sufficiently broader, I'm still not sure that I would be comfortable with it being able to overrule the IETF of a comment that the IETF wanted to place on an independent stream document. However, the IESG is not the IETF. I'd personally be happy to ignore that and assume it would all work out. I'd also be happy with a mechanism where the IESG could propose a note, and the RFC editor had the option of accepting the note or asking the IESG to last-call its note within the IETF community. I would not consider it acceptable if the note were purely advisory. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
