Re: what is a threat analysis?
Ned Freed wrote: Brian E Carpenter wrote: Michael, you've had some quite concrete responses which I hope have clarified things, but I really want to say that making Internet protocols secure isn't a hoop jumping exercise; it's more like a survival requirement, and has been for ten years at least. Where did I say that? Of course you didn't, and the implication that you did say that was nothing but a strawman, a tactic I'm sad to say often seems to crop up in discussions on the IETF list. Excuse *me* but Mike's note that I was responding to said (in part): So, if this is going to be yet another hoop that the IESG and IAB sends working groups through like problem statements, requirements documents and the like, I think it ought to be incumbent on those people demanding such things to actually both agree and document what it is that they are demanding. He explicitly raised the question of hoop jumping, which for me at least carries a strong implication of pointlessness. That's what I was responding to. More recently he said: Do you seriously think you could write a threat analysis given the definition in 2828? which reads $ threat analysis (I) An analysis of the probability of occurrences and consequences of damaging actions to a system. As a glossary definition, that seems admirably clear. For a complex case, I'd expect to ask some experts for help in determining the type of threats to be considered in particular. And I would study 3552 carefully, warts and all. But the bottom line is that this is hard work to get right - compare the Security Considerations of RFC 3056 with RFC 3964 for example. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what is a threat analysis?
Brian E Carpenter wrote: Ned Freed wrote: Brian E Carpenter wrote: Michael, you've had some quite concrete responses which I hope have clarified things, but I really want to say that making Internet protocols secure isn't a hoop jumping exercise; it's more like a survival requirement, and has been for ten years at least. Where did I say that? Of course you didn't, and the implication that you did say that was nothing but a strawman, a tactic I'm sad to say often seems to crop up in discussions on the IETF list. Excuse *me* but Mike's note that I was responding to said (in part): So, if this is going to be yet another hoop that the IESG and IAB sends working groups through like problem statements, requirements documents and the like, I think it ought to be incumbent on those people demanding such things to actually both agree and document what it is that they are demanding. He explicitly raised the question of hoop jumping, which for me at least carries a strong implication of pointlessness. That's what I was responding to. So you've fixated on the word hoop. Fine. Delete it and the original question still stands. More recently he said: Do you seriously think you could write a threat analysis given the definition in 2828? which reads $ threat analysis (I) An analysis of the probability of occurrences and consequences of damaging actions to a system. As a glossary definition, that seems admirably clear. I repeat: could you write a threat analysis based upon the definition in 2828? That was suggested by somebody as being adequately defined for my original question. For a complex case, I'd expect to ask some experts for help in determining the type of threats to be considered in particular. And I would study 3552 carefully, warts and all. But the bottom line is that this is hard work to get right - compare the Security Considerations of RFC 3056 with RFC 3964 for example. The reason I brought this to this list is because there's no clarity about what is meant by a threat analysis, though it seems to be cropping up more and more in the IETF process (look ma! no hoops!). If it's going to be part of our process, then I think its incumbent on those who want to impose the process to be clear about what they're asking for, and for that process to not be an idiosyncratic. The waste of time here is not the process per se, but the work on drafts, etc, that are not what the person making the demand is asking for. Do you have an objection to clarity in process? Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: what is a threat analysis?
The reason I brought this to this list is because there's no clarity about what is meant by a threat analysis, though it seems to be cropping up more and more in the IETF process (look ma! no hoops!). If it's going to be part of our process, then I think its incumbent on those who want to impose the process to be clear about what they're asking for, and for that process to not be an idiosyncratic. The waste of time here is not the process per se, but the work on drafts, etc, that are not what the person making the demand is asking for. Do you have an objection to clarity in process? I personally consider threat analysis an integral part of protocol design. A well written security consideration should read very much as a threat analysis: what are the system's assets that need protection; what are the possible interfaces through which attacks can be conducted; enumerate the likely attacks through those interfaces; ensure that all these attacks are properly mitigated. Doing that at design time is much easier than trying to retrofit security when attacks are found in the wild. As Eric Fleischman pointed out, doing good security analyses requires training. In particular, the enumeration of possible attacks looks very much like a brainstorming session, and relies on the expertise of working group members. However, members of an engineering organization like the IETF ought to be eager to acquire such training. I mean, do you really want to design insecure protocols? For those interested in self training, I recommend the book Writing Secure Code, Second Edition by Michael Howard and David LeBlanc (http://www.microsoft.com/mspress/books/5957.asp). -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what is a threat analysis?
On Aug 16, 2005, at 3:54 PM, Christian Huitema wrote: For those interested in self training, hello christian, hello experts i saw that you are involed in IVS with Thierry Turletti from the early days on A set of four Internet-Drafts specifying the RTP protocol were issued in December 1992, and an Internet-Draft on packetization of H.261 coded video was issued in March, 1993. In addition, RTP has been implemented to varying degrees in the following programs: ... IVS Thierry Turletti and Christian Huitema MavenCharley Kline http://mirror.switch.ch/ftp/doc/ietf/avt/avt-minutes-93mar.txt Whitch drafts your talking about ? And where can i find something about MAVEN ? any pointers would be greatly appreciatet best regards marcM. http://www.wjt2005.de/ smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what is a threat analysis?
Ned Freed wrote: Brian E Carpenter wrote: Michael, you've had some quite concrete responses which I hope have clarified things, but I really want to say that making Internet protocols secure isn't a hoop jumping exercise; it's more like a survival requirement, and has been for ten years at least. Where did I say that? Of course you didn't, and the implication that you did say that was nothing but a strawman, a tactic I'm sad to say often seems to crop up in discussions on the IETF list. Excuse *me* but Mike's note that I was responding to said (in part): So, if this is going to be yet another hoop that the IESG and IAB sends working groups through like problem statements, requirements documents and the like, I think it ought to be incumbent on those people demanding such things to actually both agree and document what it is that they are demanding. He explicitly raised the question of hoop jumping, which for me at least carries a strong implication of pointlessness. That's what I was responding to. It carries no such connotation for me. www.dictionary.com says the phrase means To undergo a rigorous trial or examination. Encarta says it means to go to extreme lengths to gain favor with somebody or to carry out somebody's wishes (informal). Nothing pointless in either definition as far as i can see. But let's assume that's what Mike meant. So what? It doesn't change the thrust of his argument in any way, which was and is that there are a variety of ways a threat analysis can written in this space and we're not sure which one of these is needed. More recently he said: Do you seriously think you could write a threat analysis given the definition in 2828? which reads $ threat analysis (I) An analysis of the probability of occurrences and consequences of damaging actions to a system. As a glossary definition, that seems admirably clear. I disagree and think as definitions go it is pretty poor, but let's assume for the moment it is clear. Again, so what? It's still just a definition, not a guide for how to write these things. Are you seriously going to claim that this is all you need to know to write a threat analysis? You say below that getting these things right is difficult. And in another part of this thread we have people asserting that some amount of training is needed to write the things. For a complex case, I'd expect to ask some experts for help in determining the type of threats to be considered in particular. And I would study 3552 carefully, warts and all. But the bottom line is that this is hard work to get right - compare the Security Considerations of RFC 3056 with RFC 3964 for example. All the more reason for those in charge to be quite specific about what it is they're after, which still hasn't happened. All we get is more fixation on the words Mike happened to use in one message rather than responding to his issue with the lack of clarity in what's being asked for. You really need to start looking at the points people are trying to make rather than focusing on the words people happen to choose make them. Not everything is an attack on some dearly-held IETF principle or other, you know. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: what is a threat analysis?
No, Jeff. Most threat analysis with which I am familiar are in regards to a specific deployment or technology within explicit boundaries (i.e., a predefined context). Even so, I would never characterize my own work as addressing all possible threats in that context, because new exploits are continually being devised. One can identify classes of threats and establish controls to address the more worrisome ones within the constraints of ones schedule, budget, personnel, and available technology. Threat analysis provides management with additional information to assist them to make hard choices regarding feature definition and allocation of resources. However, in the IETF context, I imagine that its principal function would be to identify security issues that protocol design may (or may not) seek to mitigate. If it is known during design that the protocol is inherently vulnerable to certain classes of exploits, then perhaps that protocol could be designed with hooks to leverage another technology that addresses those exploits. --Eric From: JFC (Jefsey) Morfin [mailto:[EMAIL PROTECTED] Therefore, I fear that either the security community will become even more overworked or else a whole lot of not-very-helpful text will be produced or else non-security people will become de facto security people. I'm hoping for the third result, but I fear the first two. Are your threat analysis covering all the possible threads on the equipement as well as on the installations, processes, services, communities, persons, cultures, etc. behind them? thank you ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what is a threat analysis?
All the more reason for those in charge to be quite specific about what it is they're after, which still hasn't happened. All we get is more fixation on the words Mike happened to use in one message rather than responding to his issue with the lack of clarity in what's being asked for. Minor comment about the still: It's a very short time after the IETF meeting. And it's August. Area Directors are allowed to take a vacation, and even have no Internet connectivity during the time. Not-so-minor comment about guidance: I am hard-pressed to believe anyone will argue against the utility of a guidance document. In fact that's why some of us suggested it to EKR during IETF week and it is why I made my IETF plenary comment. Since EKR has a track record of producing security-related document for non-security geeks, I'm hopeful we will get something useful. But most of the IETF works has been done without benefit of such guidance documents. We have relied on the communication of guidance and criteria through other means. So I think the real question is whether reasonable, clear, stable criteria are being communicated? Since the threat analysis requirement is newly-imposed on the rest of us, one can expect a period of time where the communication is iterative and maybe even looks like a negotiation. The question, for this particular requirement, is whether there is a process to converge on clarity and stability for the requirement. Although it is early days, I am hopeful. (It helps that the construct involved has substantial history within the security community.) So the question about the threat analysis requirement is whether an effort that has this requirement imposed on it gets the help it needs to satisfy it? Noting that, in reality, an IETF effort always has quite a few requirements imposed on it, my own view is that most early-stage IETF efforts gets vastly less help than is needed. The truth of that matter is that we mostly rely on a self-forming group to figure things out on its own. At most, we assign a relatively experienced IETFer to help, but I'm not convinced that that helps as much as we would like. For DKIM, our AD met with the design team at the beginning of IETF week and met with me at the end. He tried to give us pragmatic guidance at the beginning of the week. Some of seem to have understood it and some of us clearly did not. Also, EKR sent an extended note about threat analysis to the MASSS mailing list, prior to our BOF, rather than just showing up at the microphone and lobbing a bomb at us. I see two questions leading from the fact of our own confusion about the requirement: 1. Is there something useful we can do on our own about this? 2. Are we (going to get) assistance from our AD? The answer to #1 *can be* yes. As is clear from a number of the threads on the DKIM list, the group is not all that cohesive or clear about the functional requirements DKIM is intended to satisfy. An analysis of the threats that DKIM is intended to respond to can significantly help resolve the confusion, separate from whether that analysis is exactly what we have been asked for. That is, getting the group to be clear and cohesive (rough consensus) about the goals, motivations, concerns, whatever of DKIM is an inherent good. And, indeed, there is some potentially useful discussion proceeding. The answer to #2 is simply yes. Russ (and, by the way, Sam) are trying to be helpful. As someone with lots of practice complaining about pretty much everything, I could express all sorts of wishes about how things could be better. However the fact of the matter is that they are looking for ways to improve the likelihood of success and they are clearly willing to iterate with us to get there. It is difficult to reasonably ask for more. That said, I hope we keep the pressure on, to get a document that specifies the threat analysis requirement in a way that is both clear and useful for working group productivity. -- d/ Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what is a threat analysis?
All the more reason for those in charge to be quite specific about what it is they're after, which still hasn't happened. All we get is more fixation on the words Mike happened to use in one message rather than responding to his issue with the lack of clarity in what's being asked for. Minor comment about the still: It's a very short time after the IETF meeting. And it's August. Area Directors are allowed to take a vacation, and even have no Internet connectivity during the time. It seems a bit unlikely all of dozen or so relevant people are simultaneously on vacation, but perhaps that's indeed the case. If so, that's fine, but (a) A simple statement to that effect would sure have been nice and (b) We should then refrain from attempting to construct something that's likely to be the wrong thing in the meantime. (It should be obvious why getting far down a specific path, only to be told it is the wrong path later, is a bad idea.) Not-so-minor comment about guidance: I am hard-pressed to believe anyone will argue against the utility of a guidance document. And indeed, nobody is making such an argument. Can we finally put this strawman to bed, or light it on fire, or do whatever it is you do to get rid of strawmen? In fact that's why some of us suggested it to EKR during IETF week and it is why I made my IETF plenary comment. Since EKR has a track record of producing security-related document for non-security geeks, I'm hopeful we will get something useful. But most of the IETF works has been done without benefit of such guidance documents. This has also been pointed out repeatedly. We have relied on the communication of guidance and criteria through other means. So I think the real question is whether reasonable, clear, stable criteria are being communicated? That's the question in a nutshell. And it is my belief that this is not happening. Since the threat analysis requirement is newly-imposed on the rest of us, one can expect a period of time where the communication is iterative and maybe even looks like a negotiation. I would not characterize it as such. An iterative clarifying process might serve to crystallize management thinking as to what's needed, but ideally it should not result in the sorts of changes implied by a give-and-take negotiation process. The question, for this particular requirement, is whether there is a process to converge on clarity and stability for the requirement. Although it is early days, I am hopeful. (It helps that the construct involved has substantial history within the security community.) Numerious recent events compell me not to share in your enthusiasm. As John Klensin has remarked in a separate thread, it now seems that the stock response to any suggestion or criticism whatsoever is either some sort of strawman or reductio ad absurdum argument. So the question about the threat analysis requirement is whether an effort that has this requirement imposed on it gets the help it needs to satisfy it? I confess to a bit of amusement in seeing that you yourself have characterized this in terms of imposed requirements. If I were Brian no doubt i could read volumes into this choice of words. As it happens I don't think of this as an imposed requirement, although the way this has been handled may make it seem that way. Rather, I see the need for careful analysis as an unavoidable consequence of the specific space we're working in. The security folks are merely pointing this out. Noting that, in reality, an IETF effort always has quite a few requirements imposed on it, my own view is that most early-stage IETF efforts gets vastly less help than is needed. I have believed this ever since some years back the chair of a WG-to-be flew down from the bay area to literally knock on my door here in LA to ask for help getting his group chartered. (No, I am not making this up.) The truth of that matter is that we mostly rely on a self-forming group to figure things out on its own. At most, we assign a relatively experienced IETFer to help, but I'm not convinced that that helps as much as we would like. For DKIM, our AD met with the design team at the beginning of IETF week and met with me at the end. He tried to give us pragmatic guidance at the beginning of the week. Some of seem to have understood it and some of us clearly did not. Also, EKR sent an extended note about threat analysis to the MASSS mailing list, prior to our BOF, rather than just showing up at the microphone and lobbing a bomb at us. I see two questions leading from the fact of our own confusion about the requirement: 1. Is there something useful we can do on our own about this? 2. Are we (going to get) assistance from our AD? The answer to #1 *can be* yes. Of course it can. There is always a chance that if I spin around and shoot a gun at random I'll hit the target. It just seems like we
Protocol Action: 'Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)' to Proposed Standard
The IESG has approved the following document: - 'Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) ' draft-hollenbeck-epp-secdns-08.txt as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-secdns-08.txt Technical Summary This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security extensions (DNSSEC) for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. Working Group Summary This document was received as an invidual submission and is not the product of an IETF working group. Protocol Quality This document was reviewed for the IESG by David Kessens and was also reviewed by the dnsop working group. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
