Re: Last Call: 'Email Submission Between Independent Networks' to BCP
Keith Moore wrote: >> if you are coming from outside the network, you do not get >> to "relay" through the network. You can post/submit from >> within, you can deliver into the net or you can post/submit >> from outside. > This is wrong. "outside the network" is irrelevant. What > matters is whether you are authorized to use that MTA to > submit messages to recipients not in the domain(s) for which > that MTA is authorized to accept incoming mail. I read "inside" as "something avoiding SMTP AUTH like RADIUS", "outside" as "roaming user, SMTP AUTH or SMTP-after-POP", and the third case is an unknown stranger saying "HELO". Simply 2476 or 2476bis vs. 2821. And what you later said, tricks based on the MAIL FROM, is "enforced submission rights", that's 6.1 in 2476 or 2476bis. > I'm sending comments to IESG separately. They know 2476bis, it was approved some weeks ago. And the relevant parts are the same as in RfC 2476 published 1998. And if they don't like CRAM-MD5 what they'll get is LOGIN or PLAIN _without_ TLS, sigh. Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Email Submission Between Independent Networks' to BCP
On Friday, June 03, 2005 05:27:55 PM -0700 Dave Crocker <[EMAIL PROTECTED]> wrote: In other words, if you are coming from outside the network, you do not get to "relay" through the network. You can post/submit from within, you can deliver into the net or you can post/submit from outside. This, I think is the crux of the problem. The statement above appears to conflate an IP network with an administrative domain, and assumes that something belongs to one if and only if it belongs to the other. Fortunately, that is not what the text Sam originally objected to actually says. The actual text uses the term "local environment": o Mail coming from outside an email operator's local environment, and having a RCPT-TO address that resolves to a destination that is also outside the local environment, MUST be treated as mail submission, rather than mail relaying. Hence it must be subjected to mail submission authorization and validation checks. Now, connections that come from clients not on my IP network may be from authorized submission clients which are outside my "local environment". But, they may also come from clients which are part of my local environment, but do not happen to be on my local network. I might decide that a particular client fits that category because of its authenticated identity, either to SMTP or at some lower layer. I've tried for the better part of an hour to come up with a scenario in which this matters. In particular, _any_ scenario in which a message addressed to a non-local recipient is not either submission or an attack -- whether or not the client is part of the "local environment". I may not have as fertile an imagination or as much operational experience as some people in this thread, but I've tried really, really hard. And I've been completely unable to do so. So maybe whether to treat such messages as "submission" or not is not all that important, especially if it is reasonable under some circumstances to consider a host not on the local IP network to still be part of the "local environment"?? However, I do have another concern with this requirement, and frankly I can't remember whether it's been brought up or not. My concern is with the phrase "resolves to a destination that is also outside the local environment", and how it interacts with things like forwarding. If the CMU.EDU mail exchangers receive a message whose RCPT-TO is [EMAIL PROTECTED], and LDAP says that mail for that address should be delivered to gmail, does that make it an address that resolves to a destination outside the local environment? The document is not clear on this, and I'm very concerned that a wrong answer would result in a lot of incorrectly bounced mail... -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: mac layer in manets
Alex, sometimes 'SIR' can be used by someone to show his/her sincerity and loyalty when in need of assistance. It was simple to tell Prasanna to subscribe at http://www.isi.edu/nsnam/ns/ns-lists.html Joe. On Fri, 2005-06-10 at 01:04, Alexandru Petrescu wrote: > Prasanna S.J wrote: > > hello sir, > > > > this is prasanna research student in SERC,IISc,Banglore. > > Hey Prasanna. > > > sir i am working on bandwidth utilization and power control in adhoc > > n/ws. if it is possible to give some idea regarding basic power > > control i.e. Pmax for control packets such as rts/cts and > > Pmin(minimum necessary power) for data-ack in mac layer. implementing > > this basic mechanism where will be the changes required in ns-2 > > simulator plz inform me. > > "Implementation" on NS-2 simulator can be discussed on the NS-2 mailing > list. I think there are more chances to find people with direct > experience on power-aware wireless stuff over there. > > > sir if any other materials regarding this plz inform me > > google 802.11b power Pmax gives http://www.wilmaproject.org/mdgd-p.pdf > which says Pmax 20mw (14dBm) and min useful signal power 1.0pW (-60dBm). > > > sir plz guide me in all possibilities regarding this work. i am > > waiting for your reply... > > ... please don't call me "Sir" :-) I am not. One could call somebody > "Sir" if he held that British title, Sir Elton John is an example, > otherwise why not just calling her/him by his/her first name... > > When writing to the ietf mailing list there is little chance that a > Sir - and even less a King - will reply, I think. > > Alex > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf -- -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Joseph C. Mushi, Wuhan University of Technology, School of Information Engineering, Wuhan, P. R. China. Tel: +86-13886077432 (Mobile) +86-27-87874805 (Home) +86-27-87298927 (Lab.) -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Email Submission Between Independent Networks' to BCP
Sam is correct here - the text as written is incorrect, even if it accurately reflects the authors' intent. You mean that you disagree with the authors' intent. That is quite different from the document being "incorrect". I meant what I said. You may infer that it is my opinion, and take that for what you think it's worth. Ok. Please explain precisely what text in the draft is "incorrect" and what is "incorrect" about it. You have been sent a copy of my last call comments that I sent to IESG. If you need clarification, please let me know. I gave a case analysis for 3 conditions. I believe none of them was wrong and that there is not a fourth case. If you feel otherwise, please provide detail. I didn't see a clear breakdown of those cases. A Friday, 5:27pm posting from me: "In other words, if you are coming from outside the network, you do not get to "relay" through the network. You can post/submit from within, you can deliver into the net or you can post/submit from outside." okay, fine. first, it's less than general to assume that there is a network that is "the network" associated with the MSA. second, depending on source IP address for authentication or an indication of trustworthiness is of limited applicability - though there may be cases where it's reasonable to do, it's not reasonable to do in general, and it's not reasonable to expect these cases to apply to all MTAs. and in particular I don't think it's reasonable to treat a source IP address as an indication of trustworthiness unless you reliably know _who_ is associated with that source IP address, and that imposes several constraints on how you operate your network that are not generally met by IP networks. (if memory serves, we don't usually consider authentication by source address to be "BCP" material, though I believe that it may be reasonable to do so in this case as long as appropriate constraints are identified) finally, I believe it is simpler and clearer to treat the case where the client authenticates to the MSA/MTA via SMTP AUTH and the case where the client authenticates to the MSA/MTA via source IP address as the same case. In effect, either (a) you're both authenticated (by any of a variety of means) and authorized to relay mail to domains (not networks) other than those for which the MTA is authorized to accept mail for, or (b) you're not able to relay mail to domains other than those for which the MTA is authorized to accept mail. if there's a reason for having the MTA treat clients that are authenticated via source IP address differently from clients that are authenticated by other means, I haven't seen it. Again, I believe you are confusing what your own views and preferences are, with some sort of independent, objective reality. I could make the same claim about what you seem to be doing. Yes, you could. But that would be incorrect. You are entitled to your opinion :) "Outside the network" is exactly what we felt was relevant. It might be dandy to phrase this as some more generic issue, but since this is an operations document, for consumption by operations people, it is phrased in a way that is useful to THEIR perspective. This perspective is specific to MSAs that are operated by IP networks for the customers of those IP networks. Actually it is not. It specifies a topological distinction that is quite straightforward and has nothing to do with any business relationship, per se. I could try to nail down the details, but I suspect it's a rathole. I think the burden is on you to explain why "the network" (which I take to be the IP source address) is _in general_ relevant to whether an MTA/MSA should accept mail for relaying to domains other than those it is authorized to accept incoming mail for. If all of an MSA's users access the MSA from networks other than the one that the MSA is on, then all the users are "outside the network". or maybe there is no "the network". The document uses the term 'submission' to refer to the hand-off step. It quite carefully distinguishes between the two ports through which submission is currently done. I don't see any effort to distinguish the two, say in section 2. Section 2, Terminology. Definition of the word submission: "At the origination end, an MUA works on behalf of end users to create a message and perform initial "submission" into the transmission infrastructure, that's not a definition, that's a use of the word. here's my concern about treating this concept in a fuzzy fashion - while it's all well and good to say MTAs should not accept nonlocal mail from unauthenticated users (i.e. no third party relaying), we really don't want to encourage MTAs to perform the kinds of munging that MSAs are allowed to perform. so it's far better to say "MTAs should not accept mail to nonlocal users from una
Re: Last Call: 'Email Submission Between Independent Networks' to BCP
The current document purports to be a candidate for BCP and yet it recommends a practice which is clearly no longer appropriate. clearly? please provide a citation to any sort of official consensus statement that establishes this clarity. you seem to be confusing two things - technical quality and community consensus. both are necessary conditions for approving the document. but they are not the same thing. or to put it another way - a) it should be clear to you that CRAM-MD5 has known weaknesses that would make it unlikely to be suitable for BCP b) it should also be clear to you that a BCP candidate that recommends CRAM-MD5 is unlikely to gain consensus Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Email Submission Between Independent Networks' to BCP
> The current document purports to be a candidate for BCP and yet it > recommends a practice which is clearly no longer appropriate. clearly? please provide a citation to any sort of official consensus statement that establishes this clarity. an ietf formal publication would be preferred for the obvious reasons, but a reasonable substitute would likely suffice. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Email Submission Between Independent Networks' to BCP
> > > Sam is correct here - the text as written is incorrect, even if it > > > accurately reflects the authors' intent. > > > > > You mean that you disagree with the authors' intent. That is quite > > different from the document being "incorrect". > > > I meant what I said. You may infer that it is my opinion, and take > that for what you think it's worth. Ok. Please explain precisely what text in the draft is "incorrect" and what is "incorrect" about it. What you wrote means that you are asserting that we did not mean treat as submission. And I'll just bet that's not what you actually meant. > > I gave a case analysis for 3 conditions. I believe none of them > > was wrong and > > that there is not a fourth case. If you feel otherwise, please > > provide detail. > > > I didn't see a clear breakdown of those cases. A Friday, 5:27pm posting from me: "In other words, if you are coming from outside the network, you do not get to "relay" through the network. You can post/submit from within, you can deliver into the net or you can post/submit from outside." > > Again, I believe you are confusing what your own views and preferences > > are, with some sort of independent, objective reality. > > > I could make the same claim about what you seem to be doing. Yes, you could. But that would be incorrect. > > "Outside the network" is exactly what we felt was relevant. It might be > > dandy to phrase this as some more generic issue, but since this is an > > operations document, for consumption by operations people, it is phrased > > in a way that is useful to THEIR perspective. > > > This perspective is specific to MSAs that are operated by IP networks > for the customers of those IP networks. Actually it is not. It specifies a topological distinction that is quite straightforward and has nothing to do with any business relationship, per se. If all of an MSA's users access the MSA from networks other than the one that the MSA is on, then all the users are "outside the network". > > The document uses the term 'submission' to refer to the hand-off > > step. It quite > > carefully distinguishes between the two ports through which > > submission is > > currently done. > > > I don't see any effort to distinguish the two, say in section 2. Section 2, Terminology. Definition of the word submission: "At the origination end, an MUA works on behalf of end users to create a message and perform initial "submission" into the transmission infrastructure," Whereas references to the services on different ports is... gosh. By port number. If you want text changed, then please suggest specific changes. > Indeed, it appears that the document uses several vague terms without > bothering to define them. Speaking of vagueness, please review your sentence, directly above, and explain to me what specific references it makes and what specific changes it calls for. > no, that's not what I meant. I meant "treating a message received by > an MTA as a submission has never been well defined". Given that section 3 discussion the construct extensively, then I cannot guess what more you are looking for. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Email Submission Between Independent Networks' to BCP
The line of discussion about a particular algorithm reflects the rather unfortunately tendency to have every system-level effort involving security get dragged into low-level debates about basic algorithms and about the current views of various experts in the security community. That's no way to run a standards effort. The current document purports to be a candidate for BCP and yet it recommends a practice which is clearly no longer appropriate.In light of the information provided it should be obvious that it's not acceptable in its current form. The fix should also be obvious, and the resulting document (with other edits as needed for clarity) seems quite useful, timely, and appropriate. This discussion isn' t holding back the document, it's helping provide feedback on what kinds of edits are needed to get the document approved. If anything, one of the authors is holding back the document. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Email Submission Between Independent Networks' to BCP
The implications you are drawing are exactly what is intended. When the document said "treat as a submission" it meant exactly that. Sam is correct here - the text as written is incorrect, even if it accurately reflects the authors' intent. You mean that you disagree with the authors' intent. That is quite different from the document being "incorrect". I meant what I said. You may infer that it is my opinion, and take that for what you think it's worth. In other words, if you are coming from outside the network, you do not get to "relay" through the network. You can post/submit from within, you can deliver into the net or you can post/submit from outside. This is wrong. "outside the network" is irrelevant. What matters is whether you are authorized to use that MTA to submit messages to recipients not in the domain(s) for which that MTA is authorized to accept incoming mail. I gave a case analysis for 3 conditions. I believe none of them was wrong and that there is not a fourth case. If you feel otherwise, please provide detail. I didn't see a clear breakdown of those cases. Again, I believe you are confusing what your own views and preferences are, with some sort of independent, objective reality. I could make the same claim about what you seem to be doing. "Outside the network" is exactly what we felt was relevant. It might be dandy to phrase this as some more generic issue, but since this is an operations document, for consumption by operations people, it is phrased in a way that is useful to THEIR perspective. This perspective is specific to MSAs that are operated by IP networks for the customers of those IP networks. This is a less-than-general perspective, as there are MSAs that are independent of IP networks, and IP networks may wish to outsource mail service. Since the email architecture delegates MTA authority on a per-domain basis (via DNS and MX records), rather than by IP address blocks, the document would be more broadly applicable if it were rewritten to separate the concept of "operating environment" from the concept of domain. If you're going to make a document that is narrowly scoped than that, you should at least state the scope. Of course, if a user's identity is reliably known from his source IP address, combined with the knowledge an operator has that its network is adequately protected against source IP spoofing, this might reasonably be considered sufficient authentication for that user. But this should probably be stated explicitly and precisely rather than buried in the undefined concept of operating environment. And the question of whether a user should be able to use a particular server for message submission, or whether a message is treated as a submission, probably shouldn't depend on _how_ a user has authenticated - whether by passwords over TLS or TLS client certs or by PPPoE to the provider's network (as indicated by source IP address) - so long as the user's identity is reliably known. There seems to be some ambiguity between treating an incoming message as a submission and using the SUBMISSION protocol. Well, I don't see the ambiguity, but I do see the confusion. Submission is a hand-off from the From/Sender user realm to the mail handling service. SUBMISSION is a particular port and service for doing submissions. The document uses the term 'submission' to refer to the hand-off step. It quite carefully distinguishes between the two ports through which submission is currently done. I don't see any effort to distinguish the two, say in section 2. Indeed, it appears that the document uses several vague terms without bothering to define them. It seems prudent to clearly distinguish the two. And since treating an incoming message as a submission has never been well-defined, the term "incoming" is what causes the problem here. For every server, every message that it receives is "incoming". that is true for msa's as well as mtas. agreed. however i suspect what you mean, here, is 'coming from outside the network'. since you earlier said that it is irrelevant, i'm not sure what your point is, here. no, that's not what I meant. I meant "treating a message received by an MTA as a submission has never been well defined". Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Email Submission Between Independent Networks' to BCP
> The environment has changed a great deal. I don't know why people > thought MITM attacks weren't feasible in 1996 -- Joncheray published a > paper on how to carry them out in 1995 -- but they're now trivial. There are some meta-problems with this thread. (Aside: John K has raised his own perspective on some of them and I'd like to try to raise mine. I don't see them as conflicting with John's, but rather I'd like to treat them as separate just to avoid having to worry about synchronization. If they overlap with his, fine. If not, well, that's fine too.) This draft BCP touts some basic practices to improve the accountability of mail systems that are injecting messages into the global Internet. It cites a range of specifics, for performing those practises, notably with respect to some security functions. Mostly, it cites those specifics in order to make give body to the higher-level recommendations it is making. It does not particularly recommend one over the other, nor do I believe it should. Notably it does not invent any technologies or practices. Rather it tries to document and recommend some broad operations practices that are established and that result in some general improvements in the email service. The line of discussion about a particular algorithm reflects the rather unfortunately tendency to have every system-level effort involving security get dragged into low-level debates about basic algorithms and about the current views of various experts in the security community. That's no way to run a standards effort. First, if the algorithm in question is so terrible, surely the large number of folks using it would be experiencing some problems by now. It is not as if we are lacking in attackers exploiting easy holes in Internet services. And surely there would have been global alarums raised about this algorithm, given its widespread use and it weakenesses. The current reality is that the ops and apps areas get to play a guessing game, in the sure and certain knowledge that they will guess wrong. The security community will always find fault with our choices. Unless and until the security community can provide the applications and operations community some common "packages" to use, just as transport, network management and routing do, then we are never, ever going to make serious progress using meaningful security. Yes, I know the arguments for why this is difficult. And yes, I know that security folk claim it is impossible because every service is unique. That's not good enough. If the security is going to press for use of good security, then it needs to provide far more turn-key solutions to those developing services. Simply requiring that every service be developed with security expertise and solutions that are unique to the service is a model that clearly does not... scale. Having debates about what is currently in vogue among various experts is a fine thing to do... among the experts. But it is entirely inappropriate to have these spontaneous debates in the middle of pursuing a document specifying current practises. If there is consensus among the security community that particular, established practises are no longer viable, then please go through the usual IETF processes for documenting community consensus about it. At that point, it will make sense for the operations and development community to adjust what it specifies. Until then we are stuck with the vagaries of individual opinions and as I recall, that's not what the IETF is supposed to be driven by. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Email Submission Between Independent Networks' to BCP
"Kurt D. Zeilenga" <[EMAIL PROTECTED]> writes: > It is my recommendation that the mandatory-to-implement > "strong" authentication mechanism for this protocol be either: > DIGEST-MD5 (with a mandate that implementations > support its data security layers) > TLS+PLAIN (with a recommendation that PLAIN not > be used when TLS is not in use). I don't think recommending the DIGEST-MD5 security layers is a good idea. The integrity layer is hard coded to be HMAC-MD5, with keys derived using a home-grown key-derivation function based on MD5. Of the privacy layers, only des and 3des were mandatory to implement in RFC 2831, and both ciphers were dropped in RFC 2831bis, presumable because they were never implemented correctly nor successfully deployed. Either situation alone should be enough to avoid recommending its use for IETF protocols, in my opinion. I believe the code complexity cost of DIGEST-MD5 generally outweigh the small advantages that DIGEST-MD5 may have, for the majority of users. This is why, in my perception, DIGEST-MD5 hasn't "taken off". The lack of cryptographic analysis and cryptographic flexibility doesn't improve the situation. TLS+PLAIN seem like a fine recommendation, though. Cheers, Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Email Submission Between Independent Networks' to BCP
Keith, > > The implications you are drawing are exactly what is intended. When the > > document said "treat as a submission" it meant exactly that. > > > Sam is correct here - the text as written is incorrect, even if it > accurately reflects the authors' intent. You mean that you disagree with the authors' intent. That is quite different from the document being "incorrect". The document says what we meant, including the implications. If there is a factual error -- and that is what "incorrect" means -- then please state it. > > In other words, if you are coming from outside the network, you do not > > get to "relay" through the network. You can post/submit from within, > > you can deliver into the net or you can post/submit from outside. > > > This is wrong. "outside the network" is irrelevant. What matters is > whether you are authorized to use that MTA to submit messages to > recipients not in the domain(s) for which that MTA is authorized to accept > incoming mail. I gave a case analysis for 3 conditions. I believe none of them was wrong and that there is not a fourth case. If you feel otherwise, please provide detail. Again, I believe you are confusing what your own views and preferences are, with some sort of independent, objective reality. "Outside the network" is exactly what we felt was relevant. It might be dandy to phrase this as some more generic issue, but since this is an operations document, for consumption by operations people, it is phrased in a way that is useful to THEIR perspective. > > SUBMISSION is relatively recent and it's use is still only for a portion > > of the posting traffic on the Internet. From a practical standpoint, > > port 25 is still heavily used; so that the two types of traffic are > > still frequently multiplexed over 25. Hence any BCP concerning initial > > posting needs to cover both ports. > > > There seems to be some ambiguity between treating an incoming > message as a submission and using the SUBMISSION protocol. Well, I don't see the ambiguity, but I do see the confusion. Submission is a hand-off from the From/Sender user realm to the mail handling service. SUBMISSION is a particular port and service for doing submissions. The document uses the term 'submission' to refer to the hand-off step. It quite carefully distinguishes between the two ports through which submission is currently done. If you see any ambiguity, please explain where and what. > It seems prudent to clearly distinguish the two. And since treating > an incoming message as a submission has never been well-defined, the term "incoming" is what causes the problem here. For every server, every message that it receives is "incoming". that is true for msa's as well as mtas. however i suspect what you mean, here, is 'coming from outside the network'. since you earlier said that it is irrelevant, i'm not sure what your point is, here. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Email Submission Between Independent Networks' to BCP
> > The good part of this requirement seems to be to subject such mail to > > authorization (and in many cases authentication). However I think > > that saying mail must be treated as submission rather than relaying > > may have effects significantly beyond authorization/authentication. > > For example MSAs are given significant freedom to modify submitted > > That's right. > > The implications you are drawing are exactly what is intended. When the > document said "treat as a submission" it meant exactly that. Sam is correct here - the text as written is incorrect, even if it accurately reflects the authors' intent. > In other words, if you are coming from outside the network, you do not get to > "relay" through the network. You can post/submit from within, you can > deliver > into the net or you can post/submit from outside. This is wrong. "outside the network" is irrelevant. What matters is whether you are authorized to use that MTA to submit messages to recipients not in the domain(s) for which that MTA is authorized to accept incoming mail. > >Also, mail relaying > > and submission have different protocols defined by different > > specifications. For the most part these protocols are interoperable > > but the requirement seems overly strict given this situation. > > SUBMISSION is relatively recent and it's use is still only for a portion > of the posting traffic on the Internet. From a practical standpoint, port > 25 is still heavily used; so that the two types of traffic are still > frequently multiplexed over 25. Hence any BCP concerning initial posting > needs to cover both ports. There seems to be some ambiguity between treating an incoming message as a submission and using the SUBMISSION protocol. It seems prudent to clearly distinguish the two. And since treating an incoming message as a submission has never been well-defined, perhaps a different way of describing what an MTA should do when an unauthenticted sender tries to send to a recipient not in a domain for which the MTA is authorized to accept incoming mail, would be appropriate. bottom line: the spec as written is poorly worded and needs significant revision. I'm sending comments to IESG separately. (and yes, I found the same problem that Sam did, before I read his message) Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An interesting sub-note for all of you using the xml tool for drafts
Hi Frank, On 2005-06-09 20:29 Frank Ellermann said the following: > Brian E Carpenter wrote: > >> See http://ietf.levkowetz.com/tools/idnits/idnits.pyht > > I never got the idnits webservice version to do anything else > but show its 'usage' info. No idea what's wrong, maybe it's > only my browser. But ml2rfc and Bill's validator work online, > his ABNF checker is also very nice. Bye, Frank !! Ok, I'll have to find out what's up here, then. Taking this off list, with a follow-up letter to Frank to work out what's the matter. Henrik ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
In message <[EMAIL PROTECTED]>, Ned Freed writes: >> From where I sat, the problem was trying to ensure that a WG thought >> about an issue. Neither mandatory material nor checkoff boxes >> accomplish that, but I think the former is often more useful because >> material in an I-D is visible to the entire WG. > >I disagree completely and think you have this exactly backwards. Mandatory >material would only help if people actually think about what goes in it - whic >h >they don't. Rather, they think about it as "another something we have to do to >get past the IESG" and deal with it by spending as little time on it as >possible. Sure -- I saw a lot of that when I was on the IESG. Too often, I would say "in your Security Considerations section, you need to think about X, Y, and Z" -- and I'd get back a new document saying "think about X, Y, and Z". >Even worse, the presence of a section that says "these are all the IANA >considerations" or "there are no IANA considerations here" is likely to cause >reviewers to assume that someone has already checked for IANA actions. This >will lead to more omissions, not less. > >And in fact there has already been at least one example of this happening. The >document draft-ietf-lemonade-mms-mapping-04.txt is now in the RFC Editor's >queue. It's IANA considerations section says "no IANA actions". Alas, the >document defines any number of new header fields that need to be placed in the >appropriate header regsitry. > >That IANA considerations section sure helped a lot, didn't it? You can lead a horse to water I agree -- there are no panaceas here. It's a question of what will help the most, not what will solve the problem. > >Like it or not, careful reviews and review checklists, while quited flawed in >their own right, are the best tool we have. When I was on the IESG I had my own >private review checklist; it was the only thing I found that worked. Such reviews are certainly necessary. The question is this: what policy is most likely to reduce the incidence of such things? We'll never eliminate it. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
> From where I sat, the problem was trying to ensure that a WG thought > about an issue. Neither mandatory material nor checkoff boxes > accomplish that, but I think the former is often more useful because > material in an I-D is visible to the entire WG. I disagree completely and think you have this exactly backwards. Mandatory material would only help if people actually think about what goes in it - which they don't. Rather, they think about it as "another something we have to do to get past the IESG" and deal with it by spending as little time on it as possible. Even worse, the presence of a section that says "these are all the IANA considerations" or "there are no IANA considerations here" is likely to cause reviewers to assume that someone has already checked for IANA actions. This will lead to more omissions, not less. And in fact there has already been at least one example of this happening. The document draft-ietf-lemonade-mms-mapping-04.txt is now in the RFC Editor's queue. It's IANA considerations section says "no IANA actions". Alas, the document defines any number of new header fields that need to be placed in the appropriate header regsitry. That IANA considerations section sure helped a lot, didn't it? Like it or not, careful reviews and review checklists, while quited flawed in their own right, are the best tool we have. When I was on the IESG I had my own private review checklist; it was the only thing I found that worked. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Email Submission Between Independent Networks' to BCP
In message <[EMAIL PROTECTED]>, John C Klensin writes: >The claims about man-in-the-middle attacks are another matter. >When the analysis was done in 1996, the conclusion was that such >attacks were not possible unless either the secrets were already >known to the attacker or there was a plausible attack on >HMAC-MD5 itself. If such attacks are now seen to be plausible, >or if post-authentication session hijacking has become a >dominant concern in practice, it is, as I indicated in my >earlier note, time to document that and to use the documentation >as the basis for explicitly deprecating CRAM-MD5 (or HMAC-MD5 >itself if necessary). The environment has changed a great deal. I don't know why people thought MITM attacks weren't feasible in 1996 -- Joncheray published a paper on how to carry them out in 1995 -- but they're now trivial. There are off-the-shelf tools -- see, for example, Dug Song's dsniff package, and read the man pages for arpspoof, sshmitm, webmitm -- and the advent of wireless has created a fertile ground for such things. (Think about the "evil twin" wireless attacks.) Factor in routing attacks -- they're happening, too -- and you'll see why I'm concerned. For the record, I've seen active attacks on ssh and web in the wild, at the Usenix Security conference and at the IETF itself. And those were without even looking for them. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Email Submission Between Independent Networks' to BCP
Kurt and Sam, I hope someone else will pick up this discussion, as I'm not the right person to lead it. I would encourage you to read and react to Simon's comments as a start. However, let me make a couple of additional observations: * CRAM-MD5 was caused because folks in the security area said "no more clear text passwords" to applications folks, then more or less stepped away. Whatever the strengths or weaknesses of either clear text passwords or CRAM-MD5, it was considered an advantage at the time that they provided authentication, and authentication only. In particular, an authentication-only model, with no attempt or pretense at privacy or integrity protection for message content, avoids entanglements with any national or trans-border restrictions that might exist (or be imagined) on encryption, law enforcement access to keys, etc. Now sometimes that is ok, and sometimes it isn't. I am often reminded of a conversation with an MIT senior faculty member some years ago about exposure of information in a generally-accessible shared-printer environment. Her response to my concern was that, if someone decided to pull her material off the printer and read it, maybe they would learn something and that was what she and the Institute were all about. It all depends on the circumstances. * There is a huge difference between telling a user or implementer, in a Security Considerations section or otherwise, "hey, CRAM-MD5 just provides authentication and no privacy or integrity protection, if you need either of those, you need to use it with something else or use something else entirely" and saying "we have decided, in our wisdom, that authentication-only solutions are inadequate for you and should be discouraged". The claims about man-in-the-middle attacks are another matter. When the analysis was done in 1996, the conclusion was that such attacks were not possible unless either the secrets were already known to the attacker or there was a plausible attack on HMAC-MD5 itself. If such attacks are now seen to be plausible, or if post-authentication session hijacking has become a dominant concern in practice, it is, as I indicated in my earlier note, time to document that and to use the documentation as the basis for explicitly deprecating CRAM-MD5 (or HMAC-MD5 itself if necessary). Similarly, if there is really consensus in the IETF community that authentication without message integrity protection, etc., are useless or worse, then it is time to document that opinion and the associated consensus and see if we can start persuading implementers and the marketplace to move on. But, in the presence of a fairly broad installed base and interoperable implementations, I suggest that far more is needed that the personal preferences of the two of you, or even the personal preferences of the entire security community, before it is reasonable to start recommending against the continued use of a widely-deployed practice. IMO, such a recommendation has to be considered a very serious step, especially when the practice was started as the consequence of some rather specific IETF recommendations. We should consider "never mind what we said a decade ago about clear text passwords, protected or not; we now prefer such passwords when sent through encrypted tunnels to be preferable to challenge-response models" to be a fairly serious step in terms of IETF credibility if nothing else and should not take it unless we have clear documentation and clear consensus, not just changes in taste. john --On Thursday, 09 June, 2005 06:36 -0700 "Kurt D. Zeilenga" <[EMAIL PROTECTED]> wrote: > My personal view (e.g., SASL chair hat off) is that CRAM-MD5 > use on the Internet should be limited. It fails to provide > any form of data security itself. The lack of integrity > protection means sessions are subject to hijacking. While > this inadequacy can be addressed by protecting the session > with TLS, if TLS is used then it becomes a real toss-up > between CRAM-MD5 and PLAIN. While CRAM-MD5 might be viewed > by some as better, I note that PLAIN provides for better > interoperability in systems involving external password > stores (especially in face of string preparation requirements > to be added in revisions of PLAIN and CRAM-MD5 specifications), > and provides support for proxy authorization (identity > assumption). > > It is my recommendation that the mandatory-to-implement > "strong" authentication mechanism for this protocol be either: > DIGEST-MD5 (with a mandate that implementations > support its data security layers) > TLS+PLAIN (with a recommendation that PLAIN not > be used when TLS is not in use). > > I have slight preference for the latter. > > Kurt > > At 03:52 PM 6/8/2005, Sam Hartman wrote: >> Hi. I'm not in a good position to write a long response now; >> let me know if you do end up wanting a longer response and >> you'll get it in a week or so.
Re: An interesting sub-note for all of you using the xml tool for drafts
Brian E Carpenter wrote: > See http://ietf.levkowetz.com/tools/idnits/idnits.pyht I never got the idnits webservice version to do anything else but show its 'usage' info. No idea what's wrong, maybe it's only my browser. But ml2rfc and Bill's validator work online, his ABNF checker is also very nice. Bye, Frank -- -- -- -- -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Wed June 8 2005 14:30, Ned Freed wrote: > > The IETF Internet-Drafts page notes that "All Internet-Drafts that are > > submitted to the IESG for consideration as RFCs must conform to the > > requirements specified in the I-D Checklist". The current version of > > the ID-Checklist clearly states: [IANA Considerations section is REQUIRED] > That's most unfortunate. What do we need to do to get this silly and > counterproductive requirement removed? (pessimist hat on) Nothing. Just ignore it; everybody does. The rule, such as it is, isn't enforced. (pessimist hat off) I think "counterproductive" is at best quite a stretch. > The problem is that requiring such a section creates no such assurance. Of course. But it does encourage thought (both by authors/editors and reviewers). Surely you're not suggesting that authors, editors, and reviewers should ignore IANA considerations. The problem (N.B. pessimist hat is off) is that we now have the worst of all possible situations: o The rule exists in some random documents buried on some web sites, and the documents have no status as RFC or BCP; as far as I can tell there are no immediate plans to change that (one of the documents is an Internet-Draft which is now nearly 11 months old) o BCP 14 language is used with a normative reference to BCP 14, implying that this is a matter taken seriously; the document using that language comes from the IESG, but as noted above has no standing as BCP o Although it is expressed as REQUIRED, and: i. it is referenced either directly or indirectly from several places ii. there exist tools (e.g. idnits) which quickly and accurately determines if the requirement is met the rule is not enforced (or is at best selectively enforced) These things are at odds (e.g. there is little point in a requirement, expressed in strong terms (but in somewhat obscure documents with no official standing) which is ignored), yet are self-reinforcing (if the rule isn't enforced, it's hardly surprising that authors and editors ignore it, nor is it surprising that some IETFers seem to be unaware of requirements in documents that have no standing and are hidden in obscure places). If the IESG really doesn't care, it could indicate so consistently by: 1. reissuing the guidelines without BCP 14 language and burying the document deeper on the IETF web site; keep the document unofficial, make random changes at random times, and remove all version indications (or further obscure those indications by making the gray text on the gray background in the current HTML-only document even lower contrast and smaller size, and/or use an uglier markup language) 2. keep the 2223bis draft in limbo for a few more years and/or ask the RFC Editor to elide the part about a null IANA Considerations section [obviously, some of the comments immediately above are tongue-in-cheek] Conversely, if the IESG does regard the matter as important, it could: 1. direct the IETF Secretariat to enforce the rule (given the fact that idnits already checks for it, as well as checking for IPR boilerplate issues -- which the Secretariat does enforce with an iron fist -- I don't buy the argument that checking would impose an inordinate cost. In fact I suspect that the incremental cost would be smaller than that of any instrumentation that might be applied to measure that cost) 2. publish the guidelines as BCP and move forward on the 2223bis draft ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: mac layer in manets
Prasanna S.J wrote: > hello sir, > > this is prasanna research student in SERC,IISc,Banglore. Hey Prasanna. > sir i am working on bandwidth utilization and power control in adhoc > n/ws. if it is possible to give some idea regarding basic power > control i.e. Pmax for control packets such as rts/cts and > Pmin(minimum necessary power) for data-ack in mac layer. implementing > this basic mechanism where will be the changes required in ns-2 > simulator plz inform me. "Implementation" on NS-2 simulator can be discussed on the NS-2 mailing list. I think there are more chances to find people with direct experience on power-aware wireless stuff over there. > sir if any other materials regarding this plz inform me google 802.11b power Pmax gives http://www.wilmaproject.org/mdgd-p.pdf which says Pmax 20mw (14dBm) and min useful signal power 1.0pW (-60dBm). > sir plz guide me in all possibilities regarding this work. i am > waiting for your reply... ... please don't call me "Sir" :-) I am not. One could call somebody "Sir" if he held that British title, Sir Elton John is an example, otherwise why not just calling her/him by his/her first name... When writing to the ietf mailing list there is little chance that a Sir - and even less a King - will reply, I think. Alex ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IAB DNS choices 02
Someone suggested that I repeat this post I made to namedroppers on the main list. The reference to "wayne" refers to the message archived at: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00864.html oo The forwarded message oo Date: Thu, 9 Jun 2005 10:51:49 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis <[EMAIL PROTECTED]> Subject: IAB DNS choices 02 Cc: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] X-Mlf-Threat: nothreat X-Mlf-Threat-Detailed: nothreat;none;none Referring to http://www.ietf.org/internet-drafts/draft-iab-dns-choices-02.txt This is going to be a lengthy email, because I want to discuss this issue from an different perspective than I've seen from others on the mailing list. I saw the comments from wayne <[EMAIL PROTECTED]> on this document. I have a different perspective, I think, in that I want to protect the future of the DNS. (I don't mean to say he's out to hurt the DNS, his objective is to meet the needs of application developers - also a worthy goal.) My stipulation is that the DNS is a developed, healthy protocol and system, positioned at the core of Internet operations. Although it is heavily used, it is not threatened (as much as some what to exclaim). Being at the core means that any change to it causes many ripples in the Internet, that a conservative approach to changes is wise. From this viewpoint, my conclusion about the paper is that it is making the correct recommendation, to rely on the use of new RR types to "extend" the DNS. This is in contrast with wayne's conclusion (somewhat) but like he, I agree the paper is somewhat "pollyanna-ish" in it's justifications. The paper reminds me of RFC 2826, "IAB Technical Comment on the Unique DNS Root", published in 2000. A unique DNS root is beneficial for the Internet. But because of this RFC, conducting large-scale DNS experiments, such as is needed for DNSSEC, has been hindered. The reality is that once a system becomes as crucial to operations as DNS has, you can no longer tinker with it without endangering it's stability. The moral here is that you need a test environment for experimentation, separate from the operational environment. Because of the cited RFC, there has been resistance and reluctance to set up and join in the needed large scale (time, distance, and volume) testing needed to safely introduce DNSSEC into the operational DNS. I bring this up because that situation and the situation wayne has been describing reflects what I think has been a large shift in the dynamics of innovation in the Internet over time, and in the past decade (plus). It used to be that people could afford the time to gab informally about what they wanted to accomplish, implement the ideas in quick manner and then document the experiences. At the time, the Internet could afford outages (it was not critical infrastructure in any way) although it was fairly sound. The stability arose from the higher per capita expertise in operations and a smaller workload. Today that is not the case. The IETF recognizes this as well as industry. The IETF has responded by formalizing the gab sessions into requirements documents and (say) formal processes for reserving IANA numbers. Industry has responded in different ways, by either implementing minimally what they need regardless of the full specification, innovating without consulting the IETF first, or rolling out contract and/or regulatory agreements presupposing the environment. Coming back to the document at hand, I think what needs to be examined is "how does someone, beginning from scratch, develop a new application that needs to put data in the DNS get this application to specified in a standard?" I'm not interested in "what it means to be a standard" but more about "how does the process get a proper DNS record type?" Skipping ahead to the day where the developer realizes "hey, I need to put this factiod in the DNS." Once the RR's RDATA contents are determined, there needs to be a place to put it (name), assume class IN, and a type code. For simplicity, let's say the name relates to either a host or zone, so it's fairly obvious where the factoid RR will be sitting in the DNS tree. What is done about the RR type? The relevant RFC, assuming that there is an obvious lead to this, is RFC 2929. In this, it says that the type code numbers from 65280 to 65535 are available for private use. Since the state of the work is early, that is the proper number to use. Getting a reserved RR type number requires "IETF consensus." That has is rumored to take a long time. ;) So, what is likely to happen is that implementation and testing will happen using what's at hand - the "private use" number. Eventually, IANA allocates a type code number. What happens next? Well, all of the new implementations should go out there with the new type code and that is where every one should move the records
Re: The IETF Golden Rules
Nice list. How about adding: - Be very suspicious of centralized solutions that encourage monopolies and may introduce single points of failure. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
At 15:38 09/06/2005, Brian E Carpenter wrote: Please see RFC 2434 = BCP 26 Dear Brian, I was probably not clear enough. Bruce quoted RFCs, and others points postdate RFC 2434. Current http://www.iana.org site is not the best documentation site I saw. It said two things: 1. a IANA related obligations registry. Where obligations to IANA, authors, users, etc. would be registered and easily displayed. 2. in the IANA considerations to explicit the way IANA overload will be fought. This last point (with XML registries) is a point under consideration and of concern for those having to fund the IANA as ccTLDs. It might lead to make alternatives being considered earlier than advisable for good transition. For example a daily interruption of IANA registries for an hour or random drops calling for a recall of the requested page, a timer, a copyrigh response first, etc. could be ways to prevent applications designers to call on IANA XML files everytime they need one of their data. jfc Brian JFC (Jefsey) Morfin wrote: Dear Bruce, you know what? I think it would be great to write a IANA obligations RFC. It would say that the IANA MUST maintain a list of all the obligations RFC authors should respect when writting the IANA considerations, and to document whatever additional information IANA may need (for example if a DoS might result from a possible misuse of what they ask and the proposed solutions). jfc At 19:59 08/06/2005, Bruce Lilly wrote: > Re: Last Call: 'Email Submission Between Independent Networks' to BCP > Date: 2005-06-08 10:50 > From: Ned Freed <[EMAIL PROTECTED]> > > .. RFC2119, when used, must be a normative reference. Likewise, > > you'll need to add a "null" IANA considerations section. > > Agreed on the RFC 2119 reference. However, I do not believe there is any > requirement for "null" IANA considerations sections. (A scan of recently > published standards track RFCs turned up several that don't have such a section > - 4022, 4015, etc.) Aren't we paddding out our documents with enough useless > boilerplate already without adding yet another useless section to the mix? The IETF Internet-Drafts page notes that "All Internet-Drafts that are submitted to the IESG for consideration as RFCs must conform to the requirements specified in the I-D Checklist". The current version of the ID-Checklist clearly states: The following are REQUIRED sections in all Internet-Drafts: [...] IANA Considerations A Must specify if IANA has to create a new registry or modify rules for an existing registry. B Must specify if the document requires IANA to assign or update values in an IANA registry before RFC publication. C See "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC2434] and in some cases also "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers" [RFC2780]. In some case "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692] may help as well. D If there is no action for IANA, the section should say that, e.g., including something like "This document has no actions for IANA." And the RFC-Editor's "instructions to RFC Authors" (draft successor to RFC 2223, on hold) notes: Current policy (not documented in [IANA98]) is to include an IANA Considerations section always, even if it is "null", i.e., even if there are no IANA considerations. This is helpful to IANA. However, the RFC Editor may remove any null IANA considerations sections before publication. I believe the requirements exist to ensure that draft authors give due consideration to IANA Considerations and that IANA can readily determine if some action is or is not required. Evidently (and unfortunately) the IETF Secretariat apparently doesn't enforce that part of the ID-Checklist rules. As the RFC Editor removes null sections, you won't find them in published RFCs. But Internet-Drafts are REQUIRED to have them. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
In message <[EMAIL PROTECTED]>, John C Klensin writes: >Brian, > >We agree about the desirability of making sure than some things >are explicitly documented and explicitly part of what gets >reviewed. But I continue to believe, as I have believed for >years, that adding more and more mandatory material to RFCs or >I-Ds is not the best solution to that particular problem. > >From where I sat, the problem was trying to ensure that a WG thought about an issue. Neither mandatory material nor checkoff boxes accomplish that, but I think the former is often more useful because material in an I-D is visible to the entire WG. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The IETF Golden Rules
At 8:15 PM +0200 6/8/05, Jacob Palme wrote: > >Do not comment on the draft in ietf@ietf.org or >[EMAIL PROTECTED], use the new mailing list. There goes your first rule... -- +---+ |"Minds are like parachutes - they only function when open."| +---+ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Brian, We agree about the desirability of making sure than some things are explicitly documented and explicitly part of what gets reviewed. But I continue to believe, as I have believed for years, that adding more and more mandatory material to RFCs or I-Ds is not the best solution to that particular problem. Perhaps, in line with the PROTO effort (and maybe the ISD discussion), it is time to revisit the other approach: rather than cluttering up I-Ds with materials that can be filled out pro-forma and that the RFC Editor may then remove (or not), migrate at least some of these procedural requirements associated with protocol specifications from the I-D to a "submission checklist" that a WG or individual would provide to the IESG as part of the request for Last Call and approval action. That document could contain, e.g., an explicit statement as to whether the WG had examined IANA issues and decided that there were none, rather than just providing pro forma text or boilerplate, as well as draft protocol action statements, etc. The IESG gets more information, in clearer form, and we don't end up with a choice between information getting lost and more clutter in RFCs. Of course, if one were doing ISDs, that text and anything else that relates to the process and context for approving a standard, rather than information key to the protocol specification itself, could, when the spec was approved, be reasonably be transposed into the ISD. john --On Thursday, 09 June, 2005 11:06 +0200 Brian E Carpenter <[EMAIL PROTECTED]> wrote: > Ned Freed wrote: > ... >>> The IETF Internet-Drafts page notes that "All >>> Internet-Drafts that are submitted to the IESG for >>> consideration as RFCs must conform to the requirements >>> specified in the I-D Checklist". The current version of the >>> ID-Checklist clearly states: >> >> >> That's most unfortunate. What do we need to do to get this >> silly and counterproductive requirement removed? > > Enough context has been removed that I don't know quite what > you're > objecting to, but the intent of the I-D checklist is to avoid > the IESG having to kick back documents for trivia, so you can > argue about what should or shouldn't be in the checklist, but > you surely can't argue against it being used for its intended > purpose. > >>> I believe the requirements exist to ensure that draft >>> authors give due consideration to IANA Considerations and >>> that IANA can readily determine if some action is or is not >>> required. > > There is another purpose IMHO: ensure that future readers > (implementers > and deployers of the technology) know whether they need to > deal with > any IANA registration issues. For this reason, I have a > strongly held > opinion that null IANA Considerations sections should *not* be > removed. > >> The problem is that requiring such a section creates no such >> assurance. I've seen any number of documents with IANA >> considerations that initially failed to list all the >> considerations. > > Yes indeed, and I see a lot of IESG DISCUSSes on exactly this > point. > >> And given past experience with "security >> considerations: none" sections, there is no reason to believe >> that requiring such a section will actually result in IANA >> considerations being properly called out. In fact I'd say >> there's a good chance it will cause obscure considerations to >> be missed. > > I think experience shows otherwise: the fact that reviewers, > including the > IESG, are paying increasing attention to this section is in > fact catching > omissions. > >> Like it or not, boilerplate is not now and never will be a >> useful subsitute for careful review. > > I agree > >> And as the pile of useless crap we require gets ever-larger it >> gets harder, not easier, to get that review. > > I disagree. Actually, the mandatory presence of this section > *triggers* > review (see above comment). > >>> Evidently (and unfortunately) the >>> IETF Secretariat apparently doesn't enforce that part of the >>> ID-Checklist rules. > > The ID-Nits tool checks it and the future automated submission > tool will > check a lot more than the Secretariat can do manually. > > Brian > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
The IETF Golden Rules
I have written an Internet Draft on the IETF Golden Rules which may be very controversial. Abstract: This memo presents the following rules, which to some extend can be regarded as the golden rules of IETF, even though there are exceptions when these rules should not be adhered to. - Be liberal in what you accept, and conservative in what you send - Do not munge forwarded data - Modify as late as possible - Cause no harm - Leave nothing undefined - Keep it simple, stupid - No voting, rough consensus - Plain ASCII text is enough I have started a mailing list to discuss this draft, so that people not interested don't have to participate. To subscribe to the mailing list, go to http://lists.dsv.su.se/cgi-bin/mailman/listinfo/ietf-golden/ Do not comment on the draft in ietf@ietf.org or [EMAIL PROTECTED], use the new mailing list. -- Professor Jacob Palme <[EMAIL PROTECTED]> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/jpalme/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Please see RFC 2434 = BCP 26 Brian JFC (Jefsey) Morfin wrote: Dear Bruce, you know what? I think it would be great to write a IANA obligations RFC. It would say that the IANA MUST maintain a list of all the obligations RFC authors should respect when writting the IANA considerations, and to document whatever additional information IANA may need (for example if a DoS might result from a possible misuse of what they ask and the proposed solutions). jfc At 19:59 08/06/2005, Bruce Lilly wrote: > Re: Last Call: 'Email Submission Between Independent Networks' to BCP > Date: 2005-06-08 10:50 > From: Ned Freed <[EMAIL PROTECTED]> > > .. RFC2119, when used, must be a normative reference. Likewise, > > you'll need to add a "null" IANA considerations section. > > Agreed on the RFC 2119 reference. However, I do not believe there is any > requirement for "null" IANA considerations sections. (A scan of recently > published standards track RFCs turned up several that don't have such a section > - 4022, 4015, etc.) Aren't we paddding out our documents with enough useless > boilerplate already without adding yet another useless section to the mix? The IETF Internet-Drafts page notes that "All Internet-Drafts that are submitted to the IESG for consideration as RFCs must conform to the requirements specified in the I-D Checklist". The current version of the ID-Checklist clearly states: The following are REQUIRED sections in all Internet-Drafts: [...] IANA Considerations A Must specify if IANA has to create a new registry or modify rules for an existing registry. B Must specify if the document requires IANA to assign or update values in an IANA registry before RFC publication. C See "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC2434] and in some cases also "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers" [RFC2780]. In some case "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692] may help as well. D If there is no action for IANA, the section should say that, e.g., including something like "This document has no actions for IANA." And the RFC-Editor's "instructions to RFC Authors" (draft successor to RFC 2223, on hold) notes: Current policy (not documented in [IANA98]) is to include an IANA Considerations section always, even if it is "null", i.e., even if there are no IANA considerations. This is helpful to IANA. However, the RFC Editor may remove any null IANA considerations sections before publication. I believe the requirements exist to ensure that draft authors give due consideration to IANA Considerations and that IANA can readily determine if some action is or is not required. Evidently (and unfortunately) the IETF Secretariat apparently doesn't enforce that part of the ID-Checklist rules. As the RFC Editor removes null sections, you won't find them in published RFCs. But Internet-Drafts are REQUIRED to have them. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Email Submission Between Independent Networks' to BCP
My personal view (e.g., SASL chair hat off) is that CRAM-MD5 use on the Internet should be limited. It fails to provide any form of data security itself. The lack of integrity protection means sessions are subject to hijacking. While this inadequacy can be addressed by protecting the session with TLS, if TLS is used then it becomes a real toss-up between CRAM-MD5 and PLAIN. While CRAM-MD5 might be viewed by some as better, I note that PLAIN provides for better interoperability in systems involving external password stores (especially in face of string preparation requirements to be added in revisions of PLAIN and CRAM-MD5 specifications), and provides support for proxy authorization (identity assumption). It is my recommendation that the mandatory-to-implement "strong" authentication mechanism for this protocol be either: DIGEST-MD5 (with a mandate that implementations support its data security layers) TLS+PLAIN (with a recommendation that PLAIN not be used when TLS is not in use). I have slight preference for the latter. Kurt At 03:52 PM 6/8/2005, Sam Hartman wrote: >Hi. I'm not in a good position to write a long response now; let me >know if you do end up wanting a longer response and you'll get it in a >week or so. > >I don't think cram-md5 is a reasonable best current practice. I think >it is accurate to describe it as a common practice. > >It's my recollection that cram-md5 is vulnerable to man-in-the-middle >attacks but digest-md5 is not. It's also my recollection that >digest-md5 will do a much better job of supporting servers that do not >want to store plaintext equivalents than cram-md5. The server will >store a secret that is sufficient to log into that server but may not >be sufficient to log into other servers. > > >Digest-md5 also supports an integrity and confidentiality layer. > >I think all of the above are significant advantages over cram-md5. > >If you are concerned that digest-md5 is not sufficiently widely >implemented then let's recommend plain+tls and digest-md5. I think >those are two low-infrastructure protocols in wide use. > >___ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An interesting sub-note for all of you using the xml tool for drafts
On 6/9/05, Brian E Carpenter <[EMAIL PROTECTED]> wrote: > It's not illogical - if your source file says > you get exactly what you asked for, i.e. the > obsolete boilerplate. The id-nits tool will warn you - it is > well worth running that before submitting *any* I-D, whether produced > by xml2rfc or another method. Another tool that is worth running on the xml source before using xml2rfc on it is at http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/ ; it will check that the source is well-formed and valid according to the DTD (XML generated outside of a validating editor is often not valid, and sometimes even not well-formed, even though xml2rfc creates a fine-looking document from it), and also checks for various other errors including the IPR requested. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Email Submission Between Independent Networks' to BCP
Ned Freed <[EMAIL PROTECTED]> wrote: > [Pekka Savola <[EMAIL PROTECTED]> wrote:] >> On Wed, 8 Jun 2005, Ned Freed wrote: >>> [Pekka Savola <[EMAIL PROTECTED]> wrote:] >>> A practical issue I have with this doc is that the recommendations are relatively few, and most of them are rather generic or vague. Haven't we learned more on email BCPs by now? >>> >>> What we have learned and what we are able to reach consensus on are two >>> very different things. I submit they are not different after all: where we are unable to reach consensus, there's a _strong_ indication that not all of us have learned the lesson yet. There _are_ genuine areas of difficulty in reaching consensus, alas. These need to be explored... >> My point is that when we are writing a document like this, making it >> intentionally very generic and vague seems much less useful. > > And my point is that a less generic document we cannot reach consensus on > is and which therefore cannot be published of no use at all to anyone. And here we have the war of the generations. :^( (I call it the war of the generations because the _typical_ youngster believes the world can be conquered before breakfast, while the _typical_ oldster has failed to conquer the world so often as to have given up trying. In point of fact, though, I'm a definite oldster but I'm on Pekka's side here.) We could easily lather, rinse, and repeat those two statements, getting nowhere. Or we could easily have Pekka make specific suggestions, each of which could be shot down by some weird case; and lather, rinse, repeat... Stepping back a bit, we note that Pekka is standing on grounds of vagueness -- the sands shifting so fast as to obscure our sight -- while Ned is standing on grounds of Catch-22 -- daring us to try to find a consensus that he (or his friends) can't torpedo. We need to find common grounds on which to argue this, or we're doomed to "lather, rinse, repeat". :^( When I was younger, I liked to propose where to find the common grounds; I was even pretty decent at making successful suggestions. But I'm not young anymore: so until one or the other shows some interest in finding common grounds, I'm content to watch from the sidelines. However... There's an issue for all of us here: we are evolving into a paradigm where the IESG can't agree to form a Working Group to tackle a known problem (this is particularly obvious where spam is concerned); so they wait for individual submissions; the individual submissions provoke controversy; the controversy gets aired a bit on the IETF general list; no consensus ensues; and eventually the IESG agrees that consensus will never be reached, so it's better to publish what we have. This has obvious implications for the quality of documents approved by the IESG. The implications are perhaps less obvious on the quality of people _willing_ to serve on the IESG. (I'm still completely amazed that Brian agreed to do so!) My point is that "Consensus will never be reached!" is a self-fulfilling prophesy if we never even try the methods we have evolved for doing so. These include: - forming a group which includes enough folks interested in a solution; - designating a moderator empowered to redirect efforts towards a goal; - designating a document editor to propose language; - issuing consensus calls on pieces of the solution; - exposing the consensus to review by non-participants; - et cetera... I've seen a lot of stuff on this list claiming that the IESG has only itself to blame if its workload increases, because it was foolish enough to create too many Working Groups. I've been biting my tongue, trying to avoid shouting, "TANSSATMWG!" (There ain't no such thing as too many Working Groups.) I know a lot of folks disagree with me there: that the "primary" job of the IESG is managing Working Groups, so there must be some limit to how many they can manage. I would respond that the IETF seems tolerant of most any management scheme the IESG may choose; so there's no reason they couldn't manage thousands of Working Groups. This would, I admit, require some changes in paradigms: - Working Groups would not automatically deserve a session at meetings; - dissolution would be automatic with some level of inactivity; - Area Directors would not necessarily follow every mailing-list; - (I could continue, but you get the idea...) I must question whether the IESG sees management of Working Groups as its primary goal: I think there's increasing evidence that they see Quality-Control of RFCs as their primary goal, and that they have become as suspicious of the quality of Working-Group drafts as they are of individual submissions. If so, this is sad, and I wish we could change it. -- John Leslie <[EMAIL PROTECTED]> ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Dear Bruce, you know what? I think it would be great to write a IANA obligations RFC. It would say that the IANA MUST maintain a list of all the obligations RFC authors should respect when writting the IANA considerations, and to document whatever additional information IANA may need (for example if a DoS might result from a possible misuse of what they ask and the proposed solutions). jfc At 19:59 08/06/2005, Bruce Lilly wrote: > Re: Last Call: 'Email Submission Between Independent Networks' to BCP > Date: 2005-06-08 10:50 > From: Ned Freed <[EMAIL PROTECTED]> > > .. RFC2119, when used, must be a normative reference. Likewise, > > you'll need to add a "null" IANA considerations section. > > Agreed on the RFC 2119 reference. However, I do not believe there is any > requirement for "null" IANA considerations sections. (A scan of recently > published standards track RFCs turned up several that don't have such a section > - 4022, 4015, etc.) Aren't we paddding out our documents with enough useless > boilerplate already without adding yet another useless section to the mix? The IETF Internet-Drafts page notes that "All Internet-Drafts that are submitted to the IESG for consideration as RFCs must conform to the requirements specified in the I-D Checklist". The current version of the ID-Checklist clearly states: The following are REQUIRED sections in all Internet-Drafts: [...] IANA Considerations A Must specify if IANA has to create a new registry or modify rules for an existing registry. B Must specify if the document requires IANA to assign or update values in an IANA registry before RFC publication. C See "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC2434] and in some cases also "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers" [RFC2780]. In some case "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692] may help as well. D If there is no action for IANA, the section should say that, e.g., including something like "This document has no actions for IANA." And the RFC-Editor's "instructions to RFC Authors" (draft successor to RFC 2223, on hold) notes: Current policy (not documented in [IANA98]) is to include an IANA Considerations section always, even if it is "null", i.e., even if there are no IANA considerations. This is helpful to IANA. However, the RFC Editor may remove any null IANA considerations sections before publication. I believe the requirements exist to ensure that draft authors give due consideration to IANA Considerations and that IANA can readily determine if some action is or is not required. Evidently (and unfortunately) the IETF Secretariat apparently doesn't enforce that part of the ID-Checklist rules. As the RFC Editor removes null sections, you won't find them in published RFCs. But Internet-Drafts are REQUIRED to have them. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Ned Freed wrote: ... The IETF Internet-Drafts page notes that "All Internet-Drafts that are submitted to the IESG for consideration as RFCs must conform to the requirements specified in the I-D Checklist". The current version of the ID-Checklist clearly states: That's most unfortunate. What do we need to do to get this silly and counterproductive requirement removed? Enough context has been removed that I don't know quite what you're objecting to, but the intent of the I-D checklist is to avoid the IESG having to kick back documents for trivia, so you can argue about what should or shouldn't be in the checklist, but you surely can't argue against it being used for its intended purpose. I believe the requirements exist to ensure that draft authors give due consideration to IANA Considerations and that IANA can readily determine if some action is or is not required. There is another purpose IMHO: ensure that future readers (implementers and deployers of the technology) know whether they need to deal with any IANA registration issues. For this reason, I have a strongly held opinion that null IANA Considerations sections should *not* be removed. The problem is that requiring such a section creates no such assurance. I've seen any number of documents with IANA considerations that initially failed to list all the considerations. Yes indeed, and I see a lot of IESG DISCUSSes on exactly this point. And given past experience with "security considerations: none" sections, there is no reason to believe that requiring such a section will actually result in IANA considerations being properly called out. In fact I'd say there's a good chance it will cause obscure considerations to be missed. I think experience shows otherwise: the fact that reviewers, including the IESG, are paying increasing attention to this section is in fact catching omissions. Like it or not, boilerplate is not now and never will be a useful subsitute for careful review. I agree And as the pile of useless crap we require gets ever-larger it gets harder, not easier, to get that review. I disagree. Actually, the mandatory presence of this section *triggers* review (see above comment). Evidently (and unfortunately) the IETF Secretariat apparently doesn't enforce that part of the ID-Checklist rules. The ID-Nits tool checks it and the future automated submission tool will check a lot more than the Secretariat can do manually. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An interesting sub-note for all of you using the xml tool for drafts
Carl Malamud wrote: Randall's method works, or you can do what the readme suggests: see: http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html#ipr A number of us, including the IETF Chair, have discovered this experimentally. It's not illogical - if your source file says you get exactly what you asked for, i.e. the obsolete boilerplate. The id-nits tool will warn you - it is well worth running that before submitting *any* I-D, whether produced by xml2rfc or another method. See http://ietf.levkowetz.com/tools/idnits/idnits.pyht Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
