Re: OpenDNS today announced it has adopted DNSCurve to secure DNS
On Wed, 24 Feb 2010 12:44:10 -0500 Phillip Hallam-Baker hal...@gmail.com wrote: The problem here is not that you might infringe the patent, the problem is that if a patent suit is brought against you, it will cost a minimum of about $5 million to defend. Just to get to the point of having an opinion on the matter you would have to engage a competent expert witness who was willing to work on patent stuff rather than building stuff. Then they have to do maybe a months work on research and explain the results to a group of lawyers. You are going to have five or more people and rack up several thousand hours at lawyer rates. Those costs buy a lot of crypto accelerator boards. I kept trying to explain this situation to the various people who tried to sell their 'efficient CRL' hacks. Even if your system is the greatest ever and you give it to me for free, it will cost more to work out if it is legally safe than it costs to solve the problem with raw CPU power. If the 512 byte limit really is a problem, then the logical answer would be to use DSA-SHA256 since the signatures generated in DSA are not a function of the key size. DSA also allows for offline calculation of the signature data which would address performance issues for companies like Akamai. There are also reasons to beware of DSA. Steve Bellovin pointed out that if the random number generator is bad the private key can leak out. But RSA is not without similar issues, companies that can't generate a good random seed for DSA will probably not create secure keypairs for RSA either. I've pointed it out in the IETF, but I'm certainly not the one who came up with that observation in the first place; please do not give me credit for other folks' work. More on-topic: unless I'm very much mistaken, DNScurve relies on transmission security rather than object security; in turn, that requires a pretty fundamental change in how the DNS works. (Well, not completely, but you wouldn't gain any security benefit against most of the threats from cache contamination if you didn't change it.) Maybe the DNS can work that way or should work that way -- but I haven't seen any analysis to show that the load is manageable without caching and with lots of banging on the authoritative servers. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
On Mon, 23 Nov 2009 08:16:49 -0500 Scott Brim scott.b...@gmail.com wrote: Simon Josefsson allegedly wrote on 11/23/2009 5:03 AM: John-Luc said he is bound by confidentiality obligations from his company, and I think the same applies to most employees of larger organizations. There is nothing explicit in BCP 79 to protect against this apparent conflict of interest, or is there? Since disclosure is required for anyone submitting documents or participating in IETF discussions, a person who does not disclose IPR for this reason, or any other reason, must not contribute to or participate in IETF activities with respect to technologies that he or she reasonably and personally knows to be Covered by IPR which he or she will not disclose. Precisely. The conflict Simon mentions was of course known to most of the WG; that's one reason we have that clause. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Fri, 18 Sep 2009 11:12:59 -0500 Matt Crawford craw...@fnal.gov wrote: On Sep 18, 2009, at 10:42 AM, Marshall Eubanks wrote: We are therefore asking for input from the community by two means - by commenting on the IETF discussion list, ... I'm trying to imagine the thought police remaining calm during a plenary such as the one at Danvers. I can't quite picture it. Speaking of Danvers -- what is the situation -- theory and practice -- regarding encrypted transmissions to/from such a meeting? I think that a high percentage of IETF attendees are using various sorts of VPNs and/or encrypted tunnels for email retrieval, remote login, etc. Note that I'm assuming they don't care much if we discuss cryptographic technology (i.e., they're happy for the Security Area to meet). I'm just talking ordinary, day-to-day activities for many participants. N.B. It is extremely unlikely that I'd attend a meeting in that slot, regardless of where it was; my current $DAYJOB doesn't give me the luxury of attending most IETF meetings. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Some more background on the RFID experiment in Hiroshima
I'm with Eric on this. Part of our dog food is a decent regard for security and privacy; we shouldn't neglect in the name of experimentation. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication UsingOnly A Password) to Informational RFC
On Tue, 21 Jul 2009 17:54:23 -0700 (PDT) Dan Harkins dhark...@lounge.org wrote: If specification of patented algorithms and drafts subject to IPR disclosure is not enough to knock a draft of the Standards Track then I don't know why FUD about a possible patent _maybe_ existing that _might_ apply is. I'm no longer an AD, but if I were, I'd propose a policy that the IESG automatically disregard any objection to a spec on the grounds that it uses a patented protocol. Folks, the IETF, via the IPR WG (of which I used to be co-chair) explicitly declined to adopt that standard. The policy under which it operates, *by IETF consensus*, is that the WG should decide for any given document if the (vast) disadvantages of an encumbered technology are outweighed by the abilities it grants. I see no reason whatsoever to even consider a generic objection.; that's not what our explicit policy says. I should note that I have no opinions on the merits of this draft compared with an EKE-based alternative, though I should also note that (a) I'm the coinventor of EKE, and (b) as far as I know the US patent on EKE (5,241,599) doesn't expire until October 1, 2011. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Stockholm airport
By chance (I assume it was chance), CNN's travel section just ran a piece on Stockholm: http://www.cnn.com/2009/TRAVEL/getaways/07/21/stockholm.travel/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Steve Coya
On Sat, 6 Jun 2009 14:53:36 -0400 Steve Crocker st...@shinkuro.com wrote: This is indeed sad news. Steve was energetic and dedicated, and we all benefitted greatly from his contributions. Indeed. He will be missed. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Security of BGP Re: Status of the 16-bit AS Number space
On Tue, 12 May 2009 09:25:07 -0400 Phillip Hallam-Baker hal...@gmail.com wrote: Looks to me that we have an obscurity based 'security' system going on there. Everyone in the business understands that there is a routing security problem. There is some disagreement about the magnitude of the threat, and hence about how much one should spend on defense (as opposed to cleaning up afterwards), but there is no disagreement that there is a problem. On the other hand, none of the previous proposals solves it properly; all of the proposed solutions have their own serious flaws. At RSA there was a presentation on security holes in IPSEC and SSH. In the IPSEC case the response 'from the IETF' (i.e. from a well known individual speaking on his own behalf) was that the security issues with using IPSEC without authentication were well known and that this is not new. To which the reply came, well why did you continue to make support for encryption only mandatory? Your writing here is unclear. I assume you mean that current IPsec standards support encryption-only without authentication. I agree -- that was a bad decision by the WG. It was not done blindly, or in ignorance of the attacks. The case was made that there are some situations (video over IP with per-connection keying, for example), when the attacks are inapplicable and the costs are high. The WG was persuaded that this need overrode the potential for misuse. As I said, I did and do disagree. There is unfortunately a naive view that we can solve the BGP security issue by simply sprinkling some IPSEC pixie dust on it. I've been working on routing security for 20 years. I've never heard *anyone* competent suggest IPsec for this problem. Next straw man, please? I think that view is based on a profound misunderstanding of what is possible with a packet layer security protocol. Key agreement and crypto-packaging are trivial problems that can be solved by a moderately competent grad student. The hard part is the problem that IPSEC never solved, how to establish the trust context. And once you look at that problem you soon realize that IPSEC is the wrong tool entirely as the routing problem requires you to take an accountability approach which in turn requires you to work at the message level. `May the day not be too long delayed,' said Boromir. 'For though I do not ask for aid, we need it. It would comfort us to know that others fought also with all the means that they have.' `Then be comforted,' said Elrond. `For there are other powers and realms that you know not, and they are hidden from you. Anduin the Great flows past many shores, ere it comes to Argonath and the Gates of Gondor.' Tolkien, Lord of the Rings There are many people still trying to figure out how to solve this one. It's a hard problem. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Security of BGP Re: Status of the 16-bit AS Number space
On Tue, 12 May 2009 15:42:26 -0400 Phillip Hallam-Baker hal...@gmail.com wrote: We can all agree on the fact there is a problem. That does nothing. What matters to me is if we plan to do something about it before crunch time comes. As for adding IPSEC to BGP, I would not want to comment on the competence of the person involved. I will merely note that maybe the proposal suffers from an over enthusiasm for a protocol they are heavily invested in and an under-appreciation of the issues involved. Before agreeing that the problem is 'hard', I would like to see someone set out the security requirements with respect to a credible operations model. In particular I find it utterly unbelievable that large backbone corporation A is going to configure its border routers to simply accept routing information from large backboe corporation B. If I was responsible for large corporation A then every piece of external routing data would be funnelled into a control center and the edge routers would only respond to control instructions from the control center. No matter what specifications and standards might opine, that is how I would run my network. When you do run an ISP, let me know how well that actually works. We thus have two BGP security problems, an internal security problem that can be solve adequately with existing infrastructure and an inter-network BGP security problem that has some very difficult trust issues to manage but certainly does not need to involve the cryptographic capabilities of router hardware. I would not generate my routing tables on a router. The inter-network BGP security problem can then in turn be broken down into the problem of binding an IP address block to an AS number and securing the anouncement of routs for an AS number. The first is relatively straightforward as the bindings are global. They can be generated by the IP address block holder using a signature key advertised through reverse DNS. The second is hard as routing data requires us to consider a transitive trust problem. Yes -- we all know that. The devil is in the details. I don't think we can prevent an attacker from inserting a bogus route. We can however deploy mechanisms that provide for accountability so that parties who do introduce bogus routes are detected and face consequences. And depending on the resources we are prepared to apply we can make the deployment window really short. I think the cost function goes up very rapidly as deployment time gets shorter. But let's do some arithmetic. First -- there are no fully-specified protocols on the table today that (in my opinion) are acceptable. What we have are a variety of research prototypes that are not adequate for production use on today's Internet. But let's suppose that someone has one in his or her back pocket and will post the I-D tomorrow. Then what? Do we want the IETF's imprimatur? Even if nothing is changed (and experience suggests that that's unlikely), the process will take about a year, if only to give people enough time to actually look at it in Stockholm, Hiroshima, etc. Next, Cisco and Juniper have to go off and design, code, and test. Meanwhile, other parties -- ISPs, RIRs, perhaps IANA, perhaps end-sites that speak BGP -- need to develop their own software and databases to manage the certificates that are required. Design of processes -- how does an AS get a certificate? What about sites with their own AS# but who do not wish to generate a key pair? -- takes time as well. Perhaps that will overlap the router code development. I don't know for sure how long all this will take, but my guess is 1.5-2 years. Remember that this is touching BGP; major ISPs do *not* like to run lightly-tested code trains, especially when BGP is involved. Only at this point can we get to deployment (and figuring out how to pay for it). Here, perhaps, more money can speed things up, though it's rather unclear to me where this extra money will come from. I don't know how long it will take to get the new code deployed throughout enough of the Internet to make a difference, but if hardware accelerators are required (and some past proposals, such as SBGP, would likely require them) it will take noticeably longer. Throwing money at this problem would help, but I don't know where that money would come from. Phil, I agree that securing routing is a big problem. It's the issue that got me interested in Internet security in the first place, 20 years ago! But simply asserting that people don't take it seriously isn't going to solve it. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Subscriptions to ietf-honest
On Mon, 23 Mar 2009 17:35:35 -0400 Melinda Shore melinda.sh...@gmail.com wrote: I was auto-subscribed to Dean's ietf-honest mailing list, and I'm unhappy about it. I don't know what his current status is with regard to the ietf@ietf.org mailing list but I think he's pretty clearly abusing this mailing list by snagging names from it and putting us on his mailing list without asking. I'm also not thrilled that the welcome message he sends out fails to clearly identify who's sending it and that he does not represent the IETF. This is a small problem but a problem nonetheless. It's happened to me twice, with two different lists of his. I've complained to him, but to no avail. I wonder if the CAN SPAM act applies. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
On Tue, 10 Mar 2009 14:21:00 -0400 Richard M Stallman r...@gnu.org wrote: Steve Bellovin wrote: Other than giving up the RFC label for Experimental documents, it's hard to see what the IETF can do. Another thing the IETF could do is stop publishing this sort of document. Anyone that might ask the IETF to publish one can easily publish it on Internet himself. In the cases where an experimental RFC is useful, how is it more useful for the Internet than publication of the same information in some other way? Long ago, before search engines, perhaps interested people would not have found it elsewhere, but that isn't true now. For the same reason that people publish in conferences and journals -- experimental RFCs are peer-reviewed and accessible via a stable mechanism. Of course, the notion of peer review, especially for for-profit journals, has also been challenged, and for the same reasons you cite. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
On Mon, 09 Mar 2009 11:07:10 -0700 SM s...@resistor.net wrote: As the draft was not approved by the IESG as a Proposed Standard, the fact is that most people in the IETF community would not consider it as a proposed standard. The Experimental designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process. Publication as an Experimental RFC does make a document a standard. The Status of This Memo which is prominently displayed on the first page of the RFC mentions that: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Put another way, an Experimental RFC is no more an IETF standard than a conference or journal publication. Someone has done something that is perceived to be of enough interest to the community to publish as an RFC, but it is manifestly *not* an IETF standard of any kind. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
On Mon, 09 Mar 2009 15:35:31 -0700 Stephan Wenger st...@stewe.org wrote: The IETF might view it this way. Large parts of the (standardization) world does not. One example in my field of work is FLUTE, and the surrounding infrastructure of frameworks and FEC codes. To the best of my recollection, these specifications were originally issued as Experimental RFCs, for reasons of congestion control worries. (They are also heavily encumbered, but that was not really an issue according to my recollection.) The Experimental status did not stop 3GPP and other SDOs to normatively reference them, and treat them just like any other IETF RFC. Note that 3GPP could NOT do that with a journal publication... I could name more examples, both when it comes to referencing SDOs and referenced RFC types (including normative references to at least Historic, Obsolete, Informational). This is, I think, the second- or third-most-common topic on the IETF list: should we rename the document series to prevent that... (#1 is non-ASCII formats for RFCs; #2 -- by volume of postings, rather than frequency of discussion -- might be IPR.) Other than giving up the RFC label for Experimental documents, it's hard to see what the IETF can do. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
On Sat, 7 Mar 2009 17:49:54 -1000 David Conrad d...@virtualized.org wrote: Hi, On Mar 7, 2009, at 5:38 PM, Christian Huitema wrote: I agree with Ned. The main purpose of the registry should be to document what is out there, not to act as a gatekeeper. Even when a protocol is not a full standard, having a public documentation is useful. Documentation enables filtering, monitoring, even debugging. This is not how IANA staff have been directed to maintain the IETF registries. That is not how IANA staff has been directed to maintain *some* IETF registries. Typically, the RFC that creates a registry specifies the conditions for it. It may be IETF consensus, or a whole host of other options; see RFC 5226 for more details. The issue here is two-fold: what are the specified conditions for this particular registry, and was the decision of the TLS WG correct when it specified them? Christian's note suggests other code point design strategies that don't run into the limited number of small integers problem. Very true -- and those strategies are explicitly recognized by 5226. There may be a problem here, but it's not the general IANA problem, it's the specific decision made once upon a time. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Terminal room at IETF74
On Mon, 02 Mar 2009 13:16:19 -0500 John C Klensin john-i...@jck.com wrote: This should go on ISOC's list of things to whine to the new US administration about, along with visa request rejections because attending the IETF isn't a good enough reason. It's not just the US; other governments -- including the UK -- have similar policies. See, for example, http://news.bbc.co.uk/1/hi/sci/tech/150465.stm http://www.melonfarmers.co.uk/arlaptop.htm Not that ISOC shouldn't complain -- but it should complain to many governments, and perhaps assorted EU commissions. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposal to create IETF IPR Advisory Board
On Tue, 17 Feb 2009 19:24:20 -0800 Lawrence Rosen lro...@rosenlaw.com wrote: Ted Ts'o wrote: So you've done the equivalent of submit Windows source code and assume that it can be ported to a Unix system left as an exercise to the reader care to give a detailed suggestion about *how* it could be revised to work with the IETF's more open procedures, and still be useful in terms of meeting your stated goals? I've made no such assumptions. I've submitted a couple of process documents from W3C that can be modified easily to fit the IETF model. I thought John and Steven would be satisfied with a rough draft. Sort of like Windows might provide a model for a Linux open source program, without the actual code being yet written. :-) Now that I've submitted this draft, I refuse to be told it isn't a draft, although I admit it isn't in the proper format. Any process bigots want to comment on that flaw tonight too? I specifically said that the W3C Patent and Standards Working Group (PSIG) charter (http://www.w3.org/2004/pp/psig/) and *section 7* of the W3C Patent Policy (http://www.w3.org/Consortium/Patent-Policy-20040205/) would be models for an IETF IPR Advisory Board. Neither of those specific document sections implies anything mandatory about RAND or royalty-free or any other of the political patent battles that divide us. They are merely open process descriptions, just like a draft here ought to be. I think it's a fair start, though I note that 7.5.3 carries with it a fairly strong bias towards royalty-free terms. But let me translate. Rather than a standing board (which was what I thought you had intended), you're suggesting (translated IETF terms) that when a WG encounters a patent thought to be related, a group will be formed consisting of the AD, the WG chair(s) ex officio, representatives of the WG (presumably designated by the chair(s)), perhaps an IAB liason -- and the IETF patent counsel. What is the analog to representatives of each member organization? Volunteers not from the WG? Selected by whom? The usual IETF practice would be appointment by the AD and/or the IAB, I suspect. What would the possible alternatives be? The W3C version has a strong bias towards royalty-free, since that's W3C's overarching policy. The IETF's policy is different, and the board's charge would have to be different. Really, with the exception that it needs legal input, such a group would actually be a design team that is supposed to look at the tradeoffs (per our policies) and make a recommendation to the WG. Anyway -- I think this is a promising suggestion, and not inconsistent with IETF practice or policy. But a fully-fleshed out I-D -- one that addresses the membership and the alternatives -- is probably needed, if only as a matter of form. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposal to create IETF IPR Advisory Board
On Wed, 18 Feb 2009 13:17:39 -0800 Lawrence Rosen lro...@rosenlaw.com wrote: Rather than a standing board (which was what I thought you had intended), [LR:] I had indeed intended a standing board, and still do. Why have to agitate and recruit an expert team over every question, when a simple question referred to an IPR Advisory Board for an answer will probably suffice? But like most of your points in this paragraph, it's open for discussion The advantage of a per-WG board is that members would likely have familiarity with the technology and history of the field. The advantage of a standing board is familiarity with patents and procedures. Pick it... [LR:] Be very careful. No attorney who can be deemed to speak on behalf of IETF regarding patents should be there opining IETF's opinion about actual patents. Instead, I recommend that we have an invited (and probably open) selection of other attorneys who are willing to sign up and actually participate as individuals, not representing specific clients and speaking with appropriate liability caveats. For process purposes, however, the IPR Advisory Board can probably be chaired by an IETF patent counsel just to make sure everyone behaves We'll have to see how many brave attorneys are actually willing to participate in the entire IETF community's behalf, but if W3C is an example, we'll find lots of willing attorneys. :-) I wonder -- the IETF has been known to be hostile to lawyers... Anyway -- I think this is a promising suggestion, and not inconsistent with IETF practice or policy. But a fully-fleshed out I-D -- one that addresses the membership and the alternatives -- is probably needed, if only as a matter of form. [LR:] Ah yes, form. :-) Does anyone else volunteer? Do we have a second? I'll participate, but I sure don't have the cycles to write anything, nor am I likely to be at very many IETF meetings for the PAG WG or even the PAG bar bof... --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposal to create IETF IPR Advisory Board
On Wed, 18 Feb 2009 21:54:49 -0800 Christian Huitema huit...@windows.microsoft.com wrote: This discussion of IPR seems to be running in circle. Can't we switch to something else, e.g. whether RFC could be written in some other format than ASCII text? Sorry, that idea is patented or something. No, I've got it -- it's a W3C trade secret. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposal to create IETF IPR Advisory Board
On Tue, 17 Feb 2009 18:42:17 -0500 (EST) j...@mercury.lcs.mit.edu (Noel Chiappa) wrote: From: John Levine jo...@iecc.com We're looking forward to the draft I hope you're only partially ironic here. If there's no chance whatsoever of such a draft going anywhere, I'd hate to see people, in good faith, put in effort in creating one if it's 100.000% drop-dead guaranteed to be a waste of time. I think the right advisory board would be a good idea, but I'm not optimistic that we'd get one. There's a line from Zelazny's Lord of Light that this reminds me of. Approximately (I don't have the book handy) he asked the storm. The storm never lies... and it always says No!. A board composed solely of, say, FSF afficiaonados would be useless, because the FSF's position on patents isn't nuanced; I'd therefore have trouble believing that their analyses were objective. (Not objective isn't a value judgment or an assertion about the correctness of any particular analysis.) A more important question is what the board should do. Analyze a patent and its claims, and make statements about validity? Leaving out the question of the value of such an activity, when a definitive answer can only come from a court, doing such an analysis is difficult and time-consuming. But I'm not even certain of the value of the answer -- certainly, the large corporations are not going to take this advisory board's word for it; they'll do their own analysis, where the output of the board would simply be more input. And their motives may be different. Consider the case of three large companies, A, B, and C. A asserts that their patent covers some protocol. B, which has a cross-licensing agreement with A, wants it to be valid, because that will keep C (which has no such agreement) and assorted start-ups out of the market. Infringement or non-infringement is a somewhat easier call, though the answer there may depend on implementation choices. Then, of course, there's the whole question of liability. Can the IETF and/or ISOC afford the liability insurance for such a board? Finally, where are we going to get the people? It's hard enough to get sufficient security expertise, and there we don't even have to cross a disciplinary boundary and bring in lawyers. Could we get enough competent people who know enough about enough different protocols *and* about patent law, and are willing to spend (presumably uncompensated) time doing this? I have my doubts. All that said, the above is my strawman that I've just torched. This is why we need a draft -- until we have one, we won't know if it's a plausible, useful idea or not. In fact, a metadraft -- one that simply set out the questions that a concrete proposal should address -- would be a worthwhile contribution in its own regard. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
On Fri, 13 Feb 2009 11:48:08 +0100 Simon Josefsson si...@josefsson.org wrote: Steven M. Bellovin s...@cs.columbia.edu writes: On Thu, 12 Feb 2009 21:38:44 +0100 Simon Josefsson si...@josefsson.org wrote: The discussion started by Stephan suggesting that free software authors publish their work as free standards in the IETF. My point was that since the IETF disallow publishing standards under a license that is compatible with free software licensing (e.g., allows modification), it is not possible for free software authors to do this. Thus, to me, this discussion is not related to comments in source code at all. My understanding of IETF policy is that the IETF will publish I-Ds that are in the public domain. Nothing is freer than that. You're perfectly free to put your text in the public domain before submitting it for publication as an RFC. Sure, but I can also put the text under the Microsoft EULA before submitting it for publication as an RFC. The IETF still requires some assurances from me as contributor, and those assurances go beyond both what the public domain and the Microsoft EULA implies. A more interesting question is if you can submit somebody else's public domain work to the IETF. I don't know the answer to that. Legally, yes; it's public domain. Academic honesty and common courtesy would demand an acknowledgment. It seems clear that I can't take a work licensed under the Microsoft EULA and submit it to the IETF though. Right, which is why I suggested public domain and not the Microsoft EULA More generally: if the goal is to have some text that can be freely used in any software -- proprietary, open source, GPL -- there's nothing more amenable to that than public domain. That may not meet all of the FSF's goals, but I don't really see that that's the IETF's problem. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
On Thu, 12 Feb 2009 21:38:44 +0100 Simon Josefsson si...@josefsson.org wrote: The discussion started by Stephan suggesting that free software authors publish their work as free standards in the IETF. My point was that since the IETF disallow publishing standards under a license that is compatible with free software licensing (e.g., allows modification), it is not possible for free software authors to do this. Thus, to me, this discussion is not related to comments in source code at all. My understanding of IETF policy is that the IETF will publish I-Ds that are in the public domain. Nothing is freer than that. You're perfectly free to put your text in the public domain before submitting it for publication as an RFC. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TLS WG Chair Comments on draft-ietf-tls-authz-07
On Wed, 11 Feb 2009 16:29:05 -0800 Hallam-Baker, Phillip pba...@verisign.com wrote: Could I just point out here the real risk that this relevant objection might get lost in the sea of irrelevant aggitation from the FSF supporters? I agree. Let's move the substantive discussion to the TLS WG mailing list, or at least agree on some secret keyword to put into Subject: lines that I can use for better filtering; I'm on the verge of kill-filing anything with authz or TLS or patent, at least if they appear on the IETF list... --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: why to contact the IETF
On Tue, 10 Feb 2009 10:59:52 -0800 Lawrence Rosen lro...@rosenlaw.com wrote: The result of the FSF campaign has been to raise a legal concern No, they didn't raise the concern. The concern had been raised previously by people who are obviously IETF participants, including Simon Josefsson. (I don't recall if you've posted on this particular I-D, but I obviously put you in the category of IETF participant, too.) obviously important to many of us: Will users of the proposed IETF TLS specification require patent licenses from RedPhone to use such implementations in the US or elsewhere? I don't yet know the answer to this question. Does anyone here? As you well know, the IETF per se doesn't care about the answer to that question. Individual participants may care, of course, and can and should use that information when making their own judgments. More precisely -- the statement the IETF should not standardize draft-chthulhu-shogoth-666.txt because the technology is patented is a NOP according to IETF policies on patented works. The proper formulation is I feel that standardizing draft-chthulhu-shogoth-666.txt is a bad idea because in this particular case, the licensing terms are too onerous for the benefit gained, perhaps with a suggestion that some other technology be adopted instead. Several emails here have valiantly attempted to get us to focus on the technical aspects of the RedPhone patent claims, the progress of the patent in the PTO and PCT, and other technical issues. Speaking only for myself, I haven't yet seen any justification for us fearing the RedPhone patent claims. They may be as bogus as the hundreds of other patent infringement claims that companies receive letters about every day. OTOH, they may be deadly submarines ready to attack us all. Why don't we organize to answer the patent claim infringement issues like professionals do? Ask technical experts. Consult a patent attorney. Render expert opinions. Absolutely -- that's everyone's right, privilege, and (arguably) duty. I haven't looked at it myself because I have no particular interest in it at the moment, but this is definitely the proper course. It's also perfectly proper to post analyses to influence others -- that was done years ago in IPsec to reassure people that a particular patent was unlikely to be enforceable. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: meeting attendance nomcom
On Fri, 09 Jan 2009 11:11:15 -0500 John C Klensin john-i...@jck.com wrote: though one might reasonably require that any volunteer have a firm expectation of being able to attend f2f Nomcom meetings, participate in f2f interviews, etc. (i.e., attend several meetings in succession even if their earlier participation was less dense). I think this is a very important point. In addition, since Nomcoms seem to mostly evaluate and then return incumbents (whether that is good or bad is a separate issue; it is an observable fact), a case can be made that evaluations from within the Nomcom about how I* members deal with participants who do not routinely attend meetings could actually enhance the Nomcom's effectiveness. At the time Scott put me on the IPng directorate, I'd never attended a meeting... Meanwhile, you might be interested in the draft paper at http://www.cs.columbia.edu/~smb/papes/codebooks.pdf -- even if it cites a very different Unicode... --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: meeting attendance nomcom
On Fri, 9 Jan 2009 11:37:18 -0500 Steven M. Bellovin s...@cs.columbia.edu wrote: Folks -- I hit 'send' too soon; it was supposed to be a private message. Meanwhile, you might be interested in the draft paper at http://www.cs.columbia.edu/~smb/papes/codebooks.pdf -- even if it cites a very different Unicode... That link doesn't work; the error is pretty obvious. But since I hadn't intended it to be public yet, I'll let anyone who cares figure it out for themselves... --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impactto applicationdevelopers
On Mon, 1 Dec 2008 19:07:35 -0800 Christian Huitema [EMAIL PROTECTED] wrote: GSE/8+8 also does not achieve topology hiding, not if the mapping between internal and external /64 is a one-one. Of course, you could smash multiple internal subnets to a single /64 external view, but then you would probably need a new duplicate address detection algorithm to avoid conflicts, not to mention recognize cases of a single host using the same host ID on multiple subnets. I'm not sure I believe in the need for topology hiding. But if I did, on v6 I'd just allocate a separate subnet or group of subnets for external access. If really necessary, have such hosts set up IP over IP or L2TP tunnels to a concentrator; that will make this external access net look flat. Of course, Iljitsch points an interesting issue. If NAT66 behaves exactly like, say, NAT 64, then why would the organization bother to use IPv6 rather than sticking with net 10? Services like Microsoft DirectAccess? --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Sun, 09 Nov 2008 23:40:43 -0500 Tony Hansen [EMAIL PROTECTED] wrote: I'm personally very interested in getting the format for querying DNS *white* lists standardized. I want to be able to use DNSWLs as part of *positive reputation* checking: given an *authenticated* domain name (say, with DKIM), can we say something positive about them beyond they send email? The protocol described in this draft covers both cases, both positive and negative checking. While the majority of the examples in the document concentrates on negative examples, the protocol *is* useful for the positive case. Does anyone have issues with the use of this protocol for WHITE lists? In some sense, I have more trouble with white lists than black lists. My concern is centralization of power. If used properly, white lists are fine. If used improperly, they're a way to form an email cartel, forcing organizations to buy email transit from a member of the inner circle. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On 8 Nov 2008 17:05:00 - John Levine [EMAIL PROTECTED] wrote: standardizing them and formally recommending their use I'm not aware of any language in the current draft that recommends that people use DNSBLs. What it does say is that if you use or publish DNSBLs, here's how they work so you can, you know, interoperate and all that. I hear you -- but http://xkcd.com/463/ comes to mind. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir Review of draft-stjohns-sipso-05
On Tue, 21 Oct 2008 16:57:12 -0400 Michael StJohns [EMAIL PROTECTED] wrote: ... Classified documents have this thing called paragraph marking. Each paragraph within a document is marked with the highest level of data within the paragraph. A page is marked with the highest level of data in any paragraph on that page. The overall document is marked with and protected at the highest level of data within the document. Those who want the gory details should see http://www.fas.org/sgp/isoo/marking.pdf --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NTIA request for feedback on DNSSEC deployment at the root zone
On Thu, 9 Oct 2008 10:03:32 -0400 Tim Polk [EMAIL PROTECTED] wrote: Folks, The National Telecommunications and Information Administration published a Notice of Inquiry entitled Enhancing the Security and Stability of the Internet's Domain Name and Addressing System in today's Federal Register: Note that comments posted to the IETF list aren't seen (at least not officially) by NTIA. Follow the procedure in the Federal Register notice for official comments (and note that they will become part of the public record). --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Secdir Review of draft-stjohns-sipso-05
On Wed, 1 Oct 2008 22:12:17 -0400 Steven M. Bellovin [EMAIL PROTECTED] wrote: Steven Note 7.3.1 on Steven TCP considerations. (Also note that 7.3.1 disagrees Steven with 793 on the treatment of security labels in section Steven 3.6 of 793. At the least, this shoudl be noted. I had completely missed this. I'll call out the section to the transport ADs I should have added: I think the new document is in fact more correct than 793 -- the 793 scheme would permit various forms of high-bandwidth covert channels to be set up. This is an issue that was not nearly that well understood when 793 was written. That said, it is a change to TCP, and needs to be treated as such. Thinking further -- I suspect that the right thing to do here is for someone to write a short, simple draft amending 793 -- it's handling of the security option is simply wrong, independent of this draft. I wonder -- what TCPs actually implement even 793? NetBSD doesn't; I strongly suspect that no BSDs do. Does Solaris? Linux? --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Secdir Review of draft-stjohns-sipso-05
On Thu, 02 Oct 2008 17:48:07 -0700 Joe Touch [EMAIL PROTECTED] wrote: The point I'm making is that there seems like there should be a way to prevent the covert channel without mucking up TCP's definition of what an endpoint is. I think this belongs elsewhere than either the secdir list or the main IETF list, but I think you're wrong -- there doesn't have to be a way. Certainly, I don't think your suggestion of filtering SYNs will do it. MLS security is a very different creature than regular security. We've seen very little of MLS in the IETF (and for that matter, it's not used all that much even in the DoD world), but there's a lot of literature on the subject. The questions for the IETF are (a) is this TCP issue worth doing at all in the IETF, given the limited market, and (b) if it is, how is it best done? I don't think a WG is needed -- the subject is too narrow -- but I do think we need one or more I-Ds, and probably a mls-tcp mailing list. Clearly, any resulting document will have to pass muster by TSV as well as SEC; probably, that means TCPM and SAAG. It might pay for someone to write an assumptions and threat model I-D first -- to give just one example of what might be discussed in it, should we assume that the OS has any role at all? Given how few operating systems are even MLS-capable these days (let alone evaluated for that purpose), perhaps all of the MLS processing will be done (in the real world) on outboard NICs or IPsec boxes. What is the scope, then, of host MLS processing? --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Secdir Review of draft-stjohns-sipso-05
On Thu, 02 Oct 2008 18:11:07 -0700 Joe Touch [EMAIL PROTECTED] wrote: Steven M. Bellovin wrote: On Thu, 02 Oct 2008 17:48:07 -0700 Joe Touch [EMAIL PROTECTED] wrote: The point I'm making is that there seems like there should be a way to prevent the covert channel without mucking up TCP's definition of what an endpoint is. I think this belongs elsewhere than either the secdir list or the main IETF list, Agreed; I propose to take this over to TSVWG. It's more general than just TCP... Don't forget to include SAAG... --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Secdir Review of draft-stjohns-sipso-05
On Tue, 30 Sep 2008 06:44:45 -0400 Sam Hartman [EMAIL PROTECTED] wrote: Steven == Steven M Bellovin [EMAIL PROTECTED] writes: Steven On Mon, 29 Sep 2008 15:20:23 -0400 Steven Sam Hartman [EMAIL PROTECTED] wrote: Section 8 proposes that AH is the mandatory-to-implement security mechanism for this option. Do we still believe that is appropriate given RFC 4301's move away from AH as a mandatory-to-implement service? Steven As discussed way back when, when we'd agreed on what Steven became 2401 et seq., the IETF preferred that security Steven labels be part of the credential, and hence implicit in Steven the security association, rather than being part of the Steven IPsec header. Now -- here, the use of IPsec is to protect Steven the security label, rather than the data -- but does it Steven actually do that in any useful way? If the security Steven option is really end-to-end, we don't need it, per the Steven above. If it's hop-by-hop -- and it's using a v6 Steven hop-by-hop option -- AH doesn't provide useful protection Steven unless packets are digitally signed rather than MACed. Doesn't that sort of depend on 1) who the attackers are 2) who the endpoints of the SA are? I'm not sure what you mean here. I think it's reasonable to postulate an active or semi-active attacker on a nominally-secure link -- think Operation Ivy Bell, or any of a number of CIA attacks on Soviet communications systems described in a new book Spymaster. Such an attack could record packets and resend them with a different security label; in the absence of digital signatures, this could not be detected until the receiving site, which of course will never see it -- the destination address would be changed, too. As far as I can tell AH would be fine for hop-by-hop SAs to protect packets flowing over a link that cannot be trusted to preserve integrity between two intermediate systems. You could potentially have both an end-to-end SA and a hop-by-hop SA. That says that you trust intermediate systems less than you do the endpoints, but somehow you're still trusting them not to disclose traffic. I'd like to understand the threat model that leads to this better. Need to know -- intermediate systems may be cleared very high, but they have no need to see the packet contents. However, I agree with you that the draft is broken. It seems clearly like it is talking about end-to-end AH, and I agree that doesn't fit the model well at all without digital signatures. That's my main point. As we know, BCP 61 requires a strong mandatory-to-implement security mechanism for Internet protocols. That mechanism needs to be sufficient for use over the open Internet. We have been very reluctant to accept weaker security mechanisms because some standards-track protocol is not intended for use on the open Internet; BCP 61 says we have consensus that is not how we do things. I question whether AH is sufficient as a BCP 61 mandatory-to-implement mechanism. The entire point of this IPV6 option is to limit disclosure of confidential and classified information. In order to meet that security objective on the open Internet, some confidentiality mechanism is required. I strongly recommend that if this TS is published on the standards track,ESP with confidentially be required. Steven I don't agree. The purpose of AH in this spec is to Steven protect certain information that's in the clear. (As Steven noted, though, I don't think it does it properly.) Steven Protection of the underlying data is the business of a Steven separate layer or sublayer. I made a number of statements and I'd like to explore our disagreement. I'm assuming that we agree about what BCP 61 is trying to do: it's trying to require that IETF protocols have adequate security for the open Internet, because networks will get connected. I seem to recall you buy into that argument:-) Yes... Do you disagree with my assertion that from a overall architecture view, anyone who implements this mechanism needs confidentiality to run their packets over the open Internet? Yes. If you agree confidentiality is needed somewhere, how do we get interoperability if we don't mandate a confidentiality mechanism here? It's a different layer. The security label doesn't require confidentiality; it does require integrity. The document requires that if there is a label inside and outside an AH header, that these labels must be the same. Why is this a valid use of a 2119 MUST? What security or interoperability problem results if for example the outer label dominates the inner label? As far as I can tell this requirement gets in the way of tunneling arbitrary IP traffic. Steven It guards against someone tampering
Re: Secdir Review of draft-stjohns-sipso-05
On Mon, 29 Sep 2008 15:20:23 -0400 Sam Hartman [EMAIL PROTECTED] wrote: Section 8 proposes that AH is the mandatory-to-implement security mechanism for this option. Do we still believe that is appropriate given RFC 4301's move away from AH as a mandatory-to-implement service? As discussed way back when, when we'd agreed on what became 2401 et seq., the IETF preferred that security labels be part of the credential, and hence implicit in the security association, rather than being part of the IPsec header. Now -- here, the use of IPsec is to protect the security label, rather than the data -- but does it actually do that in any useful way? If the security option is really end-to-end, we don't need it, per the above. If it's hop-by-hop -- and it's using a v6 hop-by-hop option -- AH doesn't provide useful protection unless packets are digitally signed rather than MACed. As we know, BCP 61 requires a strong mandatory-to-implement security mechanism for Internet protocols. That mechanism needs to be sufficient for use over the open Internet. We have been very reluctant to accept weaker security mechanisms because some standards-track protocol is not intended for use on the open Internet; BCP 61 says we have consensus that is not how we do things. I question whether AH is sufficient as a BCP 61 mandatory-to-implement mechanism. The entire point of this IPV6 option is to limit disclosure of confidential and classified information. In order to meet that security objective on the open Internet, some confidentiality mechanism is required. I strongly recommend that if this TS is published on the standards track,ESP with confidentially be required. I don't agree. The purpose of AH in this spec is to protect certain information that's in the clear. (As noted, though, I don't think it does it properly.) Protection of the underlying data is the business of a separate layer or sublayer. This document referrs to SIPSO-IPsec interactions in a number of places, but never outlines processing rules for systems that implement both IPsec and SIPSO. Does the label go inside or outside of IPsec? (presumably the label should be protected) Very important -- see above. The document requires that if there is a label inside and outside an AH header, that these labels must be the same. Why is this a valid use of a 2119 MUST? What security or interoperability problem results if for example the outer label dominates the inner label? As far as I can tell this requirement gets in the way of tunneling arbitrary IP traffic. It guards against someone tampering with the outer label, causing the packet to be misrouted perhaps. Note 7.3.1 on TCP considerations. (Also note that 7.3.1 disagrees with 793 on the treatment of security labels in section 3.6 of 793. At the least, this shoudl be noted. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART Review of draft-ietf-forces-mib-07
On Tue, 02 Sep 2008 16:48:43 -0400 John C Klensin [EMAIL PROTECTED] wrote: It occurs to me that people may have been saying could be resolved in AUTH48 when they really meant could be resolved in an RFC Editor note. While, like Paul, I tend to prefer that the RFC Editor get clean copy, there is a huge difference between IESG makes a note to the RFC Editor about a desired editorial fix or IESG makes a note to the Author/Editor about a desired editorial fix so it can be incorporated into the clean copy that goes to the RFC Editor and anything having to do with AUTH48. The former two are pre-editing and allow opportunities for discussion of any proposed changes that appear to be unreasonable. Requesting that changes be made at AUTH48 time is just, IMO, an opportunity for mistakes and/or abuse. Personally, I don't even like RFC Editor notes for things that can and should be corrected by the author. As both an author and an AD, I much preferred clean new copies. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Failing of IPR Filing Page when makling updates in re LTANS and other filings.
On Wed, 13 Aug 2008 12:48:07 -0400 (EDT) Dean Anderson [EMAIL PROTECTED] wrote: On Tue, 12 Aug 2008, Scott Brim wrote: On 8/12/08 12:02 PM, TS Glassey allegedly wrote: As to the IPR Page - it does not allow for updates of already filed IPR Statement's to include new IETF documents which violate the patent rights after the posting of the IPR Notice. How can a description of how to use a technology infringe on a patent? A standard isn't merely a description, as in a magazine article, but also represents an industry agreement on the definition of a product. A draft or WG could encourage persons to violate a patent, which is indirect infringement. A draft or WG could define a product that is a contributory infringement on a patent. The working group must take care not to do these things. The whole point of the IETF's IPR policy to make sure that people do know of applicable patents. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: About IETF communication skills
On Fri, 1 Aug 2008 07:38:27 +0100 Paul Hoffman [EMAIL PROTECTED] wrote: Folks: please review all of the IETF-related articles in the IT trade press from the past five years. Discard the articles that say the IETF is considering Foo when in fact someone had submitted a -00 draft. The very small pile that remains, including interviews with our leadership about where they think the IETF is going and in-depth articles comparing multiple contenders being considered in IETF areas, are mostly written by Carolyn Duffy Marsan. Indeed. I've personally dealt with her quite often, and she's always represented what I've said quite accurately and fairly -- even one time when I wished she hadn't I have exactly zero complaints about her reporting. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Be aware when traveling to the USA.
Be aware when traveling *from* the US, too -- according to the policy at http://www.cbp.gov/linkhandler/cgov/travel/admissability/search_authority.ctt/search_authority.pdf they worry about exports as well... In fairness, though, many countries reserve the right to search laptops. See http://news.bbc.co.uk/1/hi/sci/tech/150465.stm for a story about it happening to a journalist entering the UK from France. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: About IETF communication skills
On Thu, 31 Jul 2008 11:24:07 -0700 Ted Faber [EMAIL PROTECTED] wrote: On Thu, Jul 31, 2008 at 02:11:48PM -0400, Daniel Brown wrote: On Thu, Jul 31, 2008 at 2:08 PM, Joel Jaeggli [EMAIL PROTECTED] wrote: Or you know not consenting to interviews with someone who's professionalism you don't respect. Why you would expect someone engaged in serious journalism or otherwise to offer you the opportunity to modulate your own statements post facto is beyond me. To change what was said, no. To ensure that it's taken in the proper context, yes. It's done in the media every day. I think it is unwise to assume that you will get an opportunity to review a story before publication - let alone offer comments or corrections - unless you have specifically negotiated that right with the reporter and perhaps their superiors. YMMV. IANAL. Right. Years ago, the Bell Labs guide to dealing with the press specifically warned against even asking if you could review the story -- reporters often fear you'll try to delete embarrassing things you said, or even bring pressure to get the story changed. (A few years ago, I was explaining some arcane technical details to a reporter for a very reputable mainstream publication. He asked me to review his text for correctness -- but told me that that was something he wasn't supposed to do. He made an exception because the text under discussion was supposed to be factual, not commentary, and I wasn't the focus of the article. But he was quite clear that his publication *prohibited* reporters from showing articles to their subjects.) The only thing you can do is make sure you only talk to reporters you think will capture your statements correctly. (Btw, don't assume that reporters make up headlines -- often, they don't, any more than authors have sole control over book titles or covers.) --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: About IETF communication skills
On Thu, 31 Jul 2008 23:08:57 +0100 [EMAIL PROTECTED] wrote: Maybe IETF should be thinking about what actions and policies, uniformly applied, will result in the most accurate representation of its work to the community. In my experience, the best action to take would be to advise, or teach, people how to handle media interviews. Back when I used to regularly talk to journalists I had no problem with their articles because I planned the interviews in advance. I made sure that I had no more than two or three key points to make, I prepared a sound bite or two, and I repeated myself. There is an art in taking complex technical material and explaining it in layman's terms, but that is exactly what you must do with journalists if you want them to accurately represent your message. Even journalists who cover technology are not technologists themselves. Their specialty is writing and they can only write what you CLEARLY and consistently explain to them. It can be especially hard for people with a deep technical understanding of something, complete with a multitude of corner cases, to summarize in laymans' terms and gloss over the details. That's why I agree with Keith that some IETF action would be beneficial here. I agree that learning how to talk to reporters is important. You won't always get what you want, but it will help. However, I don't agree that official IETF action is a good idea. Note that one way to approach the issue is to hold official press conferences at which only accredited members of the press can ask questions. By doing this you focus attention on a few people who would, hopefully, prepare for the event and understand how to explain the work to ordinary people like journalists and their readers. This doesn't prevent the press from attending other meetings and it doesn't prevent IETF members from talking to the press. What it does do is hold out the carrot of quality communication, and one hopes that the press will appreciate the effort and make full use of it. Indeed, the invitations should explicitly solicit clarifying questions about anything that the journalist has already begun working on. I don't know what accredited means anymore. Too often, it turns into ways to exclude unfriendly or non-mainstream reporters, or to plant favorable ones. See http://www.cnn.com/2005/ALLPOLITICS/02/09/white.house.reporter/ for one example, but the opposite effect -- excluding unfriendly reporters -- has also happened. Back when I was an editor of one of my university's student papers, New York City press passes were issued by the police department to members of the working press. This, of course, excluded student reporters, and since police brutality towards student demonstrators was an issue then this was a non-trivial handicap. These days, the analogous issue is whether or not bloggers are real journalists. I would hope that most IETFers would object to that distinction. To put it bluntly, I'm not at all in favor of trying to manage news coverage, especially by organizational mechanisms. Say what you mean, say it clearly, and publish your own blog/newsletter/whatever if you need to. Complaints about misconstrued quotes are also appropriate, because any system needs a feedback channel. But trying to control the press is not only worse than the disease, it's counter-productive. (I'd be astonished if the reporter in question were not reading this thread -- what will the next story be?) --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sieve-refuse-reject
On Tue, 29 Jul 2008 00:13:42 +0200 Frank Ellermann [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: you appears to be complaining that the definition given in this RFC in fact agrees with yours, perhaps modulo emphasizing that the intent is to hurt the person whose address is forged. Another attempt: Joe Jobs are about hurting an alleged sender, not about spamming. Joe Jobs are relatively rare. Forged return-paths are standard operation in spam, they are about spamming. The backscatter is not the intention. Somebody who gets tons of backscatter likely doesn't care if that was intentional or not, because (s)he's annoyed. Nevertheless using the term Joe Job is a distraction, because it is about a limited problem, unlike the global problem with the name backscatter. Sorry -- I'm with Ned on this one. Joe Jobs are Joe Jobs; the intent isn't important. Backscatter is an effect of the technique; it isn't the act itself. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Progressing I-Ds Immediately Before Meetings
On Sat, 19 Jul 2008 15:42:08 -0700 Dave Crocker [EMAIL PROTECTED] wrote: Russ Housley wrote: When all of the Internet-Drafts were processed by Secretariat staff, there was a huge workload concern. ,,, I also agree that an AD should be able to get an I-D posted after the cut-off date if it is the right thing. Russ, I'm missing some bit of logic that I hope you can clarify: 1. The cut-off was put into place due to workload on the Secretariat. The automated I-D has eliminated that bottleneck problem. No, that's not the primary reason -- the reason was to give wg members a chance to actually read the documents before the meeting. Only a small part of the interval was for the benefit of the secretariat. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
On Tue, 17 Jun 2008 14:44:33 -0400 Marshall Eubanks [EMAIL PROTECTED] wrote: I fully agree with Debbie here. Human experience teaches us that examples will be used, over time. Foo.com is a commercial site. If the IETF uses foo.com in email examples, it is reasonable to assume that foo.com will get unwanted traffic because of that. I think that the IETF should not put itself in the position of causing avoidable pain to others, even if the likelihood of serious harm is small. Since there is a remedy, and it could be adopted readily, I think that the discuss was reasonable and do not support the appeal. Yes -- and there's certainly case law to support the IESG's position; the IESG has been insisting on this for years. Now -- there are times when the stated policy just doesn't work. I recall one IPsec document where the example had to show several different networks. John's appeal stated that the WG considered and rejected using the 2606 names; perhaps this is another case. (I haven't read the draft in question.) Hoping the reader will notice the difference between example.com and example.net, or even bad-dog.example.com and good-cat.example.net, is just asking for trouble. So -- in general, I think the IESG's position is a good one, and well-supported by custom; however, there are exceptions. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Meeting Network Requirements ION Published
On Tue, 25 Mar 2008 10:03:22 -0700 Joel Jaeggli [EMAIL PROTECTED] wrote: Does this also disallow (rather typical) filtering of Windows ports (at least 137-139, 445)? I understand it to mean that yes, the advisability of using SMB across the public internet notwithstanding. Umm -- I regularly participate across the public Internet... And given context, I think I'll sign this message. --Steve Bellovin, http://www.cs.columbia.edu/~smb signature.asc Description: PGP signature ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confirming vs. second-guessing
On Mon, 17 Mar 2008 18:44:49 -0700 Christian Huitema [EMAIL PROTECTED] wrote: And in order to make the confidentiality issue more concrete (ie, real) would folks offer some examples of what falls under it. I accept the nomination of area director. The current area director, Mr. J. Sixpack, has been attempting to impose his opinion that beer should contain rice. This is causing a rift in the working groups within the area. I would follow the area consensus that we should outlaw rice in beer and thus my appointment as new area director would achieve peace and harmony within the area. Why should such a statement be confidential? Try this one, quite non-hypothetical: a candidate for the IESG is contemplating switching jobs. His or her current employer does not yet know this. It has a clear bearing on whether or not that person can do the job of AD, but equally clearly should not be broadcast to the world. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confirming vs. second-guessing
On Sun, 16 Mar 2008 18:31:24 -0700 Dave Crocker [EMAIL PROTECTED] wrote: Spencer Dawkins wrote: I have misunderstood before, but one point of view I've heard expressed was that - NomCom is supposed to choose the best candidate, while - the confirming body is supposed to make sure NomCom chose a good candidate That sounds like exactly the opposite of a rational sequence. Nomcom's always do an early filter against clear inadequacy. If that leaves no candidates, they search for more. This is like doing late-stage reviews, after a working group has been operating for two years, and raising strategic concerns about their entire apporach: Good issues, but at the wrong time. So what do you see as the role of the confirming body? --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Eating our own dog food and using SIP for telephony... (was Re: My view of the IAOC Meeting Selection Guidelines)
On Mon, 11 Feb 2008 19:21:48 +0200 Lars Eggert [EMAIL PROTECTED] wrote: On 2008-2-11, at 18:55, ext Dan York wrote: Can we move some of this conversation in the bill below onto the Internet using systems where our costs essentially go to $0? (Obviously we still need to communicate to non-wired folks across the PSTN, such as event location facilities, etc.) I do hope we can reduce costs, but the requirements that Marshall described are valid: - need to be able to call in from the PSTN, worldwide (Many of us call in from hotels, airports, trains, etc.) - need to be able to have an operator dial out to someone (Calling in form a hotel sometimes just doesn't work.) - need to be able to get technical support during the call (Audio issues, lines getting dropped, calling out, etc.) There's a baseline cost associated with all that 24/7 support. Having some people call in over IP vs. the PSTN may save some money, but I doubt that the savings would be dramatic. Precisely. The issue is a *service*, not a technology. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: My view of the IAOC Meeting Selection Guidelines
On Sun, 10 Feb 2008 13:17:25 -0500 Marshall Eubanks [EMAIL PROTECTED] wrote: Having thought about this a little, I think that the real question is, what is the cost of a failed IESG meeting. (Or IAB or IAOC or...) It is not just a question of doing it cheaper. It is a question of doing it cheaper and not impacting the work done by the IETF. And there have indeed been problems; I recall a fair number of IESG calls where we had to get a human operator to troubleshoot some major voice quality problem. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)]
On Wed, 14 Nov 2007 22:43:01 -0800 Joe Touch [EMAIL PROTECTED] wrote: Sam Hartman wrote: ... Yes, Steve almost certanily did slow down any heavy CPU use during the time when he was doing the backup. Our point--Steve, Steve and I--is that for a lot of uses and a lot of users, no one cares. Perhaps that's why everyone is using security. We don't have a problem then. I didn't say that; I said that performance generally isn't the issue. Often, there's a *perception* of a performance issue, because once there was. The bigger problem, in my opinion, is usability. *Lots* of people use SSL, because they don't have to do anything. SSL as used in https has lots of problems I won't go into here, but it is excellent protection against passive eavesdroppers. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)]
On Wed, 14 Nov 2007 15:39:50 -0500 Stephen Kent [EMAIL PROTECTED] wrote: Joe, I disagree with your suggestion The software performance of security protocols has been the more substantial issue, and is likely to continue to be for the forseeable future. I suspect that most desktop users do not need hardware crypto for performance. Irarely if ever drive my GiGE interface at its line rate. With fast processors, especially multi-core processors, we have enough cycles to do symmetric crypto at data rates consistent with most application demands for individual users. Public key operations for key management are usually low duty cycle, so they too can be accommodated. Thanks -- I was going to say something similar. I regularly back up my laptop's disk over a software-encrypted GigE link. The dump file occupies about 35G of disk space; it takes about 70 minutes. Exclusive of protocol overhead, that comes to ~71M bps; given IP, TCP, and ssh, I'd guess it's more like 75-80M bps. I also know that I can run ttcp between that pair of machines at about 500M bps. Am I really suffering from a 7:1 performance hit from the crypto? Nope. I can't do controlled experiments right now, since the laptop and server in question are currently about 350 km apart at the moment. Dumping the disk to /dev/null took about 30 minutes. The maximum hit I'm taking from the crypto, then, is about 2.3:1. Using the performance numbers from 'openssl speed' for 1024-byte blocks for AES-128 and SHA-1, the crypto is 23 minutes of CPU time. (This is a 1.8Ghz, single-core laptop.) The other 17 minutes probably go to data copies -- I'm doing 'dump | ssh cat file' -- so a kernel implementation (say, IPsec) would be better -- and overhead, plus (of course) calculation error). The point, though, is that the crypto isn't the limiting factor. It's not stopping me from doing anything. It's not even the biggest bottleneck in my application. And *that's* what's important -- not *network* speed, but *application* speed. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)]
On Wed, 14 Nov 2007 21:22:48 -0500 Sam Hartman [EMAIL PROTECTED] wrote: Joe By essentially shutting your machine down for over an hour. No, not at all; not even close. I'm only going to send this one message, but then I'll drop out of the thread. We've drifted far from Leslie's original query. Steve did not say his machine was CPU bound. Also, even if it was CPU bound, he's probably running an operating system with reasonable multiprogramming characteristics. So, if he wanted to use the machine, his backup would take longer, but he'd get to do whatever he wanted. Yes, Steve almost certanily did slow down any heavy CPU use during the time when he was doing the backup. Right. Operating systems are really good at sharing the CPU between processes. As long as you're talking about pure CPU load, the scheduler works *very* well, and has for O(45 years). Right now, as I'm typing this, I'm running that dump again in the background, this type piped to 'cat /dev/null' to better simulate the pipe overhead, and I'm running 'openssl speed' in another window. I do not perceive any slowdown whatsoever. I would notice it I tried to view a movie, or if I tried to do serious picture or video editing, or if I tried running another command -- say, firing up firefox if it were not already running -- that did a lot of disk I/O. I don't know of any OS -- and that includes every version of Unix I've ever used, going back more than 30 years, and every version of Windows I've used, going back about a dozen years, that shares disk bandwidth particularly well. But sharing CPU is very easy. I don't dispute Joe's numbers about how crypto can limit bandwidth. Again, though, what matters to me is system and application performance, and there I generally don't feel the hit. Why do I use GigE? Well, in one sense it's because that's what came with my computer, but I did spend the money to convert my house network to GigE. There's some unencrypted traffic to the file server. Just as important, even with the crypto I'm approaching the limits of what I can do with 100BaseT. As I noted, my actual, over the wire, dump operations are running at 75-80M bps. There's not a lot of headroom between that and the 91M bps that is the fastest I've managed with ttcp. I just got a new, faster laptop; I'm curious what it will do, with and without the crypto. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reminder: Offer of time on the IPR WG agenda for rechartering
On Mon, 5 Nov 2007 08:44:33 -0800 Lawrence Rosen [EMAIL PROTECTED] wrote: Harald Alvestrand wrote: The outcomes I see possible of such a discussion are: snip I can't be in Vancouver for this meeting. Probably few of the others who have been vocal on these issues on these email lists can be in Vancouver either. I hope no decisions will be arrived at in what will probably be an unrepresentative arena. In-person meetings are an ineffective and expensive way to decide things in the Internet age. In any event, these email lists have elicited more comments than any meeting in Vancouver could properly address. How do we intend to move toward consensus? Per 2418, of course the mailing list decision is the one that counts. OTOH -- and as is well-understood -- it's often much harder to assess consensus over the net than in person. (It's also harder to reach consensus, in many cases, since email tends to be a polarizing medium, prone to flames and other forms of intemperate behavior.) If you have any suggestions for how to deal with these problems -- and they are problems -- I think the IETF would be very interested in hearing them. (And because I realize that this statement can be misinterpreted, given the lack of tone of voice and body language on a mailing list, let me stress that I'm being 100% serious, complimentary, etc.) The alternative to a re-charter is for this complaint to be brought up again and again, every time someone has the audacity to recommend an IETF specification that is encumbered so to prevent FOSS implementations. Is that preferable? I'm no longer an AD; if I were, my attitude would be simple: the IETF has decided, as a group, that patented technology is acceptable. There's no point to reopening the question every individual document. Were this a legal matter, I'd cry stare decisis. I'm not saying you shouldn't keep pushing, but if the IESG were to ignore a consensus to follow the current policy it would be challenged and rightly so. (The substantive issue on the document currently being discussed is not the fact of the patent -- under current policy, that's acceptable -- but rather the timing of the disclosure.) The question to discuss now is whether enough has changed since the last consensus call on this topic, in March-April 2003, that it pays to reopen the rechartering question. I personally don't think so, but I'm willing to be persuaded otherwise. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Daily Dose version 2 launched
On Fri, 02 Nov 2007 13:00:03 -0400 Joel M. Halpern [EMAIL PROTECTED] wrote: I second John's note. When I saw Pasi's note, I had assumed that he was referring to a link off of the tools page. Replacing the tools page with an activity summary is quite surprising. Joel Indeed. I suggested that an Atom feed would be a very useful alternative. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Patents can be for good, not only evil
On Wed, 31 Oct 2007 08:38:45 -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: How many Working Group participants who vent on patent issues have read RFC 3669? Of those who have read it, how many consider it to be binding? It's not binding because it's Informational. However, the topic is frequently covered in WG Chair training sessions. There's a prominent link to IPR issues on the WG Chair's page, including a separate Wiki just on IPR (and the introduction page there explicitly cites 3669). That's not a substitute for all WG participants knowing it, but I'd guess that most chairs do, and can bring it up as appropriate. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Patents can be for good, not only evil
On Mon, 29 Oct 2007 17:53:35 -0700 Lawrence Rosen [EMAIL PROTECTED] wrote: Steven Bellovin wrote: We've all seen far too many really bad patents issued, ones where prior art is legion. The (U.S.) patent office seems to do a far better job of searching its own databases than it does the technical literature. I know there are many philosophical reasons why many people oppose software patents. But for others, there are very practical reasons: there are too many bad patents issued. I think we can all agree that stopping bad patents is a worthwhile goal, even if for some it's just an intermediate goal. The times they are a-changin'. [1] Yup, I remember it from when it was new Please take a look at what's happening at http://dotank.nyls.edu/communitypatent/. This is a GREAT place for the technical experts in IETF to become involved in busting bad patents before they are issued. You raise an interesting point. Some years ago, the conventional wisdom was that it was a bad idea to oppose patents at that point, since any prior art introduced at that point were considered known by the patent office, and hence not usable to challenge the patent later. Objections based on such papers are reflected in the file wrapper, but not always in the language of the specification or the claims. In my experience, concessions by the applicant reflected there are not always understood by judges and/or juries. After patents are issued, busting them nowadays is also easier than it used to be if we can present prior art to support reexamination by the PTO. Take a look at what's happening at http://www.pubpat.org/. Does it actually work in practice, when someone has filed a (preposterous) infringement suit and each side is hiring expensive experts? (Re-examination didn't seem to work for RIM.) --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When is using patented technology appropriate?
On Thu, 25 Oct 2007 10:15:55 +1300 Brian E Carpenter [EMAIL PROTECTED] wrote: On 2007-10-25 04:30, Sam Hartman wrote: ... Simon If you replace IBM with 'A Patent Troll', do you think Simon the same holds?I think that such behavior should Simon be presumed not to be a patent troll. Patent trolls are not known forpromising to give away royalty-free licenses. They are also, in general, known for *not* particpating in the standards process, precisely to avoid falling under patent disclosure requirements. As far as non-participants are concerned, nothing in our rules matters. Right. Any IPR policy has to acknowledge the fact that relevant patents can be owned by non-troll non-participants. (Too many negatives there -- what I'm saying is that IETFers don't know of all patents in the space, and there are real patent owners who care about their patents, even though they aren't trolls.) --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A priori IPR choices
On Tue, 23 Oct 2007 08:42:06 -0400 Theodore Tso [EMAIL PROTECTED] wrote: On Tue, Oct 23, 2007 at 01:05:39PM +0200, Simon Josefsson wrote: Frank Ellermann [EMAIL PROTECTED] writes: http://tools.ietf.org/html/draft-josefsson-free-standards-howto. I noticed that the 00 draft would expire in two days, and submitted a 01 with only minor changes. I like this document a lot; kudo's to Simon for writing it! My personal opinion is that suggestions for how to write a free standard published as an informational RFC is much more useful than trying to get consensus around some edict that the IETF _only_ publish free standards. I agree. There are a number of problems with the current draft (i.e., the reference to RSA patents -- those expired years ago), but none that I think would block progress of the document. This is definitely worth pursuing. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF / UN
On Fri, 12 Oct 2007 16:41:40 -0400 Matt Larson [EMAIL PROTECTED] wrote: On Fri, 12 Oct 2007, Eastlake III Donald-LDE008 wrote: But the UN is a government-- No it isn't, Martin insisted, It's a talking shop. Started out as a treaty organization, turned into a bureaucracy, then an escrow agent for various transnational trade and standards agreements. After the Singularity, it was taken over by the Internet engineering task force. It's not the government of Earth; it's just the only remaining relic of Earth's governments that your people can recognize. ... Singularity Sky, by Charles Stross, ISBN: 0-441-01179-9, Ace Books. From page 281 of the July 2004 paperback edition. We're already on the edge of on-topic and this comment has the risk of sending us spiraling off, but everyone really must immediately stop whatever you're doing to go out and buy and read everything by Charles Stross. You won't regret it. Indeed. A few years ago, I dropped him a note and mentioned that that line was quite popular in the IETF. He replied As it happens I'd be quite surprised if the IETF or something like it *doesn't* end up running the planet one of these days. (Running the planet being a thankless infrastructure maintenance task, after all.) --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: why can't IETF emulate IEEE on this point?
On Tue, 25 Sep 2007 23:32:21 -0700 Lawrence Rosen [EMAIL PROTECTED] wrote: I respectfully disagree with Steven Bellovin and Scott Brim, and ask that we NOT turn this issue back to the IPR-WG unless and until its charter is revised to allow it to *completely revise* IETF's IPR policies with respect to patents. This issue was strangled in committee the last time the IPR-WG addressed RAND and other IPR policies for industry standards, with the WG leaders insisting (erroneously in my opinion) that there was consensus NOT to address the problems that the current IETF patent polices pose for open source *and* proprietary implementations of supposedly open standards. However it has to be done, I ask that IETF not let that burial happen again. Let's first charter the IPR-WG to completely reconsider the IETF patent policy in light of new software industry expectations, and so that we get rid of the inadequate RAND (and even non-RAND) IETF IPR policies that currently exist. Everyone is entitled to their own opinions, but they are not entitled to their own facts. -- (U.S.) Senator Daniel Patrick Moynihan. The original charter of the IPR working group was to clarify the IETF's patent documents. As chair, I promised the WG that once those documents were finished, we'd discuss rechartering. That happened, and went on for many months. You're welcome to consult the mailing list archives for that discussion. At the Atlanta IETF (November 2002), the WG meeting was polled. According to the minutes (http://www3.ietf.org/proceedings/02nov/130.htm), there was no consensus to recharter. The discussion continued; at the next IETF (San Francisco, March 2003), the room was polled again. The minutes (http://www3.ietf.org/proceedings/03mar/132.htm) say fairly clear consensus against rechartering. Per IETF procedures, I took the matter to the mailing list; see http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg00962.html I did my level best to run an open, honest poll. I announced the result two weeks later: http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg01195.html You're welcome to consult the archives yourself to verify my count -- per my first note, I asked (and took technical measures to ensure) that votes were public. The issue was very widely discussed during the process, both within the IPR WG and elsewhere. It was covered in the trade press; see, for example, http://www.news.com/Free-software-gadfly-takes-on-Net-group/2100-1001_3-971124.html Note this quote, btw: Judging by an informal poll at the group's Atlanta meeting, that movement isn't gaining any momentum with the current membership, according to both Perens and the group's chair, Steve Bellovin. Bruce Perens is a well-known open source activist who spoke quite often on the subject in the WG. The final result was described at http://www.news.com/Standards-group-beats-back-patent-foes/2100-1013_3-996351.html To summarize: I did my level best to ensure a fair consensus call. I stand by my statement then that the consensus of the group was against rechartering. If you have evidence to the contrary, I think you should produce it. I also assert -- though this is more of an opinion -- that given the structure of the IETF, where anyone could participate in any WG meeting, the notion of strangling in committee a major issue simply doesn't apply. In a legislative body, with a fixed set of voting members, that can happen; I don't think it can happen in the IETF unless there's a complete absence of publicity -- and that certainly wasn't the case here. Now -- it's been 4.5 years since that consensus call, and perhaps the world and the IETF have changed enough since then that it's worth reopening the question. I doubt it, but my involvement with the IETF over the last three years has been much less than it was before that. (And I'm no longer the co-chair of the IPR WG, so any future efforts wouldn't be my problem.) That said, the IETF does not operate as a committee of the whole; it's just too big. Any proposed policy change will have to be taken up by *some* WG, whether the current IPR WG or a new one. If you think a new effort might be fruitful, I suggest you discuss how to proceed with Russ Housley, the IETF chair and General AD, and Harald Alvestrand, the current IPR WG chair. You may be right about the present and the future -- but let's not try to rewrite the past. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: why can't IETF emulate IEEE on this point?
On Tue, 25 Sep 2007 17:47:46 + Paul Vixie [EMAIL PROTECTED] wrote: in http://www.theregister.co.uk/2007/09/21/802_11n_patent_threat/, we see: Letters of Assurance are requested from all parties holding patents which may be applicable to any IEEE standard. Basically they state that the patent owner won't sue anyone for implementing the standard. ... i was thinking, what a great policy. why doesn't IETF have one like it? Because the strong consensus of the IPR WG a few years ago was to keep the current policy. As Ted Hardie pointed out, that group's mailing list is the correct place to raise this issue -- but frankly, I don't think the consensus has changed since the issue was last considered. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New models for email (Re: e2e)
Anyone who thinks that a new mail protocol that relies on users seeing some secure or trustworthy indicator should read: An Evaluation of Extended Validation and Picture-in-Picture Phishing Attacks Collin Jackson, Daniel R. Simon, Desney S. Tan, and Adam Barth, Proc. USEC '07. http://usablesecurity.org/papers/jackson.pdf --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
On Sat, 18 Aug 2007 05:04:54 -0400 Keith Moore [EMAIL PROTECTED] wrote: I'm not sure what your point is -- I took Keith's comment to mean that home NATs with v6 were completely unacceptable. /64's do NOT imply that there's NAT functionality involved, just that there's a single subnet, yes? yes, but it's unreasonable to expect a home user to not need to subnet. particularly when there are so many different media competing for the home network spaceit would be reasonable to have a subnet for each medium. I originally agreed with you on that. However, given modern switches, I'm not nearly as convinced. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: the curse of the S(imple) protocols, was: Re: e2e
On Fri, 17 Aug 2007 15:50:48 +0200 Iljitsch van Beijnum [EMAIL PROTECTED] wrote: Then again, misspelled fishing would be an order of magnitude harder if banks and retailers started using S/MIME, which is widely implemented today, S/MIME would be a fine start. It also won't solve the problem until someone develops a user interface that DTRT for naive users who don't understand trust anchors, the difference between authentication and authorization, or how to distinguish myfinancialcompany.com from myfinancia1company.com when both have valid certificates. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: the curse of the S(imple) protocols, was: Re: e2e
On Fri, 17 Aug 2007 20:31:51 +0200 Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 17-aug-2007, at 17:54, Steven M. Bellovin wrote: S/MIME would be a fine start. It also won't solve the problem until someone develops a user interface that DTRT for naive users who don't understand trust anchors, Big yellow warning when S/MIME authentication fails in Apple's Mail is hard to miss even if you don't understand exactly what it is... You'd be surprised what people will miss... You also have to account for people missing the presence of S/MIME, i.e., the bad guy just sends the email without any protection and hopes folks don't notice. or how to distinguish myfinancialcompany.com from myfinancia1company.com when both have valid certificates. So I can register paypa1.com and then go to Verisign to get a certificate for that domain? If that's true, then I think the law makers in various jurisdictions have work to do. Given that paypa1.com was the very first phishing attack I saw, and that there was a cert... More recently, see http://blog.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishing_1.html The very simple idea of having a .bank TLD for financial institutions could also help a lot here. Same failure modes. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
On Fri, 17 Aug 2007 17:01:39 -0700 Joel Jaeggli [EMAIL PROTECTED] wrote: Keith Moore wrote: It seems likely that cable mso's similar will dole out /64's to customers one at a time, I suppose that's acceptable if not necessarily desirable and will probably still result in the use of nat mechanisms in end systems. that's COMPLETELY unacceptable. Well lot's of people still think things like why would home users ever subnet but when you walk into a decent electronics superstore these days you can buy: terabytes of network attached storage HD video streamers wireless voip handsets or dual mode wifi/cellular phones building control and security systems that plug into ethernet or hang out on your wifi vlan capable managed switches that cost $150 At some point you stop wanting to have all those devices on the same network if for no other reason than to keep your multicast HD video streams from clobbering your ip phones, and around that same point the needs of a household of 2-6 people plus visitors start to look a lot like those of a heavily technology enabled small business. Have two or more wage earners that work for large enterprises and have vpn tunnels and associated network peripherals and you have issues that can keep consultants employeed for some time... This is a fairly unusual problem right now, but it won't be for long. I'm not sure what your point is -- I took Keith's comment to mean that home NATs with v6 were completely unacceptable. I agree with you on the desirability of home routers, though it's going to be an interesting challenge to build fire and forget boxes for the house. Of course, I'm the kind of guy who already has 3 (and sometimes 4) segments on my home LAN, so I suppose I really need home routers that speak OSPF --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: In support of symbolic references
On Thu, 05 Apr 2007 22:19:11 +0200 Simon Josefsson [EMAIL PROTECTED] wrote: Sam Hartman [EMAIL PROTECTED] writes: Hi. I'm sitting here reviewing changes to a document to see if I can last call it. As part of a response to AD review comments, one of the references were changed. This document uses numeric references. Starting at reference 16, everything was renumbered. That makes the diff a pain. For this and many other reasons, I strongly encourage people to avoid numeric references in their documents. That makes sense, but I believe the default for the xml2rfc tool is to produce numeric references. Does xml2rfc support symbolic references? If the defaults in xml2rfc is changed to symbolic references, I think we'd see that a lot of documents would adopt the new approach. Use the line ?rfc symrefs=yes ? to get symbolic references. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: In support of symbolic references
On Thu, 05 Apr 2007 23:00:24 +0200 Simon Josefsson [EMAIL PROTECTED] wrote: Use the line ?rfc symrefs=yes ? to get symbolic references. Neat. Maybe we can lobby for it to become the default. Is there some IDNit rule that suggest or imply that references should be numeric? A lot of documents have numeric references, so I could imagine that it is used in some examples, and therefor used by default by tools. No, there's no such rule; symbolic references are explicitly permitted. See Section 2.7 of ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Thu, 29 Mar 2007 17:12:18 +0200 Simon Josefsson [EMAIL PROTECTED] wrote: The community needs to evaluate patent claims, and preferably reach conservative agreement (rough consensus is not good enough) on whether we should care about a particular patent or not. Input to that community evaluation process may be documentation of legal actions taken by a patent owner. Sometimes that may happen only after a document has been published. I would support down-grading standards track documents that later turn out to be patent-infected to informational. Doing so would avoid sending a message that the IETF supports patented technology, when the IETF community didn't know about the patents at publication time. For credibility of the process, I believe it is important that these decisions are only made based on publicly available information. To be consistent with IETF process and IPR policy, I think that the only way to do that is via a standards action -- an IETF consensus call (often preceeded by a WG discussion and last call) to downgrade the document. Reclassifying documents as Historic is done by separate RFCs -- I suspect that that's the mechanism that would have to be followed here. Look at it this way -- we give WGs the right to standardize encumbered technologies. If we're to later reject technologies because they've become encumbered, it's really a case of going through the same sort of decision process. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [CONTENT] Re: identifying yourself at the mic
On Tue, 27 Mar 2007 10:49:23 -0400 Henning Schulzrinne [EMAIL PROTECTED] wrote: We built a prototype for ACM Multimedia 2004, using credit-card sized RFID badges and SIP event notification, shown on a separate projector. It worked reasonably well. I'm hoping to improve on the prototype as part of a student project, but may not make IETF 69. The Security Area is planning some very interesting experiments involving watching everyone else who's wearing RFID tags... --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFID (was: identifying yourself at the mic)
On Tue, 27 Mar 2007 11:27:29 -0500 Schliesser, Benson [EMAIL PROTECTED] wrote: Eric- It sounds like your argument is: We're too incompetent to say our names at the mic, so we're probably too incompetent to use a RFID system. Did I get that right? While I'm certainly not going to defend the competence of every IETF participant, I don't find much merit in that argument. In my (unscientific) first-hand experiences, it seems that most people do manage to wear their nametags at the meeting. And many of the names on those tags are of cultural origins other than my own, i.e. from a non-English speaking country. If I could actually see the name of the person speaking, it seems like a great improvement over hearing a name which is unintelligible to my ears or hearing no name at all. And if somebody forgets their RFID-badge, then I'm no worse off than I am today. I think his point was more what you cite below: In other words, I think we could come up with a system that worked well enough to be a net improvement over our current operational model. On the other hand, I am amused by your idea of scanning the streets for RFID responses that look like IETF-badges. Then my robot army could track down and kill all IETF participants whom oppose my plans to take over the Internet! Or maybe I could just use them for some fun practical jokes instead... RFIDs carry serious privacy risks, and IETFers *do* (and will) forget to take them off (and in this case, wrap them in aluminum foil or some such). To give just one example, does everyone in the IETF want everyone else to have the potential to know who's in which hotel rooms? --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pingsta Invitation
On Sat, 24 Mar 2007 11:20:28 +0100 Fred Baker [EMAIL PROTECTED] wrote: Thanks, Carsten and others. The general sense I arrive at is: - nobody that I recognize has said it's me, and here's what I'm doing. - clearly someone wants to make a business based on my (and presumably many of our) expertise - the email says something tantalizing about profit-sharing, but there is no contract there. Someone makes money, but I have no reason to believe it is me. Hence, for myself, I think I see no reason for me to join, and no reason for any of us to. Actually, I'd deleted the invitation I received, unopened, just based on the subject line -- it looked like the usual nonsense phrase spam message... Not that I'm going to join anyway -- people who know me know where to find me, and I don't need to help 3rd parties track me and my behavior. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Warning - risk of duty free stuff being confiscated on the way to Prague
On Sun, 11 Mar 2007 11:55:06 -0400 Marshall Eubanks [EMAIL PROTECTED] wrote: I know for a fact (because it happened to me Friday) that liquids are confiscated on the security check required to transit at London Heathrow. 100 milliliters is the limit, and this includes duty-free purchased elsewhere in-route. I believe there are similar issues for travel to the US -- see http://www.tsa.gov/travelers/airtravel/assistant/duty_free_travel_alert.shtm and http://www.tsa.gov/travelers/airtravel/assistant/duty_free.shtm --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: References to prior work (was: Re: Last call comments about draft-housley-tls-authz-extns-07)
On Mon, 05 Mar 2007 12:39:35 -0500 John C Klensin [EMAIL PROTECTED] wrote: How does adding a downref to a dead document add more integrity to the RFC process? Independent of the merits in this particular case, it provides history and context. We have learned, or should have learned, two things over and over again: (1) Failure to provide context and a track through rejected and alternative suggestions results in new proposals to try the same things again, usually from people who had no idea about the prior work. (2) Providing good documentation that recognizes the origins of an idea and its date, even if there were some changes from the original version, can be very helpful in defending our work against patent vultures who try to make filings on work that the IETF has had under development for some time. Personally, I've reached the point that I would favor having most protocol specification RFCs contain a sentence of the form of The work described here derives from a series of earlier drafts, including [ref, ref, ref] the first of which was circulated in 1968. In addition, in the general case, it can be argued that referencing prior work, even dead drafts is _required_ by the obligation to recognize and acknowledge the involvement of contributors of either ideas or text. Strong second. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ietf-moms
On Fri, 16 Feb 2007 12:06:51 -0500 Michael Richardson [EMAIL PROTECTED] wrote: Further, as the technology matures, one can't tell a 14-year old anything. (I've noticed the latter only second hand. Okay, I saw it on TV.) That gets worse, too, as the teenager progresses. I'm speaking from close-up observational experience of one current and one former teenager... --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-v6ops-natpt-to-historic (Reasons to Move NAT-PT to Historic Status) to Informational RFC
On Wed, 28 Feb 2007 20:42:04 -0500 Sam Hartman [EMAIL PROTECTED] wrote: Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED] writes: From: Fred Baker [mailto:[EMAIL PROTECTED] On Feb 28, 2007, at 8:02 AM, Hallam-Baker, Phillip wrote: The core assumption here seems to be that NAT is a bad thing so lets get rid of NAT rather than trying to make NAT work. ... The only protocol which really cares about the source and destination IP addresses is IPSEC and we have discovered that is a design error. I guess you haven't been around the applications that have trouble with this very much. Hallam-Baker, As I explained to you in private, you missed the Hallam-Baker, point here. My statement was carefully chosen and Hallam-Baker, the language very precise. You missed it. Hallam-Baker, IPSEC is as far as I am aware the only application Hallam-Baker, where the actual value of the sending and receiving Hallam-Baker, address is critical. This is because they are Hallam-Baker, cryptographically signed with a MAC address. I think this is more a statement about what protocols you've spent a lot of time with than about what people have done. in most IPsec deployments and in all of the other security protocols that have the same flaw. More precisely, any protocol that uses secondary connections, the parameters of which are carried in-band in a secured connection, can't easily be NATted. The most obvious example is FTP. 4217 notes that it only works through NAT if the client is aware of the NAT's existence, and that there are serious security issues even so. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Request for input (patchwork RFCs)
On Fri, 16 Feb 2007 14:40:12 -0800 (PST) Lucy Lynch [EMAIL PROTECTED] wrote: Sign me up! Is there a secret handshake? Do I get to wear a fez? We use public key handshakes these days. And it's f(e)^z. All of this is spelled out in the Security Considerations section of that club. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
On Fri, 09 Feb 2007 21:57:58 +0200 Jari Arkko [EMAIL PROTECTED] wrote: In any case, at the end of the day there is going to be someone who has to decide whether a particular proposal fits the purpose of the WG, the IETF or the RFC series. This someone can be the people in the WG, the sponsoring AD, the RFC Editor depending on what kind of a submission we are talking about, but there is always someone. And as Brian noted, if this someone misuses their power for personal reasons or some other reason, we have an appeals process. I'm not sure there's fundamentally any other way to handle this. And for IETF documents, that someone is just handling the beginning of the process and the proposal has to go through more review from the community. Right. The IETF is not a general-purpose publishing house for networking documents. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review comments for draft-ietf-pim-bidir-08
On Wed, 7 Feb 2007 21:14:35 -0800 Joseph Salowey (jsalowey) [EMAIL PROTECTED] wrote: I would like to understand better why ... no automated key management is specified. Do they cite any of the reasons listed in RFC 4107? --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ietf-moms
And think of the Security Considerations section. (And do we need IANA considerations, too?) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Referencing BCPs [Re: ion-procdocs open for public comment]
On Wed, 31 Jan 2007 11:54:26 -0500 John C Klensin [EMAIL PROTECTED] wrote: Except for the fact that the material being cited contains the specifics of license and IPR releases, and promises to abide by certain rules, by the authors. Authors can't reasonably be asked to agree to something that might be published under the BCP number in the indefinite future, so you are either stuck with a document (RFC) number or a BCP as of a specific date, which amounts to the same thing and is harder to track down. I'll let Jorge correct me if I'm wrong, but referencing by number,date is the norm in the legal world, since statutes do get amended without necessarily being renumbered. I do agree we want to make it easy for non-lawyers. I've suggested a date-stamped archive of each version of each such document, for precisely that reason. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
CNN Travel discovers Prague
http://www.cnn.com/2007/TRAVEL/DESTINATIONS/01/29/prague/index.html --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: MUST implement AES-CBC for IPsec ESP
On Sat, 20 Jan 2007 14:45:26 -0800 Lawrence Rosen [EMAIL PROTECTED] wrote: For ESP encryption algorithms, the document that was sent out for Last Call contains the following table: RequirementEncryption Algorithm (notes) --- MUST NULL (1) MUST- TripleDES-CBC [RFC2451] SHOULD+AES-CBC with 128-bit keys [RFC3602] SHOULD AES-CTR [RFC3686] SHOULD NOT DES-CBC [RFC2405] (3) The Last Call comment suggests changing the SHOULD+ for AES-CBC to MUST. Are any of these encryption algorithms patented? Almost certainly not. DES was patented, but the patent was never enforced; it has long since expired. (Trivia: IBM filed a statement saying that DES was royalty-free *if* used in one of the NIST-approvedd modes of operation. But they never went after anyone who used it in other ways.) To my knowledge, 3DES was never patented; even if it had been, it was first publicly described in 1979, so I doubt that any patent would still be valid. AES itself had to be unencumbered; see http://csrc.nist.gov/CryptoToolkit/aes/pre-round1/aes_9709.htm#sec2d . The designers of Rijndael never even attempted to patent it; see the text quoted in RFC 3602 or the old Rijndael home page. CBC dates from at least 1980 -- I seem to recall 1978, but I don't have a citation handy. That leaves CTR mode. I doubt very much that it's patented, since it's been very well known for many years and NIST rarely standardizes patented algorithms in this space (which I know you appreciate...). However, I don't have any citations to prove this negative. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: MUST implement AES-CBC for IPsec ESP
On Sat, 20 Jan 2007 13:34:54 -0800 Lakshminath Dondeti [EMAIL PROTECTED] wrote: What are the export implications due to this? A compliant ESP implementation MUST include the DES cipher due to this change. With status quo, a compliant ESP implementation can be used for integrity protection alone with NULL encryption. I don't understand your question. Apart from the Danvers doctrine -- the IETF makes technically sound decisions without regard to politics -- how do you conclude that DES MUST be included? The new document says SHOULD NOT. Russ Housley wrote: During the IETF Last Call for draft-manral-ipsec-rfc4305-bis-errata, we received a comment that deserves wide exposure. For ESP encryption algorithms, the document that was sent out for Last Call contains the following table: Requirement Encryption Algorithm (notes) --- MUST NULL (1) MUST- TripleDES-CBC [RFC2451] SHOULD+AES-CBC with 128-bit keys [RFC3602] SHOULD AES-CTR [RFC3686] SHOULD NOT DES-CBC [RFC2405] (3) The Last Call comment suggests changing the SHOULD+ for AES-CBC to MUST. I support this proposed change, and I have asked the author to make this change in the document that will be submitted to the IESG for consideration on the Telechat on January 25th. If anyone has an objection to this change, please speak now. Please send comments on this proposed change to the iesg@ietf.org or ietf@ietf.org mailing lists by 2007-01-24. Russ Housley Security AD ___ 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 --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-legg-xed-asd (Abstract Syntax Notation X (ASN.X)) to Proposed Standard
On Mon, 15 Jan 2007 09:47:06 +0100 Stephane Bortzmeyer [EMAIL PROTECTED] wrote: On Sat, Jan 13, 2007 at 10:05:35PM -0500, Steven M. Bellovin [EMAIL PROTECTED] wrote a message of 34 lines which said: And as you very well know, the IPR working group is fixing the problem. Is working on the problem. It is not the same thing. Nothing indicate that it will be fixed, specially since some people even deny there is a problem. Actually, I think we're quite close to a consensus document that does solve the embedded code problem. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Tracking resolution of DISCUSSes
On Mon, 15 Jan 2007 14:26:33 -0500 John C Klensin [EMAIL PROTECTED] wrote: Perhaps we should make it a requirement that any document that is Last Called must be associated with a mailing list, perhaps one whose duration is limited to the Last Call period and any follow-ups until the document is either published or finally rejected. If there were a WG, then the WG list should be a proper subset of that list, anyone commenting during the Last Call should be added to it, and others could be added on request. Actually, I think it's an excellent idea. Tracking Last Call comments was always difficult, since the email tended to end up in several different folders and wasn't archived elsewhere. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-legg-xed-asd (Abstract Syntax Notation X (ASN.X)) to Proposed Standard
On Sat, 13 Jan 2007 21:38:16 +0100 Simon Josefsson [EMAIL PROTECTED] wrote: Joel M. Halpern [EMAIL PROTECTED] writes: Simon, you are mixing several issues in your note, including strictly legal issues and personal preferences. I bring up only one issue here: Can implementers extract and use the ASN.1 module for their implementations legally? Firstly, it is clear that you (and every other implementor using this document) needs the ability to extract and use the ASN.1 include in the document. That is already provided for in BCP 78. The text he included is exactly the text that BCP 78 tells him to include to do that. So there is no problem there. I explained in my note that BCP 78 does _not_ provide for that. If you disagree with that, I think you need to show where BCP 78 gives third parties the right to extract and use the ASN.1 module. And as you very well know, the IPR working group is fixing the problem. I think a pointer to the archives there would have sufficed (or at least a mention of the discussion and status). --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Tracking resolution of DISCUSSes
On Tue, 9 Jan 2007 05:03:57 -0800 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: I have had the same experience. The tracker is not mentioned in any of the process documents or the desription of ietf process or the web site (which continues to be useless). The impression is of a clique who know their procedures internally, do nothing to explain them to others then get highly anoyed when their procedures are not followed. I am reminded of the planning department in Cruddy Cottington. While more information is always good, I'll note that it's linked to from the WG Chairs page; it, in turn, is listed on the IETF home page. There's also a link from each WG's charter page to the status page which lists every document from the WG and its status. The status field, in turn, is a link to the tracker page for that I-D. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Intermediate wg summaries
On Mon, 08 Jan 2007 10:24:23 -0800 Dave Crocker [EMAIL PROTECTED] wrote: I hope no one doubts the basic truth of Brian's observation. My own feeling, in fact, is that expecting all ADs to read even the final draft is an excessive burden. Either way, it leads to the basic question of how ADs can be informed of the salient issues in a wg effort, long before an IESG vote? Currently, wgs produce 4 things: charter, email list archive, meeting notes/summary, and output documents (specifications or whatever). None of these permits intelligent assessment of working group progress, by someone who is not significantly involved in a wg's on-going effort, without making a massive effort to review the archive and notes record. At best, the meeting summary is good for incremental issues, not summarizing integrated design (or syntax, or operations, or...) decisions. Given that working groups operate over many months or years, it seems like we need something that is a work-to-date design/decision summary. If a working group's effort is solid and defensible, along the way, then it ought to be reasonable to request that it produce a summary of its work-to-date in a fashion that allows useful, critical review, without having to dive into the considerable detail of a specification or the wg record. Dave, a lot of this discussion has boiled down to a single topic, one that's been talked about for a very long time: early, cross-area review. Unfortunately, we've tried several schemes that haven't worked and we don't really know how to do better. All have had some successes; none have scaled. It seems to boil down to this: if enough time and effort is invested, by ADs, WG participants, and reviewers, it can work. But it takes that kind of focus, and extra cycles by reviewers who aren't necessarily interested in the subject area are few and far between. Extra documents don't help much, either, because they're *strongly* resented by WG members who see them as just more process imposed by the IESG. I tried several things myself when I was AD. If I were still AD, I'd keep trying. But I don't have any new ideas, and I'm skeptical of repeating old ones. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories
On Fri, 5 Jan 2007 17:17:33 -0800 Cullen Jennings [EMAIL PROTECTED] wrote: On Jan 5, 2007, at 10:03 AM, Michael Thomas wrote: My gripe is when an outside AD takes an interest in the work, goes to the f2f meetings, maybe reads the drafts but then waits to IESG evaluation time to DISCUSS their issues. If they know they have a problem(s), it would be *far* better to air that sooner rather than later for all parties concerned. I agree with the earlier is better than later for comments from anyone, AD or not. A few interesting side cases on this. Some ADs (more than one actually) recently suggested to a WG that something there were doing was likely to result in in a DISCUSS when it reached the IESG. One of the WG members appealed the IESG trying to manipulate WG consensus. Sort of left me scratching my head on why the WG would not want to know that early but evidently some folks don't. It's a delicate balance. When I was an AD, I'd often post things saying AD hat=off ... /AD and the like; I've seen other ADs do the same thing, both on lists and in person. It's not clear that people always believe the disclaimer. Even more care is necessary when warning of a DISCUSS. Is that an accurate prediction of your own or someone else's liely views, or is it an attempt to get one's way by threatening to block a legitimate choice you don't like? How will it be perceived? On the other hand, I sometimes had long, detailed discussions with WG chairs and document authors, often at the instigation of the responsible AD, trying to convey my concerns ahead of time, trying to get things resolved to my satisfaction. Finally, there was one document I abstained on, because it was terminally broken and not repairable, but was the product of too many years work for me, as a relatively new AD (and hence as one who hadn't seen it before) to block. But I declined to say no objection, because I had very strenuous objections to it. I'm glad there's a document being written to set forth DISCUSS criteria. I had lots of discussions with Harald about the number I issued -- he wanted me to justify some of them with more than the text I wrote. Is this issue serious enough to block publication of the document as is? Obviously, I thought so, but not everyone on the IESG agreed with me on some of those cases. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria
On Sun, 31 Dec 2006 19:11:33 -0800 Lisa Dusseault [EMAIL PROTECTED] wrote: On Dec 31, 2006, at 2:27 PM, Lakshminath Dondeti wrote: There is perhaps one more aspect to Can somebody explain ... that is worth considering. In some cases, the AD simply does not have the expertise or simply has incorrect/wrong understanding. In that case, the burden is on the authors to help the AD understand the context of the work, provide references to reading material and such. Until the AD understands at his/her own pace, the work seems to languish (sure the authors do delay responses etc., but let us work on one problem at a time) in the IESG review stage. Sure. That could happen. But it's not usually the case that an AD who knows that they don't understand something, holds a DISCUSS on a document for a long time, all the while getting useful responses and help from authors. I sure wouldn't feel comfortable doing that. Right. The usual AD vote is no objection, not yes. No objection includes I don't know enough to have a problem with this. In such cases, I looked at the parts I did understand -- that, of course, included authentication and (if appropriate) confidentiality -- and worried about those, and didn't worry nearly as much about arcana at other levels. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IESG Success Stories (was: Discuss criteria)
On Sat, 30 Dec 2006 07:09:21 -0800 Michael Thomas [EMAIL PROTECTED] wrote: The other thing that occurs to me -- and I know this has been brought up in many different forms -- is that if an AD _was_ following the working group to some degree, why is it legitimate for them to wait for IESG evaluation to voice comments that affect the protocol's operation? Most ADs don't follow most WGs in any detail -- they can't possibly do so. They should (and generally do) follow their own WGs, possibly the others in their area, plus one or two elsewhere that they're personally interested in. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria
On Fri, 29 Dec 2006 17:05:12 -0800 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: There is another problem to do with consensus and the status quo. Say we have a situation where a clear majority of a working group believes that a spec is unworkable unless a particular change is made. A small minority opposes the change for ideological reasons. Should the outcome in this case be: 1) Neither proposal can advance until there is consensus 2) The status quo proposal trumps the position with majority support 3) The majority position is adopted. 4) Both proposals advance In the case that the proposal is an additional feature then 3 and 4 are essentially the same. The problem here is that the positions that are most likely to be held hostage by DISCUSS are cases like this one where there is a clear majority in favor of change but the minority see absolutely no reason to compromise because they consider that they hold an effective veto, the majority can go hang. If it's a small enough minority, in theory that isn't enough to block progress. 2418 says IETF consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group shall prevail. (However, it must be noted that dominance is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement.) Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as rough consensus and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Review of draft-manral-ipsec-rfc4305-bis-errata-02.txt
On Mon, 11 Dec 2006 09:55:33 -0600 Nicolas Williams [EMAIL PROTECTED] wrote: Also, I'm not sure that the use of MUST- and SHOULD+ is actually useful. In this update no algorithms previously classified as MUST- have been downgraded, and no algorithms previously classified as SHOULD+ have been upgraded. It seems likely to me some AES cipher mode will eventually become a MUST, but it's not clear to me that AES-CBC, for example, which is marked SHOULD+, will be it. Therefore I would argue that these designations should be changed to MUST and SHOULD, respectively. Or perhaps this I-D is a good opportunity to downgrade TripleDES-CBC to SHOULD or MAY and upgrade either AES-CBC and/or AES-CTR to MUST? I'm not sure it's feasible yet to make 3DES a SHOULD; it's quite clear to me that AES-CBC should become a MUST. We can't make AES-CTR the only MUST unless we abolish manual keying. I could probably deal with AES-CTR and AES-CBC both being mandated, but I'm really not a fan of counter mode; it's just too easy to make bad mistakes. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DNS Choices: Was: [ietf-dkim] Re: Last Call: 'DomainKeys
On Wed, 6 Dec 2006 10:45:21 -0800 (PST) David Morris [EMAIL PROTECTED] wrote: It isn't a trivial technical problem to revise the electronic message infrastructure to arrange for payment of postage but to assert that it can't be done or wouldn't be deployed flys in the face of the relatively short time frame for adoption of the WWW or IM. The problem, of course, is that the spammers would steal email postage the same way they steal cycles and bandwidth. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DNS Choices: Was: [ietf-dkim] Re: Last Call: 'DomainKeys
On Tue, 05 Dec 2006 22:27:09 -0500 Jeffrey Hutzelman [EMAIL PROTECTED] wrote: On Wednesday, November 22, 2006 04:00:49 PM + Tony Finch [EMAIL PROTECTED] wrote: On Wed, 22 Nov 2006, [EMAIL PROTECTED] wrote: SMTP, on the other hand is an operational failure and even today, no one really knows how to properly implement and properly maintain an SMTP service. The actions of criminals exploiting weaknesses in the SMTP architecture have led to a series of bandaids that still have not proven to be effective. Any communications mechanism which allows you (or your organization) to receive messages from people (or organizations) you have no prior relationship with is vulnerable to spam. Spam is NOT an SMTP problem. Correct. For example, the postal mail system is vulnerable to this same problem: As is my usual practice, I asked the post office to hold my mail while I was away at IETF 67 (this is a standard service offered by the US Postal Service at no charge). I took some time off after, so when I finally picked up my mail, it was about 3 weeks worth. I received a plastic shopping bag full of mail, and after I sorted through it, I had several bills and a grand total of three other pieces, all of which were prearranged (an issue of QST, a newsletter, and an invitation). The rest of the bag was spam. Right. OTOH, the folks who send physical spam don't hijack other people's postal meters, and the products they're selling usually exist... --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IM and Presence history
On Wed, 29 Nov 2006 10:33:15 -0800 Dave Crocker [EMAIL PROTECTED] wrote: The underlying specifications permit you to have different addresses, for different services. They also permit you to have the *same* address. This is only a good idea if coupled with a powerful, easy-to-use interface that restricts presence visibility. Many more people have my email address than my IM addresses; I'm also very careful about who gets my mobile phone number. Why? Because IM communication and phone calls interrupt me in a way that email does not. In fact, I take advantage of email to avoid giving out the other information promiscuously -- I tell people who perceive an urgent need to reach me to email page-smb at the appropriate domain; this address is translated to both SMS and a direct email message. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Something better than DNS?
On Tue, 28 Nov 2006 11:45:56 +0100 Stephane Bortzmeyer [EMAIL PROTECTED] wrote: That's the problem with most one namespace, several registries proposals. There is still a registry to coordinate the so-called several registries so you're back to step 1. Most? I'd have said all. The name space is a tree, and (for almost all purposes except web browsing, and maybe even then) has to be one. (Reread 2826.) This says nothing about how one arbitrates the nodes of the tree at any level, including quite specifically the root node and the nodes directly underneath it (i.e., the TLDs) -- it can be the current ICANN, a replacement body, co-operation, bidding, or the ghost of Jon Postel -- but the nodes *must* be distinctly named if name resolution is to work. For those who like alternate roots, you can either assert that our TLD registrars would never compete (the co-operation model) or you force people trying to use these resolvers to know which one to use. In that case, the pointer to the proper resolver is the real second-level node, and the real root is whatever designates that name space. In other words, you haven't changed the model, you've just added another level (and created trouble besides). --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Fwd: The IESG Approved the Expansion of the AS Number Registry
On Mon, 27 Nov 2006 14:16:33 -0500 Russ Housley [EMAIL PROTECTED] wrote: I believe that this note should have been CCed to this mail list. I believe this action is of general interest. Do you want me to forward this to the NANOG list? To: IANA [EMAIL PROTECTED] From: IESG Secretary [EMAIL PROTECTED] Date: Mon, 27 Nov 2006 09:56:13 -0500 Cc: iesg@ietf.org Subject: The IESG Approved the Expansion of the AS Number Registry Dear IANA, The IESG has approved the expansion of the size of the AS Number registry described in draft-ietf-idr-as4bytes-12.txt before the approval of the document. Please expand the AS Number space to include the values 65536 through 4294967295, initially marked as Held by IANA. Allocations can be made to the RIRs prior to the publication of this RFC. Thank You, The IESG ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: with merit?
On Thu, 19 Oct 2006 12:29:07 -0400, Robert Sayre [EMAIL PROTECTED] wrote: OK. I want to write a document that makes MTI a non-requirement for HTTP1.1-based protocols, because I believe that is the consensus in the HTTP community. How do I get that done? Are you trying to change general IETF policy on security requirements or just get an exception for this one case? Either way, you need to write an I-D. The latter would be easier -- the I-D should be structured as a process variance. It should explain why this particular case should be exempt from the usual requirements for secure protocol design. Such RFCs are unusual but not unprecedented; Alex Zinin and I wrote one, RFC 4278, -- and it was a security-related variance -- where we knowingly approved a security protocol that does not meet today's standards. (More precisely, the variance was to approve a downref in maturity, to let a Draft Standard have a normative dependency on a Proposed Standard security document, because the security document is too flawed to be promoted to Draft. 4278 explains why we think it's acceptable in this context.) (Note, btw, that I'm not familiar with the specifics of this particular protocol, so I have no opinion on whether or not I personally would support such a waiver.) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
