Re: [AFS3-std] Re: Last Call: draft-allbery-afs-srv-records (DNS SRV Resource Records for AFS) to Proposed Standard
On 2/4/2010 12:02 PM, Jeffrey Hutzelman wrote: --On Wednesday, February 03, 2010 03:27:01 PM -0800 Russ Allbery r...@stanford.edu wrote: SM s...@resistor.net writes: At 17:03 01-02-10, Russ Allbery wrote: Ah, thank you. Changed to SHOULD on the assumption that the (pre-2119) language in RFC 1034 was intended to have roughly the same meaning. SHOULD as a requirement first appeared in RFC 1122. It does not necessarily apply to RFCs published before RFC 2119. I guess I'm not clear on what you think the correct fix is. I'm hesitant to use a lowercase should in a document that explicitly references RFC 2119, since then it's ambiguous what that is supposed to mean in terms of a standard requirement. Agree. I think we want to elevate this to SHOULD in this case, even if the original 1034 requirement was not that strong. Clients failing to operate this way presents real operational problems for AFS cell administrators. I would suggest a slight rewording, so that the present text cannot be read to imply that 1034 says SHOULD in the 2119 sense, when in fact it is somewhat more ambiguous. -- Jeff How about? AFS clients MAY remember which targets are inaccessible by that client and ignore those targets when determining which server to contact first. As is common practice, clients which do this SHOULD have a mechanism to retry targets which were previously inaccessible and reconsider them according to their priority and weight if they become accessible again. smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [AFS3-std] Re: Last Call: draft-allbery-afs-srv-records (DNS SRV Resource Records for AFS) to Proposed Standard
On 2/4/2010 2:05 PM, Jeffrey Hutzelman wrote: That's not the text we're talking about. Sure. Context was lost in the thread as the message-ids are not consistent. The text I think is being discussed is not actually in the draft, it is proposed text that Russ put forward on 1 Feb 2010. DNS SRV RRs, like all DNS RRs, have a time-to-live (TTL), after which the SRV record information is no longer valid. As specified in [RFC1034], DNS RRs SHOULD be discarded after their TTL, and the DNS query repeated. This applies to DNS SRV RRs for AFS as to any other DNS RR. Any information derived from the DNS SRV RRs, such as preference ranks, MUST be discarded when the DNS SRV RR is expired. How about: DNS SRV RRs, like all DNS RRs, have a time-to-live (TTL), after which the SRV record information is no longer valid. As implied by [RFC1034], DNS RRs SHOULD be expired after their TTL, and the DNS query repeated. This applies to DNS SRV RRs for AFS as well as any other DNS RR. Any information derived from the DNS SRV RRs, such as preference ranks, MUST be discarded when the DNS SRV RR is expired. smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [AFS3-std] Re: Last Call: draft-allbery-afs-srv-records (DNS SRV Resource Records for AFS) to Proposed Standard
On 2/4/2010 2:30 PM, Jeffrey Hutzelman wrote: --On Thursday, February 04, 2010 02:20:27 PM -0500 Jeffrey Altman jalt...@secure-endpoints.com wrote: On 2/4/2010 2:05 PM, Jeffrey Hutzelman wrote: That's not the text we're talking about. Sure. Context was lost in the thread as the message-ids are not consistent. The text I think is being discussed is not actually in the draft, it is proposed text that Russ put forward on 1 Feb 2010. DNS SRV RRs, like all DNS RRs, have a time-to-live (TTL), after which the SRV record information is no longer valid. As specified in [RFC1034], DNS RRs SHOULD be discarded after their TTL, and the DNS query repeated. This applies to DNS SRV RRs for AFS as to any other DNS RR. Any information derived from the DNS SRV RRs, such as preference ranks, MUST be discarded when the DNS SRV RR is expired. How about: DNS SRV RRs, like all DNS RRs, have a time-to-live (TTL), after which the SRV record information is no longer valid. As implied by [RFC1034], DNS RRs SHOULD be expired after their TTL, and the DNS query repeated. This applies to DNS SRV RRs for AFS as well as any otherDNS RR. Any information derived from the DNS SRV RRs, such as preference ranks, MUST be discarded when the DNS SRV RR is expired. How about Consistent with [RFC1034]...? The problem I have with your text that it could be interpreted as merely descriptive of 1034, rather than as prescribing a requirement that applies to AFS SRV RR's regardless of how you choose to read 1034. Consistent with ... works for me. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Ietf-http-auth] Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Eric Rescorla wrote: Hmm... I'm still not sure what you're trying to say. My point is that there shouldn't be any consensus calls by anyone on the ietf-http-auth mailing list. It's not a WG. Eric: It sounds to me as if you are attempting to claim that only official IETF activities are permitted to ask the participants in a discussion what they think. Clearly it is not going to be possible for a subsequent revision of this document to be re-submitted to the IESG if the contributors to the document cannot achieve consensus among themselves. I have no problem with Sam soliciting opinions in his document on any forum of his choice. What I object to is the notion--again implied in your above comments--that this document has some formal standing. As I said initially, this is an individual submission that failed to obtain consensus. As such it doesn't need shepherding or shepherding ADs, any more than any other individual ID. This is a document for which an Area Director (separate from the one who happened to be the author of the document) wishes to forward progress. While this does not imply a formal basis for consideration, it does provide incentive to put additional effort into revising it. Alexey was asked by an AD to take responsibility for this document. He is trying to fulfill that request. There is no reason to put hurdles in his path. As should be clear from my initial review, I don't think this document should move forward. That is your opinion and you are welcome to hold it. However, it is clear to me that this problem area cannot be addressed by organizations such as W3C without the support and collaboration of the IETF. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
Brian E Carpenter wrote: The financial fallacy in that is failing to note that about half the meeting fee isn't used to fund meeting expenses, but to fund continuing operations of the IETF as a whole (secretariat, RFC Editor, etc.) So restructuring the meetings would have to be done in a way that preserves the meetings surplus at about the same annual total as today. I think the IETF needs to decide what its goals are and create a funding structure that creates the appropriate incentives to achieve those goals. We want to encourage participation by the best and brightest and especially those who have time to accomplish the work. With the cost of attending a single working group session now in excess of $1000 when you include travel, overnight at the hotel, plus the flat rate meeting fee, we are discouraging participation. I have stopped attending IETF meetings in person for a variety of reasons. Cost is certainly a major factor. The amount of time I must spend away from home and my company is another one. Besides, why should I spend my own time and money to solve other people's problems? In my opinion you want to keep the cost of in person participation down so that there aren't two classes of IETF participants, those who are face-to-face and those who aren't. The notion that NomCom eligibility should be determined by those who attend meetings just doesn't make a lot of sense for an organization that prides itself on only making consensus decisions on mailing lists. Instead, we should minimize the challenges to active remote participation and find an alternative source of funds. One notion might be to charge for publications of Internet Drafts. $500 for a draft name including five revisions and then $25 for each additional revision. The rationale is that it is the draft publications which create work for the entire IETF and the cost of that work should be borne by those who want to see the work accomplished. smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Streaming
Marc Manthey wrote: On Jul 24, 2007, at 8:24 PM, Jeffrey Altman wrote: Joel Jaeggli wrote: The webpage for the streaming has been updated to reflect the schedule for monday and tuesday. http://videolab.uoregon.edu/events/ietf/ One addition is that we intend to record and broadcast the Sunday IEPG meeting located in the crystal ballroom from 1000-1200 CDT. Regards Joel Jaeggli This information really needs to be on the IETF69 Meeting page. its on the mainpage of the community wiki http://community.ietf.org/wiki/ and what good is that? The IETF69 Meeting web site is: http://www3.ietf.org/meetings/69-IETF.html Folks interested in the IETF meetings go to that page not the wiki to find out about the meetings. On that page is a section on Agenda and Presentations. In that section are links to the agenda, the meeting materials and the text conferencing. If I didn't know that there was audio streaming, how would I find out about it from the IETF69 meeting page? Why should I have to guess at looking at the Wiki for IETF 69 under the Tools and Ticketing section in order to determine that there is audio streaming? The link should be under the Agendas and Presentations. Even better would be links from the Meeting Agenda page to the audio streams, presentations, and Jabber rooms for the individual sessions. The current web site might be organizer friendly but it is not attendee friendly. smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-williams-on-channel-binding: IANA rules too complicated
Sam Hartman wrote: Unless there is strong support for the more complex registration process in the draft, we'd like to go to expert review. The technical argument in favor of a review list, whether a special list for this purpose or some pre-existing list such as SecDir, is that it is not always easy to find experts who are familiar with both of the protocols being bound. As a result, having more reviewers is a safety net. This is especially important for reviews of security protocols. I do not believe that the registration process defined in this draft is particularly burdensome. It is a well defined process with time limits that will provide a predictable response time for requesters. It doesn't limit the Area Director's ability to select an expert to perform the review. It simply provides for transparency and public comment on the registration. I believe the registration procedure should be implemented as described in the draft. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: *.ppt slides
Stewart Bryant wrote: Generally speaking just getting the slides before the slot is difficult enough without specifying a format that the author may not normally use. As a chair, I believe it is my responsibility to either obtain the presentations as PDF or convert them to PDF before posting to the meeting materials page. It is not fair for those paying attention to the meeting via audio stream or Jabber to be forced to perform the conversions on their own. It is more important to me that I obtain the participation than push the conversion chore off on someone else. I also believe that presenters should for the benefit of the audio stream state the slide number they are on as they give their presentation. This is important not only for those listening live but also for those who listen to the archive later on. Jeffrey Altman Kitten Chair smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: security features.... (Re: Facts, please)
Robert Sayre wrote: On 9/19/06, Harald Alvestrand [EMAIL PROTECTED] wrote: Robert Sayre wrote: I don't disagree. The IETF might first try to design an authentication feature worth requiring. None of the current options are at all satisfactory. In fact TLS + HTTP Basic Auth is pretty interoperable, secure against quite a few attacks, and widely deployed. Ah, this is the wink, wink approach to mandatory authentication. Specify something no one uses. Here is my bank's web site: http://www.chase.com/. It looks like a phishing attack. If you try https://www.chase.com it redirects you to http://www.chase.com. How lame. smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
Speaking as a working group chair, what is important to me is the ability to make progress on the milestones the working group is committed to achieve. Traveling to some far away location in order to fill the seats with spectators does not result in work being accomplished. I require that not only can I afford to travel there but that the half dozen active participants be able to do so as well. We are already at the point where I and others are experimenting with methods to improve the capabilities of remote participants to actively partake in the working group sessions. My belief is that working group sessions should avoid presentations whenever possible. The working group gets two hours of face to face time every four months. I'm not going to waste that time on presentations meant to instruct the locals and if you don't know what is going on before you arrive in the meeting room chances are you will not be able to contribute in a meaningful way. At IETF66 the Kitten, Kerberos and SASL working groups used a format that involved wandering microphones in the audience to permit natural dialogs among the active contributors in the room similar to that experienced at any technical design meeting while ensuring that those listening on the audio stream do not miss a beat. At the same time the Jabber room was projected on a second display in order to enable all of the participants in the meeting room to see the input of those not physically present. This model worked so well in fact that in SASL one of the primary document authors who was not present at the meeting was able to lead the discussion with him typing away on Jabber and the rest of the room responding via voice. When I attend IETF it is rare that I ever get to experience the world outside the conference hotel. My days are filled from breakfast meetings to late night work sessions. There is so much that needs to be done that I could care less about where in the world I am or what the weather is like outside. What is important is that when I am not in a session that there be lounges in the hotel for to use for meetings that have working network access. For me Paris and Montreal were the two worst meetings I have experienced in ten years because of the separation of the IETF hotel from the meeting locations and the in ability to provide network access in the hotel public spaces. My productivity dropped significantly because of those failures. The best IETF meetings from my perspective are those held in Minneapolis. The hotel understands what we need. The lounge and bar areas are smoke free and plentiful. There is accessible food via the habitrails. Things just work. To summarize, before the IETF should visit new countries folks from those countries need to participate on the mailing lists and begin to actively involve themselves reviewing documents and editing documents. That is the work we do. Traveling to Casablanca is not going to help get the work done. The one piece of evidence that might change my opinion would be this. Show me evidence that first time attendees at a local meeting results in those attendees editing a document and becoming repeat attendees in the future. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF66 - Recommendations for travel from airport to hotels?
I have arrived in Montreal. The taxi to the Delta is now CDN$35. There are airport shuttles into Montreal for CDN$13 but you would then need to take a taxi from the bus terminal to the hotel on the meter. Public transportation is also available but the travel time will be well over an hour. The travel at 17:20 in rush hour took approximately 20 minutes in the taxi. At the Delta Hotel there is no wireless in my room. There is a wired connection for CDN$9.95 per 24 hours which has a reasonable bandwidth at the current load. Jeffrey Altman Miao Fuyou wrote: The following information is from http://www.montreal.com/tourism/general.html . Airports: Pierre Elliott Trudeau International, 22 km west of downtown, now serves all domestic, U.S. and international passenger flights. Mirabel International, 55 km northwest of downtown, serves only cargo flights now. A taxi ride from anywhere in town to Trudeau Airport costs a flat rate of $31. Aerobus shuttle bus service runs from the downtown bus terminal (514-842-2281) with several stops before taking the highway. Fares are lower than taxis: $12 to or from Trudeau. It is also possible to get to Trudeau Airport by taking regular city buses: the 211 and the 204 will get you there from downtown, but the 211 could be tricky with a lot of baggage at busy times of day. Hope it helps! -Original Message- From: YAO Jiankang [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 05, 2006 9:11 AM To: Jeffrey Altman; ietf@ietf.org Subject: Re: IETF66 - Recommendations for travel from airport to hotels? someone told me that the cost from YUL airport to montreal downtown is about canadian 35 $. it seems that there was no shuttle bus to the hotel. It is better that IETF can recommend some good travel methods from airport to downtown hotels. Yao Jianakng - Original Message - From: Jeffrey Altman [EMAIL PROTECTED] To: ietf@ietf.org Sent: Wednesday, July 05, 2006 8:00 AM Subject: IETF66 - Recommendations for travel from airport to hotels? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF66 - Recommendations for travel from airport to hotels?
Does anyone have any recommendations for methods of travel from the airport to the Delta Hotel? I do not see any information on either the IETF66 or Delta Hotel web sites. Thanks. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-ietf-bmwg-hash-stuffing-05.txt
, but there undoubtedly some instances where they are not discussed. Perhaps this warrants general discussion and possibly a document on stuffing vulnerabilities. Perhaps the same is also true of the address skew vulnerabilities, I need to think about it some more. I remember an IAB document on DOS vulnerabilities from a while ago, what is the status of this document and did it discuss any of these issues? This comment makes me wonder whether there should be an index of security considerations such that all of the types of security considerations are listed along with the documents in which they appear. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Audio Info
Lucy E. Lynch wrote: All - Information on the audio from the rooms can be found at: http://videolab.uoregon.edu/events/ietf/ or you can go th http://www.ietf65.org and find a link to the audio services on the top level page. Could someone please place a link to this info on http://www.ietf.org/meetings/IETF-65.html ??? Thanks. smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Keeping this IETF's schedule in the future...?
I too am in favor of the new schedule. As for the length of lunch. I believe that 1.5 hours is appropriate at most venues at which it is possible to obtain relatively fast meal service. Here in Paris, it appears that lunch at many of the restaurants really requires closer to 2 hours just in order to get served. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-klensin-nomcom-term-00.txt
There is one thing and one thing only that I believe term limits are good for: weakening the power of a body by reducing its experience level Do we really believe that the IESG and IAB are too powerful? Do we really want to ensure that the average level of experience on the IESG and IAB are under two years? If the average experience level of the IESG and IAB is significantly less than the paid staff, then the paid staff will be the ones that effectively determine the decision making process. If the IETF participants want there to be greater turnover on the IESG and IAB there are mechanisms to do so: nominate more and better candidates volunteer to serve on nomcom be proactive in providing nomcom feedback on the candidates I do not believe we need or in reality want to place arbitrary MUSTs or SHOULDs when it comes to the length of time someone can serve. Jeffrey Altman P.S. - being curious: what are the max terms for the IESG and IAB in their history? what are the average terms for the IESG and IAB in their history? what are the average and max terms of the current participants? smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [saag] [Sam Hartman] draft-harris-ssh-arcfour-fixes-02: informational or proposed?
My personal opinion is that if there is a protocol that has been widely deployed but which for whatever reason the IETF does not want to encourage its adoption, the RFC should be published immediately as HISTORIC. Jeffrey Altman Sam Hartman wrote: Hi. I believe the following request is of interest to secsh and saag. Subject: draft-harris-ssh-arcfour-fixes-02: informational or proposed? From: Sam Hartman [EMAIL PROTECTED] Date: Wed, 01 Jun 2005 14:35:07 -0400 To: ietf@ietf.org To: ietf@ietf.org CC: iesg@ietf.org Return-Path: [EMAIL PROTECTED] Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Wed, 01 Jun 2005 14:37:25 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: [EMAIL PROTECTED] Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by suchdamage.org (Postfix) with ESMTP id 581AA1383D for [EMAIL PROTECTED]; Wed, 1 Jun 2005 14:37:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdY3t-00074x-D9; Wed, 01 Jun 2005 14:35:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdY3r-00073R-2v; Wed, 01 Jun 2005 14:35:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13323; Wed, 1 Jun 2005 14:35:23 -0400 (EDT) Received: from stratton-three-sixty-nine.mit.edu ([18.187.6.114] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdYNe-0002lY-42; Wed, 01 Jun 2005 14:55:59 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 36E3DE0063; Wed, 1 Jun 2005 14:35:07 -0400 (EDT) Message-ID: [EMAIL PROTECTED] User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion ietf.ietf.org List-Unsubscribe: https://www1.ietf.org/mailman/listinfo/ietf, mailto:[EMAIL PROTECTED] List-Post: mailto:ietf@ietf.org List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: https://www1.ietf.org/mailman/listinfo/ietf, mailto:[EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on solipsist-nation.suchdamage.org X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 MIME-Version: 1.0 Hi, folks. The IESG has received a last call comment recommending that the new rc4 cipher for ssh be published as informational rather than as a proposed standard because of weaknesses in rc4. It would be inappropriate to make a decision based on one comment so I am soliciting comments on this point. The argument in favor of publishing this document at proposed is that the existing arcfour cipher is part of a standard and that many other IETF protocols use rc4 in standards track documents. Please submit comments to ietf@ietf.org or iesg@ietf.org on this issue by 2005-06-28. Included below is a partial bibliography of RC4 attacks provided to the IESG by the person making the original comment. S. Fluhrer, I. Mantin, A. Shamir, Weaknesses in the Key Scheduling Algorithm of RC4, Proceedings of 8th Annual International Workshop on Selected areas in Cryptography (SAC 2001), Toronto, ON, CA, August 2001. J. D. Golic, Linear Statistical Weakness of RC4 Key Generator, Procedings of EuroCrypt 1997, Konstanz, DE, May 1997. S. Fluhrer D. McGrew, Statistical Analysis of the RC4 Key Generator, Proceedings of 7th International Workshop on Fast Software Encryption (FSE 2000), New York, NY, US, April 2000. S. Mister S.E. Tavares, Cryptanalysis of RC4-like Ciphers, Proceedings of 5th Annual International Workshop on Selected Areas in Cryptography (SAC 1998), Kingston, ON, CA, August 1998. L. Knudsen, W. Meier, B. Preneel, V. Rijmen, S. Verdoolaege, Analysis Method for RC4, Proceedings of AsiaCrypt 1998. R. Wash, Lecture Notes on Stream Ciphers and RC4, unpublished, Case Western Reserve University, OH, US http://acm.cwru.edu/files/2002%20Spring/talks/latex_samp2_4_09_02.pdf S. Paul B. Preneel, Analysis of Non-fortuitous Predictive States of the RC4 Key Generator, Proceedings of 4th International Conference on Cryptology in India (IndoCrypt 2003), New Delhi, IN, December 2003. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ saag mailing list [EMAIL PROTECTED] https://jis.mit.edu/mailman/listinfo/saag smime.p7s Description: S/MIME Cryptographic Signature
Re: Last Call comments on draft-strombergson-shf-04.txt
in the header for each block. The problem I have with this is that it restricts the size of the block to be something storable in memory and even assumes that the entire data block must be available prior to the generation of the header. It is very likely that the source of the data being stored by be coming from a stream source and there may not be enough memory to store it all before writing to the dump media. The checksum should be stored as a tag inside the block and the tag should contain an attribute specifying which algorithm was used. A similar checksum tag should be available to validate the entire dump. - In section 4.1, you say if the value is untrue I suspect you mean something like if the value does not match Further, rather than leaving the behaviour in the case of an incorrect length up to the implementation, it should be RECOMMENDED (RFC2119) that implementations reject such files. - In section 4.2, you require the start_address attribute to be provided, even though it may not be meaningful in all cases. This attribute should be OPTIONAL. I can see this format being used to store crash data from an application for later debugging. In this case there may be blocks which contain stack information or register contents which are not memory addressable. - I don't believe 64 bits are required to represent word size. In fact, I question whether it is necessary for this format to represent word size at all. I believe that word size may make sense for some types of blocks which would be stored in the dump file but it should not be REQUIRED. I believe the most general applications would only be interested in octet streams. - The number of blocks is OPTIONAL, but the block length is REQUIRED. Further, there is a per-block checksum but no overall checksum. These properties would seem to suggest that the intent is to allow stream-encoding by encoding an arbitrary number of relatively small blocks. This is fine, but lacking both a block count and an overall checksum, there is no way to tell whether the entire dump was transferred correctly. I would suggest adding an overall-checksum element, to be encoded after the last block (_not_ as an attribute). If one purpose is to allow encoding an arbitrary number of small blocks, there should be some indication of whether order is important, whether blocks can be dropped, etc. - Why is the number of _bits_ in a block limited to 2^64-1? This limitation seems unnecessary, given that everything else is done in terms of octets. Why bits if the word size is restricted to octets? Why not just specify the number of words since words are already required? - The requirement that words inside a dump be represented in network order is silly. The contents of a dump are by their nature specific to a particular device, and should be in whatever format is most appropriate for that device. Again, I question whether this format should have any notion of words at all. As one of the comments in the ID Tracker stated, the byte order representation for each block should be determined by the application. Each block should have an attribute specifying the byte order used. My biggest concern is that this format is not general enough. I fear that because the uses the authors were considering are not spelled out that there are underlying assumptions embedded in the document which will hamper its usefulness. Jeffrey Altman Secure Endpoints Inc. begin:vcard fn:Jeffrey Altman n:Altman;Jeffrey org:Secure Endpoints Inc. adr:;;255 W 94TH ST PHB;NEW YORK;NY;10025;United States email;internet:[EMAIL PROTECTED] title:President tel;work:+1 212 769-9018 x-mozilla-html:TRUE url:http://www.secure-endpoints.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: List of Old Standards to be retired
Eliot Lear wrote: If you see a document on the list below and you know it to be in use, would you please reply to this message indicating the RFC number, and whether you believe the doc should be advanced beyond proposed? Also, if you know of work to update anything on the list below, please include that. A note along these lines is generally sufficient to remove a document from the list below. I am a fairly good contact point for most things TELNET. Back in June 1999 the Application Area Directors, Keith Moore and Patrik Falstrom, performed a review of TELNET RFCs to move unused ones to HISTORIC. This was done in consultation with the subscribers to the [EMAIL PROTECTED] mailing list. All of the remaining Telnet options were determined to be implemented in various widely deployed implementations. RFC0698 Telnet extended ASCII option RFC0726 Remote Controlled Transmission and Echoing Telnet option RFC0727 Telnet logout option RFC0735 Revised Telnet byte macro option RFC0736 Telnet SUPDUP option RFC0749 Telnet SUPDUP-Output option RFC0779 Telnet send-location option RFC0885 Telnet end of record option RFC0927 TACACS user identification Telnet option RFC0933 Output marking Telnet option RFC0946 Telnet terminal location number option RFC1041 Telnet 3270 regime option RFC1043 Telnet Data Entry Terminal option: DODIIS implementation RFC1053 Telnet X.3 PAD option RFC1372 Telnet Remote Flow Control Option Since the requirement for moving to historic under the cruft draft is that it is not widely implemented, all of these options must remain. If there is desire to move these options to historic, then the guideline must be altered. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IEA Bottom Line
John: Thank you for your continued rationality. I do not have a strong opinion on what the solution to this problem should look like. However, I am concerned about some related problems. Local mail parts are often derived from or are usernames. Administrators like the ability to be able to assign a single name to an end user for the purpose of user identity. It is my hope that whatever conclusion is reached will ensure that the i18n mechanism will allow this single single name to be compatible with existing naming conventions utilized with Kerberos, SASL, X.509, etc. It would I believe detrimental to everyone if the various protocols which must manipulate user identities did not have a common way of representing them. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: IEA Bottom Line
John C Klensin wrote: Jeffrey, I think this is an important point. The question is what to do about it. One extreme view is that we should, because of those issues, say usernames must be confined to simple, IA5, strings because that is the only way to get guaranteed interoperability with all of these things with a single string. I don't think that is going to fly in the areas in which people are really determined to internationalize usernames and email addresses. Nor do I think that those folks are going to accept an encoding that causes user names to look as expected in some contexts and a hard-to-verify form in others -- users won't see it as the same, or common, representation of their names. So, at worst, we should be sure that people understand the tradeoffs, regardless of what i18n system is adopted: localization versus global interoperability, localization versus a single identifier as username, mailbox address, and Kerberos/ SASL/ X.509 certification or credential name. I'll try to work some words to that effect into -02 of my email document so it doesn't get lost. Much more than that we probably can't do, any more than saying I18n Bad or I18n risky or I18n less interoperable is going to prevent anyone who thinks they are needed from deploying _something_ for very long. regards, john John: My primary concern with the i18n issues are those of wire representation leakage at the user interface layer. The IDNA solution has resulted in some nasty implications for the security community because it mandates the leakage of ACE representations of IDNs to the end user when the local system architecture cannot support the appropriate i18n display and input mechanisms. This decision is wonderful for short term interoperability because it allows the existing end-user application infrastructure to be used during the migration process. The problem it causes for the security community is that the primary goal of the authentication process is to mutually authenticate two entities to one another. This usually usually means verifying a name in some fashion. This can either be done by using the name as input to some cryptographic operation (SRP,Kerberos,...) or by associating the name with an information bundle protected by a cryptographic operation (X.509). In either case, we have complicated the situation immensely by moving from a model in which each entity has one unique name to a model in which each entity may have multiple names. Future revisions to the affected protocols can deal with the change in the model, but what of the existing deployments which cannot? I would much rather see an incompatible protocol or architecture which requires a short amount of severe pain than one that compromises the architecture for the lifetime of its future deployment. Future versions of SASL and Kerberos are going to standardize on the use of a normalized form of Unicode represented in UTF-8 as the wire format for strings. X.509 already can support Unicode. If it were possible to insist that only Unicode aware applications could use i18n names then we would see a much more rapid transition to newer protocol implementations across the board. From my perspective, applications should be free to provide their own mechanisms for displaying i18n names when the operation system or windowing system does not support them. However, the wire representations should not be leaked through. The applications should always be requires to convert to Unicode before passing the strings the various protocol libraries. This would allow us to develop the network infrastructure independent of the user interface infrastructure. It is unfortunate that this separation cannot be maintained. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
TONIGHT: Project JXTA Engineering Meeting - Continental 8/9 - 7pmPST
Tonight, the Project JXTA http://www.jxta.org Board of Directors invites you to attend a Project JXTA Engineering Meeting to be held at Hilton San Francisco, 333 O'Farrell Street, San Francisco, CA 94102 from 7pm to 10pm PST in room Continental 8/9. This meeting has been scheduled coincide with IETF 56(*) The purpose of this meeting is to provide a forum for face to face technical discussions related to the future of the JXTA Peer-to-Peer Protocols and the Project JXTA Reference Implementations. Over the last year we have made significant progress in stablizing the JXTA Reference Implementations and improving the performance. The J2SE Reference Implementation is now in a state upon which real world applications can be deployed with a signficant amount of confidence in the robustness of the environment. During the course of this work many ideas for improvement have been put forward and much experience has been gained. It is hoped that this meeting we be the beginning of a new round of active discussion within the Project JXTA engineering community over the next steps to be taken. This meeting will not replace discussion on the mailing lists http://www.jxta.org/project/www/maillist.html. In fact, it is hoped that with network access available in the meeting space that we will be able to involve interested community members who are unable to attend in person. All presentations will be posted to the JXTA.ORG web site prior to the meeting via a link from the home page. The forum of the meeting will be a series of short presentations on a set of related topics by one or more experts drawn from the community and the Sun engineering team. After each set of presentations the floor will be opened for questions and discussion. After the meeting the discussions will be continued on the [EMAIL PROTECTED] mailing list. Proposed topics for include: Review: Where are we now? (J2SE, J2ME, C, ...) Formalizing the JXTA Protocol Specification Process Security implementations Alternative Peer Group implementations to demonstrate the flexibility of the JXTA architecture. (One size does not fit all needs.) Quality of Service extensions Simplifying the Application level JXTA API to ease adoption. (perhaps by wrapping JXTA with the BSD Sockets API and/or Java Sockets API.) JXTA Peer Groups without Rendezvous Peers JXTA and Web Services JXTA and IPv6 Performance enhancements Please contact Jeffrey Altman [EMAIL PROTECTED] if you have questions. We hope you will join us. - The Project JXTA Board (*) This meeting is not an IETF event. The meeting is being held in conjunction with IETF 56 http://www.ietf.org/meetings/IETF-56.html to provide an opportunity for cross-participation between the Project JXTA and IETF communities.
Re: Financial state of the IETF - to be presented Wednesday
Harald Tveit Alvestrand wrote: We usually expect higher costs outside North America - London was even more expensive than Yokohama. With the lack of sponsoring of terminal rooms, the difference is much less, but still significant. The reason for the varying prediction of per-attendee cost for 2004-2005 is that we are considering 2 non-US meetings in 2004 - but if they are definitely more expensive than US meetings even when we get sponsors outside the US and no sponsors inside the US, we may have to reevaluate. Having access to wireless networks and the Internet throughout the meetings are certainly a desireable feature. However, they are hardly a deciding factor on whether or not I attend an IETF meeting. In many ways, if there was no network we might actually get more done. What percentage of the costs of a meeting are due to the terminal room and related expenses? - Does going to two, or four, meetings per year help or hurt? My guess is that going to two would hurt income, unless we raise fees by 50% - the same people would come, I think. Going to four would be damaging to my sanity, at least - don't know about others' we whould expect slightly lower per-meeting attendance, but many would indeed feel obligated to go to all four, so would pay more, I think. Whether they would get more things done is an open question. The real question is to what extent is it reasonable for the costs of running the IETF be funded by relying on attendance fees? It has always struck me as odd that the people who volunteer to do the work of the IETF pay for the privilege. The IETF does not really function as a standards body in the traditional sense as it is not funded either by government grants nor by a consortium of industry. The IETF does not develop mandatory standards which must be adhered to in order to have certified products. Instead everything we do is voluntary. Not only is the work voluntary but so is the output. In many ways the IETF is the ultimate open source project. As with many open source projects, the survival of the project is dependent upon those that do the work having alternative sources of income to support the efforts. I have never felt that was an appropriate funding model for any work that I have done. [If only I could be ensured of a comfortable lifestyle for myself and my family I would glady spend all of my efforts volunteering and give away everything I do for free.] On the other hand, the work of the IETF It would seem that we would want those that benefit from the results of the IETF to pay. The problem is that the benefits the IETF provides to the Internet community are so hard to quantify and put a monetary price on. Nor is it easy to determine who the beneficiaries are? Is it the end-user behind a cable modem? Or the ISP? Or the operating systems, hardware, and application vendors? Should fees be taxes on the use of RFCs? Or perhaps a tax on IP addresses? Or domain names? Who would care the most if the IETF were to disappear? Would it make sense to form sub-areas of the IETF that are funded as Industry Consortiums with membership fees and contributions so that the rest of the working groups could be open? It seems to me that those groups that come to the IETF seeking the expertise of the IETF participants, the IESG review, and the IETF RFC publication status would be more than willing to pay for the privilege of bringing their nearly completed work into the body. (Assuming of course that the IETF thought the work was worthwhile.) I realize that this e-mail is mostly just rambling thoughts but there are no obvious answers jumping out to solve the funding problems of the IETF. - Jeffrey Altman
ANNOUNCE: Project JXTA Engineering Meeting - San Francisco CA US- March 18th 7pm PST
On March 18th, the Project JXTA http://www.jxta.org Board of Directors invites you to attend a Project JXTA Engineering Meeting to be held at Hilton San Francisco, 333 O'Farrell Street, San Francisco, CA 94102 from 7pm to 10pm PST in room Continental 8/9. This meeting has been scheduled coincide with the Internet Engineering Task Force meeting being held the week of March 16th.(*) The purpose of this meeting is to provide a forum for face to face technical discussions related to the future of the JXTA Peer-to-Peer Protocols and the Project JXTA Reference Implementations. Over the last year we have made significant progress in stablizing the JXTA Reference Implementations and improving the performance. The J2SE Reference Implementation is now in a state upon which real world applications can be deployed with a signficant amount of confidence in the robustness of the environment. During the course of this work many ideas for improvement have been put forward and much experience has been gained. It is hoped that this meeting we be the beginning of a new round of active discussion within the Project JXTA engineering community over the next steps to be taken. This meeting will not replace discussion on the mailing lists http://www.jxta.org/project/www/maillist.html. In fact, it is hoped that with network access available in the meeting space that we will be able to involve interested community members who are unable to attend in person. All presentations will be posted to the JXTA.ORG web site prior to the meeting via a link from the home page. The forum of the meeting will be a series of short presentations on a set of related topics by one or more experts drawn from the community and the Sun engineering team. After each set of presentations the floor will be opened for questions and discussion. After the meeting the discussions will be continued on the [EMAIL PROTECTED] mailing list. Proposed topics for include: Review: Where are we now? (J2SE, J2ME, C, ...) Formalizing the JXTA Protocol Specification Process Security implementations Alternative Peer Group implementations to demonstrate the flexibility of the JXTA architecture. (One size does not fit all needs.) Quality of Service extensions Simplifying the Application level JXTA API to ease adoption. (perhaps by wrapping JXTA with the BSD Sockets API and/or Java Sockets API.) JXTA Peer Groups without Rendezvous Peers JXTA and Web Services JXTA and IPv6 Performance enhancements Please contact Jeffrey Altman [EMAIL PROTECTED] if you wish to speak on one of the listed topics. A final agenda will be posted on Monday, March 17th on the JXTA.ORG website. We hope you will join us. - The Project JXTA Board (*) This meeting is not an IETF event. The meeting is being held in conjunction with IETF 56 http://www.ietf.org/meetings/IETF-56.html to provide an opportunity for cross-participation between the Project JXTA and IETF communities.
Re: Wireless in future meetings
Marriott's announcement was that they had signed an agreement with T-Mobile to provide the 802.11b network services. This is the same company that provides the services at Starbucks in the U.S. My personal opinion is that the service is pretty poor. The available subscription plans are enumerated here for the U.S.: http://www.t-mobile.com/hotspot/services_plans.htm Joe Touch wrote: Some places charge a corkage fee for running your own network when they have one too, even if they don't provide what you want (i.e., NAT). FWIW. Joe
Re: text conferencing at the 55th IETF meeting in Atlanta
Can someone fix the X.509 certificate that is used to protect the TLS sessions with conference.ietf.jabber.org ? The hostname is wrong so verification fails.
Re: trying to reconcile two threads
I have Cable Modem service from Time Warner Road Runner in NYC. The way they work it you get up to 5 IP addresses for each cable modem you have. The problem I have run into is that the modem gets assigned the number of addresses you pay for up front. The modem then assigns them, one to each MAC address it sees until the number of addresses is used up. Now if you connect a switch to the cable modem the LAN and WAN MAC addresses of the switch will be seen by the modem and two of your IP addresses will become inaccessible. As far as I can tell there is no way to specify to the modem which MAC addresses should be issued IP addresses. This means that for the first three addresses you get one computer. Four addresses for two computers, five addresses for three computers. Now if you use a NAT device the WAN MAC address is seen first and gets an IP address and then everything else gets private addressing. Even if you want to play by the book, DOCSIS modems make things very difficult. - Jeff Any ideas? I wish it were per-residence pricing. Here, if you want a 2nd (3rd, 4th, ...) IP address, the cable ISP expects you to connect a 2nd (3rd, 4th, ...) cable modem to the cable line. And they then charge additional fees for each such additional connection. Tony Hansen [EMAIL PROTECTED] Keith Moore wrote: IP Addresses cannot at once be scarce enough to charge for and non-scarce enough that scarcity is a non-issue. IPv4 scarcity is an issue, at least for customers. Whether it's an issue for large ISPs is a different question. The cable ISP isn't really charging per-IP addresses; rather it's charging per-residence. The motiviation is not the scarcity of IP addresses, but the scarcity of available dollars per customer - in other words, they have an assumption that the amount of income they can get from residental Internet service is more-or-less a constant times the number of residental customers served. So they use flat-rate, per-residence pricing to attract the largest number of residential customers. But they get annoyed when the service is shared over multiple residences. They'd get just as annoyed if the mechanism were IPv6 instead of NAT. Keith Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 Beta available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. SSH soon to follow.
Re: Jim Fleming's posting privilleges have been revoked
Anthony Atkielski [EMAIL PROTECTED] wrote: I'm really not interested in the opinions of people who continuously rant and spam off-topic posts and it seems that opinion is shared by a lot of people on the list. That's what killfiles and filters are for. I _am_ interested in the opinions of people, no matter what those opinions are. I don't see why the world must be censored at the source just to meet your standards of what you do and don't want to see. And claiming to represent the majority is irrelevant, even if it is true (and I'm not convinced of that), because it is technologically quite possible for each person to censor his own mail at his recipient end--it is not necessary to censor at the source, unless your real objective be to prevent _others_ from reading anything of which _you_ do not approve. If you are interested in opinions no matter what they are then you won't mind if someone starts to randomly forward postings from any of the usenet newsgroups. The question here is not whether or not someone has a right to voice their opinion, but whether or not they have a right to voice their opinion in this forum. If this was a mailing list dedicated to earthworms and a posting on IPv8 was repeatedly sent to the list in various forms, you would have to agree that it would be inappropriate. The IETF mailing list is supposed to be used only for items which are of interest to the entire group of participants regardless of the working group they participate in. It would be inappropriate to discuss implementations or usage of IMAP or SSH on this list. That is what the working group mailing lists are for. In the same regard, IPv8 is not appropriate for this list. One posting would have been fine. But to repeatedly receive similar postings which contain the same message use IPv8 its free and which do not result in any dialog other than why is this being posted and the author has the write to post is just completely inappropriate. The author has the right to his opinions and to voice them. This is not the appropriate forum.
Re: Bottom feeders
On Thu, 21 Dec 2000, Ken Hornstein wrote: That hasn't been my experience; I've seen what can only be described as an "old-boy" network in operation. I'm not saying that such a thing is necessarily bad, just that sometimes it takes significant effort to overcome it if you're a newbie. Both the "old-boy" network and the undue skepticism are natural and occur in every field. My intuition is, if you try to suppress them, they'll show up in other ways! On the other hand, I was a first-timer at the 49th IETF (although I was already known to some in mmedia wg before), and had a rather atrocious proposal to lobby for (see my I-D - you *can't* possibly believe it at first reading :-). I've seen no less openness and no more skepticism at the IETF than within my own organisation. I think the people are wonderful, including many "old timers" - I quite enjoyed the many first-hand stories in the many hallway discussions. But here is the difference between your first time experience and those of others. You were already known in one of the WG communities; and you came with an I-D that you were trying to build support for. In other words, you were a participant rather than a lurker. You are exactly the type of first timers that should come to IETF meetings. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. SSH soon to follow.
Re: Bottom feeders
We *should* worry about people who come to the IETF once and never come back - because they probably came to the wrong meeting, and went home unhappy. interesting idea. so assuming that a lot of folks come to the IETF expecting something different than it is, and going home disappointed, what can we do to make future prospective attendees more aware of what they're getting into? Keith I don't know if this is done or not, but all first time registrants should be sent an e-mail suggesting that they read the Internet-Standards Process and Newcommer's Orientation presentation. Plus be advised that they should attend the orientation on Sunday. I remember my first trip to IETF. I thought that I could simply arrive and get a standard adopted. That was three years ago. Many RFCs later I'm still here. But it is not because involving myself in the IETF was easy. For a long time I felt like an outsider. Even after attending a year's worth of meetings. But I kept attending because I had something that I wanted/needed to accomplish. I think the important point to remember is that we attend IETF to accomplish a specific technical goal (developing an internet standard). We are not here to be a part of a fraternity;to find a job; not to find employees; to find authors; to disrupt others; ... I welcome all to attend IETF meetings. But I want people to attend that are going to do work; not make it more difficult for me to accomplish my work. If people come to IETF unprepared and without the intention to actively contribute to standards development and then leave disappointed and frustrated, I'm not sure that is a bad thing.
Looking for Lyrics to the IETF Xmas song
Sorry for the wasted bandwidth. But could someone please post the lyrics to the IETF Christmas song, the video that was shown at the Plenary. Thanks. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. SSH soon to follow.
Re: NATs *ARE* evil!
You know, concerns over global name spaces and architectural purity are valid to the engineer/operator. But to Joe User who just got his first cable modem and got rid of AOL, he just wants to connect his computer to the Internet. Then he wants to share that connection with his kids' computer and their $50 e-bay printer server. That's why so many of the little NAT gadgets are sold. Because Joe User doesn't want to shell out extra bucks for more IP addresses and Joe User needs simplicity. Also _most_ average users just want to browse the web, get their email, download software, and maybe exchange music files. It is up to the networking professionals to make sure Big Company X and Big Company Y connect when and where they have to. But its up to Joe User to manage his home network. Lets try to at least make that simple for Mr. and Mrs. Joe User. Funny. I believe that is why the cable companies are giving each user 5 or 6 IP addresses. To make it easy so that the end user doesn't need to know how to manage a NAT. The answer is to give people the address space they need, not force them to understand the subtle problems that are caused by the use of NATs. You have no idea how many students complain that they can't access campus services due to the fact that Kerberos can't work through a NAT. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. SSH soon to follow.
Re: 49th-IETF conf room planning
This suggestion will I hope generate much heated discussion. We could always ask the working group chairs to identify the contributing members. Those who submit Internet-Drafts can also be added to the list. These members like the WG Chairs, ADs, ... can have stickers added to their badges. Those without badges can be asked to leave when space gets tight. It makes absolutely no sense to have someone pre-pay a meeting fee, pay to travel to a location, attempt to attend a meeting, and be turned-away. I disagree in the strongest possible terms. it makes a great deal of sense if the purpose of the meeting is to get technical work done, rather than to spoonfeed people who can't be bothered to read the background material. and we're seeing entirely too much spoonfeeding in meetings these days - witness the tremendous amount of precious meeting time that is devoted to presentations of *material already explained in the relevant drafts*, rather than discussion. OTOH I happen to feel that it's quite useful if IETF folks who actively participate in some WGs, drop in on the meetings of other WGs. we need to encourage cross-pollenation between groups. but we don't need to encourage non-participants to attend IETF meetings. In addition, turning away people who wish to attend seems counter to the IETF spirit. the IETF spirit has always been to include anyone *who does his/her homework* Keith Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. SSH soon to follow.
RE: end-to-end w/i-Mode? (was Re: imode far superior to wap)
You haven't given a single technical argument that will convince
system experts in these big corporations that they have dug themselves
a "very nice hole". The meaningless rhetoric "WAP is bad" doesn't
convince any one.
The problem that WAP has is that it is not used for end to end
connections. WAP will protect the data from the wireless device to a
proxy server which must be able to decrypt the data so that it can be
retransmitted over a SSL/TLS connection to the real HTTP server.
That means that I as a corporate service provider MUST trust the
wireless provider's security and their promise not to look at my
data. I'm sorry, but this is not a system that I will rely on.
Since WAP is not end to end, it is of no use to me.
Jeffrey Altman * Sr.Software Designer
The Kermit Project * Columbia University
612 West 115th St * New York, NY * 10025 * USA
http://www.kermit-project.org/ * [EMAIL PROTECTED]
Re: fyi.. House Committee Passes Bill Limiting Spam E-Mail
Perhaps one of the solution would be to limit the amount of addressees one
email can go out to simultaneously. Imagine Joe Spammer would have to send
out his junk say to max 30 addresses at a time. Or even 100. It would not
impair normal users because we do not send mail to more than a few addresses
at a time - but it would make spamming a little more difficult.
I already hear the argument: There'd be "solutions" to circumvent this
limitation faster than it would be implemented. Still I think it is worth
the debate. What do you think?
The premise is not true. When planning parties or even
volleyball tournaments I frequently send out e-mail to several hundred
friends. This is not spam. Arbitrary limits are not the answer.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
Re: draft-ietf-nat-protocol-complications-02.txt
% even if you do this the end system identifier needs to be globally % scoped, and you need to be able to use the end system identifier % from anywhere in the net, as a means to reach that end system. % %DNS is a bright and successfull example of such deal. % % actually, DNS is slow, unreliable, and often out of sync with reality. % % DNS reverse lookup tables (PTR) are not as well maintained as forward % lookup tables (A) so they're even less reliable. This is an assertion that I've heard over the years and I've come to beleive (based on regular audits of the in-addr space) that this is an Internet equivalent of an urban legend. I'd really like to see your backing data on this. This is hardly an urban legend. Columbia University requires the use of tcpwrappers in Paranoid mode which requires that the forward and reverse lookups for an IP address in DNS match. The Kermit Project is based at Columbia University and uses its systems for our FTP and HTTP access. A week does not go by when we do not get complaints about people being unable to access our FTP server due to a failure of the forward and reverse to match. Just from the first 8 hours of logs today: proxauth3-bb2.globalintranet.net != 212.234.59.254 hide193.nhs.uk != 195.107.47.193 marta-c-gw.caravan.ru != 212.24.53.234 su9127.eclipse.co.uk != 212.104.136.138 Granted this is hardly a scientific study. But we see this from approximately a dozen new addresses every day. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
Re: IPv6: Past mistakes repeated?
Users shouldn't care or know about the network's internal addressing. Some of the application issues with NATs spring directly from this issue (e.g. user of X-terminal setting display based on IP address instead of DNS name). it's not the same issue. the point of using IP addresses in DISPLAY variables is not to make them visible to the user - it's because using the IP address is (in a non-NATted network) far more reliable than depending on the DNS lookup to work. the fact that doing this makes the address more visible to the user is just a side effect; most users don't care diddly about it one way or the other as long as it works. Keith The default DISPLAY variable for an X Server on the local machine is unix:0 This means contact the 0th display attached to the 0th X Server on the local machine. When you make a connection to a remote machine you cannot count on the return from gethostname() is going to have any relationship to the name in the DNS. Not to mention that on a multi-homed machine you need to be able to choose the IP address that is actually accessible to the remote. So what you do is look at the IP address on the local end of the socket that is being used to connect to the remote system and insert that IP address into the exported DISPLAY variable. This has of course worked for 20 years and fails when a NAT is in the middle. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
Re: draft-ietf-nat-protocol-complications-02.txt
doesn't this require the NAT to use the same inside-outside address binding for the connection between the client and the KDC as for the connection between the client and the application server? e.g. it seems like the NAT could easily change address bindings during the lifetime of a ticket. True. However, the same problem applies without NAT if the client changes address bindings, so I wouldn't say this is really a NAT-related problem. Under what conditions transparent to the user does a client change address bindings? Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
Re: draft-ietf-nat-protocol-complications-02.txt
At 09:59 AM 4/20/00 -0400, Jeffrey Altman wrote: This draft is very incomplete and in my opinion not ready for prime time. The working group has in the past requested lists of protocols and applications which do not work with NATs. I have replied discussing those items for which I am most familiar: [...snipped] I think everyone agrees that the draft is incomplete. I've been begging for input for over a year now in the NAT WG meetings and on the NAT list. I've also asked every IETF WG chair for input. Our hope is that through IETF last call, we will get enough contributions such as yours to get a reasonable document together that folks can reference. I am not on the NAT mailing list; nor do I attend NAT working group meetings. I consider NATs to be architecturally unsound and that the IETF and IESG should in no way endorse their use or development. All of the energy and money being spent on NATs could and should be spent to begin the migration to IPv6 instead. It is my hope now that Windows 2000 supports IPSec that enough pressure will be applied to halt the deployment of NATs Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
Re: IETF Adelaide and interim meetings for APPS WGs
The problem I have with the Adelaide meeting is very simple. With so few working groups holding sessions, I can't justify making the trip. This would be true for a meeting at any location more than 400 miles away. If only one group that I am interested in is holding a session, I can't go. The powers that be just won't approve it. So the side effect of not holding a session is that not only have the working groups decided that they do not want the interest and participation of non-U.S. members, but they don't want the interest and participation of U.S. members either. This leads me to question why the working group is in fact a working group in the IETF. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
Re: IP network address assignments/allocations information?
I've generally been of the opinion that NAT is a very workable solution for the small office and home network, and questionable for larger networks. Sounds like you're saying the same. The New York City Board of Education is using NATs as a security measure to keep their 1000+ schools off of the public network. Teachers are reporting that the networks are unusable because of them. Many of the educational benefits that the schools want to gain from being connected to the internet are unaccessible because of the limitations NATs place on the types of connections that may be made (and accepted.) The NYC BOE does not have the money or staff to figure out how to properly configure and maintain these devices. But they were put in place most likely because they were presented to the high level admins as an easy way of securing the network. The teachers (as consumers of the technology) have chosen not to use the Internet in the classroom experience because they can't get the same access from the classroom that they are able to receive from AOL at home. --- The use of NATs in home or small office environment must be voluntary by the end user. It is somewhat scary that an end user must now know enough about NATs to ask their proposed ISP whether or not a NAT is going to be used to allocate them an IP address. And if so, be able to instruct the ISP how it should be configured for them. I forsee a day when the use of NATs and the failure by ISPs to disclose their use will result in lawsuits by Ralph Nadar and the Attorney General's offices of several states for fraudulant advertising. --- NATs are workable solutions for the home environment if and only if they are implemented by knowledgeable people or are used by individuals whose range of Internet access is severely limited. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
Re: Last Call: Telnet Authentication Option to Proposed Standard
Protocols that offer increased complexity but no gain in security or efficiency over other standards-track efforts, but are in use today, are IMHO excellent candidates for Informational publication. Not for the standards track. I think the point of this debate is whether or not there is added strength to the encryption. And so far the opinions have been divergent. If 3DES is a better PRNG than DES then it is stronger. As we point out in the Drafts, the telnet encryption stream mechanism is susceptible to attacks. We know that. We have addressed it in various ways. Unfortunately, the Telnet AUTH option implementations for Kerberos 4, Kerberos 5, and Secure Remote Password all rely on the Telnet Encryption option for privacy. I don't think it is appropriate to send Telnet Auth to Proposed Standard with its reliance on an option that is Informational. Hence, the desire for all of these drafts to go to Proposed Standard. The TN3270 WG is working on a Telnet over TLS draft which has seen several independent interoperable implementations for TN3270 and well as more traditional telnet. My hope is to integrate Telnet over TLS with Telnet AUTH so that Telnet AUTH may be used to provide mutual authentication via a TLS using an ADH cipher. The one problem I have run into is that the TLS Library vendors (other than OpenSSL) have been very resistent to exporting the contents of the Finished messages to the application so that they may be used in the Telnet Auth negotiation to provide mutual authentication of the TLS. Once this draft goes to Proposed Standard I would recommend that the Telnet Encryption option be moved to Historical. But until that happens we need it on the standards track. These drafts have been floating around the net for almost eight years with many implementations. Its time for them to move on. - Jeff Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
Re: Last Call: Telnet Authentication Option to ProposedStandard
I'll go further. THIS ENTIRE PROTOCOL DUPLICATES OTHER STANDARDS TRACK
EFFORTS. I see no reason why it should rise above Experimental and
Informational.
We already have authentication and encryption at link layer (PPP),
network layer (IPSec), transport layer (TLS), and session layer
(SecSHell). Why do we need application layer security, too?
If this were "just" authentication, just as new authentication modes
have been added to protocols (POP3, SMTP) that already have some form of
authentication, it might be useful. But, Telnet has no extant
authentication that is being improved. This is a whole new set of
features, including encryption (not mentioned in the announcement).
Why bother?
Moreover, there is no _required_ option that must be implemented. One
of the most important interoperability design principles is violated.
Finally, the protocol itself seems insecure and subject to denial of
service and monkey in the middle attacks. It's a bad idea.
These options have been in use for eight years and are widely
deployed. Telnet AUTH is currently RFC 1416. We are removing the
man in the middle attack that is possible with that RFC.
Please see my other postings to this thread for a discussion of TLS
and Telnet.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
