Re: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06
David, Steve, I think the modified introduction text suffices to connect the PATHSEC and BGPsec terms, but I don't think that referring to the SIDR WG charter for the PATHSEC goals is reasonable -- an RFC is an archive document, whereas a WG charter is not. The revised intro text now paraphrases the text from the SIDR charter that describes the path security goals. Steve
Re: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06
David, Since this doc logically precedes the BGPsec design, I still think it's appropriate to use PATHSEC here. But, we can add a sentence to connect the terms. I propose this modified text for the introduction: *This document describes the security context in which PATHSEC is intended to operate. **(The term "PATHSEC" is employed in this document to refer to any design used to achieve the path security goal**described in the **SIDR WG charter. **The charter focuses on mechanisms**that will enable an AS to determine if the AS_path represented in a route**represents the path via which the NLRI traveled. Other SIDR documents use the term "BGPsec" to refer to a specific design.) ... * The phrase "calls for" seems appropriate in the cache discussion. There is no MUST in the RFCs about using a local cache. The docs encourage RPs to maintain a local cache, and 6481 states that not using one is "NOT RECOMMENDED." All of the RP software of which I am aware does so, but it is not an absolute requirement. I think we've agreed that quoted is a static assertion and thus need not be annotated to reflect more recent RFCs. Steve
Re: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06
David, Major issue: This draft contains more than just a threat model. agreed. It also contains a high level security analysis of the security architecture/approach that applies the RPKI to secure use of BGP. yes. we didn't create a threat model doc for the RPKI, and this seemed like a good time to address that omission, since the SIDR charter mandates use of the RPKI as a basis for the path security design. That analysis appears to be good, but it's somehow disconnected from the rest of the sidr WG's work, by what I hope is simply a terminology problem: - This draft refers to the security architecture/approach for BGP as PATHSEC. - Many of the other sidr WG draft refer to that security as BGPsec In effect, the PATHSEC security architecture/approach appears to be implicit in this draft. The term PATHSEC is used to refer to a generic path security solution approach, consistent with the WG charter, rather than to the specific solution approach, BGPsec, that has been developed. The rationale for using the different term is that this threat doc should precede the requirements doc, which should precede the solution design. In reality, the requirements doc was generated before the threat analysis, and the BGPSEC design was well along before this doc was finalized. Earlier versions of the doc did refer to BGPsec, but the term was changed for the reasons cited above. This doc does embed assumptions about what a general path security architecture would entail, e.g., based on prior work on such architectures, e.g, S-BGP. Something's missing - if those two terms were meant to be the same, BGPsec should probably be used in this draft, otherwise, the relationship should be described. I've tagged this as a major issue, as it makes text like the following in Section 4.2 rather unclear: I hope my explanation above explains why the terminology was adopted. Stale Path Announcement: If PATHSEC-secured announcements can expire, such an announcement may be propagated with PATHSEC data that is "expired". This behavior would violate the PATHSEC goals and is considered a type of replay attack. What is "PATHSEC data"? What are "the PATHSEC goals"? The statement in the abstract that " We use the term PATHSEC to refer to any BGP path security technology that makes use of the RPKI" doesn't seem to answer these questions. PATHSEC data is whatever data is sent via a path security design to enable an AS to verify that the UPDATE has traversed the indicated set of ASes. The goals for PATHSEC are the ones stated in the SIDR WG charter . (The relevant charter text used to appear up front, but was removed at the request of the WG chairs and the cognizant AD. The relevant text appears in this version on page 16, as part of the residual vulnerabilities discussion.) Minor Issue: Section 4.4 seems somewhat loose on caching by RPs, considering the importance of that caching in countering a number of the attacks described in that section - in multiple cases, RP detection of an attack relies upon the RP noticing that something has changed at the publication point wrt the RP's cached copy in a fashion that should not have happened. Statements such as "the RPKI calls for RPs to cache" and "RPs are expected to make use of local caches" strike me as a weak foundation for the level of security dependence on that caching. A pointer to a SHOULD or MUST requirement for caching by RPKI RPs in another document would alleviate this concern; surely that language exists somewhere. The RPKI mandates caching (see RFCs 6480 and 6481), and since use of the RPKI as a basis for PATHSEC is mandated by the SIDR charter, I didn't feel it was necessary to repeat that here. But we can include a cite: Note first that the RPKI calls for RPs to cache the data they acquire and verify from the repository system *[RFC6480, RFC6481]*. Nits/editorial comments: Also in Section 4.4: (The RP would be very unhappy if there is no CRL for the CA instance anyway.) Please rewrite to describe how the RP reacts to failure to find a CRL - the RP surely does something in addition to becoming "very unhappy" ;-). Some of that may already be in the sentence immediately following the "very unhappy" text. I'll remove the flippant parenthetical. You're right that it isn't useful. idnits 2.12.17 complains about a missing reference: == Missing Reference: 'TCPMD5' is mentioned on line 114, but not defined That citation is embedded in a quote from RFC 4272, nonetheless, [TCPMD5] should be informatively referenced here - it was RFC 2385, which has been obsoleted by RFC 5925, which is referenced here. The fact that RFC 2385 is obsolete will generate a different idnits warning, which is ok to ignore. I disagree, and I discussed this with Stewart previously. The reference appears in a quote and was appropriate at the time the quoted text was generated.
Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08
David, I agree with Sam here. The key table is analogous to the SPD in 4301, but not the PAD. Another doc being developed in the KARP WG does have a "Routing Authentication Policy Database" (RAPD) that incorporates aspects of the PAD from 4301, as well as some SPD fields. Steve
[sidr] Last Call: (Algorithm Agility Procedure for RPKI.) to Proposed Standard
The tech report cited in Eric's message is not a critique of the SIDR algorithm agility document that is the subject if this last call. The tech report is a critique of the overall SIDR repository system and object retrieval paradigm, with an emphasis on the speed with which relying parties (principally ISPs) will be able to acquire RPKI data. The RPKI repository system is defined in RFC 6481; the RP object retrieval approach is described in RFC 6480. The tech report includes assumptions about the addition of many instances of additional objects (router certs) to the RPKI repository system, but these assumptions are based on I-Ds that are in process in SIDR, and thus may be the more appropriate focus of the report, in terms of responses. The tech report includes no specific criticisms of the algorithm agility mechanism described by the I-D in IETF LC, nor does it suggest any changes to this doc. An extensive discussion of the tech report took place on the SIDR list, in early December. That discussion also did not suggest any proposed changes to the algorithm agility doc. Thus the authors do not plan to make any changes as a result of this comment being posted during IETF LC. Steve Kent (on behalf of Roque Gagliano and Sean Turner)
Re: [Gen-art] Gen-ART review of draft-ietf-dnsop-dnssec-dps-framework-08
Joe You're right, I did miss your point, quite thoroughly :-) I am guessing that the answer is that there's no corresponding facility in DNSSEC to for a policy identifier to be published with a DNSKEY RR, but I say that largely ignorant of X.509 and attendant CA policy and hence perhaps am still misunderstanding what you're looking for. In X.509 each cert can contain a policy OID that indicates the policy under which the cert was issued. Thus, when a CA changes it's policy it can issue certs under the new policy with the new policy OID. This makes it clear to relying parties what policy is in effect, and when a CA changes its policy, irrespective of other changes, e.g., key rollover. Steve
Re: Last Call: (The RPKI/Router Protocol) to Proposed Standard
The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'The RPKI/Router Protocol' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf at ietf.org mailing lists by 2011-12-13. Exceptionally, comments may be sent to iesg at ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. I am familiar with this document and support its advancement. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
I support this doc, and concur with Stewart's comments. Contrary to what some have suggested, we sometimes (ofttimes?) have more than one standard for no good technical reason. Sometimes very large, competing companies back different standards for parochial reasons, to the detriment of consumers, service providers, etc. This appears to be one of those cases. Moreover, not opposing a two-standard approach sends a bad message, and encourages similar, bad behavior in the future. As the co-chair of PKIX, which has two standards for cert management (CMC and CMP), for exactly the bad reasons I cite above, I am intimately familiar with this sort of problem. I failed, in my role as PKIX co-chair, to prevent this in that WG. Let's not repeat that sort of mistake here. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
At 10:32 AM -0400 5/4/11, Sam Hartman wrote: >... Let me see if I can summarize where we are: You've describe an upgrade strategey for the origin validation in the current set of docs. It depends on the ability to store multiple certs, ROAs and other objects in the repository. requirements that already exist to accommodate key rollover and alg transition for the RPKI. We have a SIDR doc describing both key rollover, You agree that when SIDR looks at using RPKI objects in the newly adopted work it will need some upgrade strategy for format, keys and algorithms. There are probably a number of options for how to accomplish this. Even if the working group did decide to update processing of RPKI objects at that point, requiring new behavior from parties implementing a new protocol would be possible. I find your last sentence above confusing. I would say that the BGPSEC protocol will have to define how it deals with alg changes for the signed objects it defines, with key changes for RPKI certs, with alg changes for all RPKI objects, and with format changes for RPKI objects and for its own objects. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
At 7:48 AM -0400 5/4/11, Sam Hartman wrote: >>>>> "Stephen" == Stephen Kent writes: Stephen> The BGPSEC protocol being defined does not pass around ROAs Stephen> or other RPKI repository objects. It defines two new, Stephen> signed objects that are passed in UPDATE messages, and are Stephen> not stored in the repository. These objects are verified Stephen> using RPKI certs and CRLs, so there is a linkage. OK, so how will the upgrade work for these signed objects? In particular during phase 2, when both old and new certs (under the old and new profile) are in use, what happens with these signed objects? Can a party generate both old and new signed objects? If so, will the protocol scale appropriately? If not, how does a party know which signed object to generate? Sam, The BGPSEC protocol will have to accommodate changes in the algs used to validate BGPSEC signed objects, and changes in algs used to validate RPKI objects, and key (not alg) changes in the RPKI objects, especially the certs associated with routers. So, format changes are just another example of a change in the RPKI that BGPSEC will have to accommodate. This is a legitimate discussion point for the BGPSEC protocol design discussions that will take place in SIDR. It is out of scope for the current set of docs, since they deal only with origin AS validation. It would be inappropriate to suggest delaying this doc (or to suggest changes to it) based on discussions that will take place in the future, for a protocol that is just being adopted as a WG item now. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
At 6:07 PM -0400 5/3/11, Sam Hartman wrote: >>>>> "Stephen" == Stephen Kent writes: >> >> I guess the only question I'd have remaining is whether ROAs or >> other signed objects are intended to be used in other protocols >> besides simply living in the SIDR repository? Stephen> The RPKI repository is designed to support a specific, Stephen> narrow set of apps. That's what the CP says, and we try to Stephen> make these certs unattractive for other apps, e.g., by use Stephen> of the non-meaningful names. You had mentioned that about the PKI before. Now, though I'm focusing on the ROAs and other signed objects, not the certificates and CRLs. Do these narrow applications involve simply storing these objects in the repository, or are there plans to use ROAs or other signed objects as elements in protocols? At least years ago, for example, there was discussion of carrying signatures of objects in BGP. I understand that's not within SIDR's current charter, but is SIDR intended to support that style of use, or have things been narrowed to a point where that would require reworking details of the repository and PKI? If the answer is that those sorts of uses are not in scope for the SIDR architecture, then I think you've basically resolved my concerns. Sam, You might want to look again at the SIDR charter, since it has just been revised to include BGP path validation. The path validation approach being pursued makes use of the RPKI, consistent with the scope of the CP, not surprisingly. The BGPSEC protocol being defined does not pass around ROAs or other RPKI repository objects. It defines two new, signed objects that are passed in UPDATE messages, and are not stored in the repository. These objects are verified using RPKI certs and CRLs, so there is a linkage. Does that answer your question? Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
At 11:05 AM -0400 5/3/11, Sam Hartman wrote: Let me make sure I'm understanding what you're saying. I can have multiple ROAs for the same set of prefixes in the repository and valid at the same time: one signed by a new certificate and one signed by a previous certificate? If so, I think I now begin to understand why the SIDR working group believes this is a reasonable strategy. yes, that is correct. This is an essential part of the alg transition mechanism. I guess the only question I'd have remaining is whether ROAs or other signed objects are intended to be used in other protocols besides simply living in the SIDR repository? The RPKI repository is designed to support a specific, narrow set of apps. That's what the CP says, and we try to make these certs unattractive for other apps, e.g., by use of the non-meaningful names. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
At 9:27 AM -0400 4/17/11, John C Klensin wrote: Steve, Two things: (1) Given the variable amount of time it takes to get RFCs issued/ published after IESG signoff, are you and the WG sure that you want to tie the phases of the phase-in procedure to RFC publication? It probably would help if the IESG coordinated with the RFC Editor to try to avoid having any problems here. But, we anticipate that the durations for the phases will be long enough so that a few months in the RFC editor's queue can be managed. (2) There is an incomplete sentence at the end of (2): "This allows CAs to issue certificates under" (more context below). john Whoops. The final sentence should be: This allows CAs to issue certificates under the new format before all relying parties are prepared to process that format. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
At 12:02 PM -0400 4/25/11, Sam Hartman wrote: ... However, when I look at section 2.1.4 in the signed-object document , the signer can only include one certificate. How does that work during phase 2 when some of the RPs support the new format and some only support the old format? Your text above suggests that RPs grab the certificates from the RPKI repository, but it seems at least for end entity certificates they are included in the signed object. What happens for end entity certificates during this form of upgrade? Sam, Yes, only one cert is associated with an RPKI signed object, and yes, this cert is embedded in the signed object format. So, when a new cert is issued, using a new format, the object itself is changed. Thus, the text describing Phase 2 is saying that there will be parallel instances of certs, CRLs, and signed objects in the RPKI repository system, associated with the old and new cert/CRL formats. I could add a sentence or two making this explicit, and referring the reader to the phased transition strategy used for algorithm transition in the RPKI, and described in draft-sidr-algorithm-agility. The reference would be informative, as this I-D is still in development and I don't want to hold up the progress of the rest of the SIDR docs. Let me know if this addresses your question. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
Sam, In response to your comments on the res-certs draft, re the restrictive nature of the relying party checks in certs, we have prepare the following text that will be included as a new section in the document. Steve - Operational Considerations This profile requires that relying parties reject certificates or CRLs that do not conform to the profile. (Through the remainder of this section the term "certificate" is used to refer to both certificates and CRLs.) This includes certificates that contain extensions that are prohibited, but which are otherwise valid as per RFC 5280. This means that any change in the profile (e.g., extensions, permitted attributes or optional fields, or field encodings) for certificates used in the RPKI will not be backward compatible. In a general PKI context this constraint probably would cause serious problems. In the RPKI, several factors minimize the difficulty of effecting changes of this sort. Note that the RPKI is unique in that every relying party (RP) requires access to every certificate and every CRL issued by the CAs in this system. An important update of the certificates and CRLs used in the RPKI must be supported by all CAs and RPs in the system, lest views of the RPKI data differ across RPs. Thus incremental changes require very careful coordination. It would not be appropriate to introduce a new extension, or authorize use of an extant, standard extension, for a security-relevant purpose on a piecemeal basis. One might imagine that the "critical" flag in X.509 certificate and CRL extensions could be used to ameliorate this problem. However, this solution is not comprehensive, and does not address the problem of adding a new, security-critical extension. (This is because such an extension needs to be supported universally, by all CAs and RPs.) Also, while some standard extensions can be marked either critical or non-critical, at the discretion of the issuer, not all have this property, i.e., some standard extensions are always non-critical. Moreover, there is no notion of criticality for attributes within a name or optional fields within a field or an extension. Thus the critical flag is not a solution to this problem. In typical PKI deployments there are few CAs and many RPs. However, in the RPKI, essentially every CA in the RPKI is also an RP. Thus the set of entities that will need to change in order to issue certificates under a new format is the same set of entities that will need to change to accept these new certificates. To the extent that this is literally true it says that CA/RP coordination for a change is tightly linked anyway. In reality there is an important exception to this general observation. Small ISPs and holders of provider-independent allocations are expected to use managed CA services, offered by RIRs/NIRs and by large ISPs. (All RIRs already offer managed CA services as part of their initial RPKI deployment.) This reduces the number of distinct CA implementations that are needed, and makes it easier to effect changes for certificate issuance. It seems very likely that these entities also will make use of RP software provided by their managed CA service provider, which reduces the number of distinct RP software implementations. Also note that many small ISPs (and holders of provider-independent allocations) employ default routes, and thus need not perform RP validation of RPKI data, eliminating these entities as RPs. Widely available PKI RP software does not cache large numbers of certificates and CRLs, an essential strategy for the RPKI. It does not process manifest or ROA data structures, essential elements of the RPKI repository system. Experience shows that such software deals poorly with revocation status data. Thus extant RP software is not adequate for the RPKI, although some open source tools (e.g., OpenSSL and cryptlib) can be used as building blocks for an RPKI RP implementation. Thus it is anticipated that RPs will make use of software designed specifically for the RPKI environment, and available from a limited number of open sources. Several RIRs and two companies are providing such software today. Thus it is feasible to coordinate change to this software among the small number of developers/maintainers. If the resource certificate format is changed in the future, e.g., by adding a new extension or changing the allowed set of name attributes or encoding of these attributes, the following procedure will be employed to effect deployment in the RPKI. The model is analogous to that described in [draft-ietf-sidr-algorithm-agility-00], but is simpler. A new document will be issued as an update to this RFC. The CP for the RPKI [ID-sidr-cp] will be updated to reference the new certificate profile. The new CP will define a new policy OID for certificates issued under the new certificate profile. The updated CP also will define a timeline for trans
Re: [TLS] Last Call: (Additionx
At 8:20 AM +0100 3/11/11, Nikos Mavrogiannopoulos wrote: ... > What Peter probably meant to say was that IPsec chose to truncate the HMAC value to 96 bits because that preserved IPv4 and IPv6 byte-alignment for the payload. Also, as others have noted, the hash function used here is part of an HMAC calculation, and any collisions have to be real-time exploitable to be of use to an attacker. Thus 96 buts was viewed as sufficient. This sounds pretty awkward decision because HMAC per record is full (e.g. 160-bits on SHA-1), but the MAC on the handshake message "signature" is truncated to 96-bits. Why wasn't the record MAC truncated as well? In any case saving few bytes per handshake is much less of value than saving few bytes per record. Was there any other rationale for truncation? I think you lost the context here. I was explaining why IPsec chose to truncate the hash, not TLS. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Secdir review of draft-ietf-sidr-res-certs
At 5:58 AM +0100 3/11/11, Martin Rex wrote: Stephen Kent wrote: n to act as CAs , and we want to limit their liability. One way to do this is to restrict the fields and extensions in resource certs to make then not very useful for other applications. A CA should never sign extensions that it doesn't understand. Why has the RP to be bothered with this? this is not about signing certs with extensions submitted by a Subject and which the CA does not understand. A request "everything must be considered critical, even if not marked as such" implies that every conceivable extension can only be a constraint. I would prefer to say that the vast majority of extensions are excluded from this profile, to make it easier for RP software to process resource certs. The critical marking is not equivalent to what we have stated in this doc, although there are similarities. For example, there are a lot of standard extensions that 5280 requires RP software to recognize that are explicitly forbidden in the RPKI context. With its original meaning, the "ciriticality" flag could be used to sort extensions into "constraints" (critical) and "capabilities" (non-critical). Note that not all extensions can be marked critical, so that using the critical flag would not be a solution in all cases anyway. The problem with newly inventend constraints is that they require flag days. capabilities do not suffer from this, and allow for a smoother migration. This doc is a profile of 5280 and thus the imposition of constraints is to be expected. I do not know what you mean by the phrase "... capabilities do not suffer from this ..." > I also note that we want to impose these constraints on both CAs and > RPs, because we have lots of examples of CAs issuing "bad" certs, accidentally. se want to use RP strictness to help "motivate" CAs to do the right thing :-). I don't think that this idea will work. The consumers of the technology will want things to interoperate, not to fail. And implementations will provide the necessary workarouds. Interoperability is NOT enhanced by allowing certs with extensions that are extraneous to the focus of this architecture, and to the CP for this PKI. I suggest you read the architecture doc and the CP, both of which are available at the SIDR page to get a better sense of the context targeted by this profile. Besides, such an idea is in conflict with rfc-2119 section 6 6. Guidance in the use of these Imperatives ... they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. I disagree with our reading of this text, relative to this context. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
Jeff Steve noted a desire to limit the liability of entities acting as CAs in the RPKI. I agree that goal is desirable, and restrictions on what certificates issued by those CAs can contain help to do that (provided the CAs actually comply). However, requiring compliant RPs to treat all extensions as critical does _not_ help, because an RP which incorrectly accepts an over-broad RPKI certificate for some other purpose is probably not an implementation of this profile and thus not bound by the restriction. My comments also noted that part of the strategy to limit the utility of resource certs in other contexts is to restrict their content. In principle, establishing constraints on what RPKI C As issue would do this, but experience suggests otherwise :-). Thus, in order to provide immediate feedback to a CA that the certs it is issuing are non-compliant, we would like to have RPs reject the certs (when used in the intended context). Thus having RPs be very strict in what they accept is important as well. Steve P.S. Sam noted that there are potentially lots of RPs. In principle, there are just as many CAs, since every ISP is a CA as well as an RP. In reality we anticipate that many small ISPs will take advantage of managed CA services (the RIRs are already offering such services), so there should be many fewer distinct CAs vs. RPs. Balancing that is the possibility that a number of ISPs, ones that rely on default routes, will also not be RPs. So, it's not clear whether we have more (distinct) CA or RPs. I am hopeful that the RIRs will do a good job of generating compliant certs in their primary and managed service CA roles. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity,
At 6:03 PM +0100 3/11/11, Martin Rex wrote: Phillip Hallam-Baker wrote: 1) WPA/WPA2 is not an end to end protocol by any stretch of imagination. It is link layer security. It is a 100% end-to-end security protocol. Because the IETF deals in Internet protocols (for the most part) e-t-e secruity usually is interpreted to mean a protocol that can traverse routers. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Secdir review of draft-ietf-sidr-res-certs
Sam, The cert profile is intentionally very restrictive, as you noted. A primary rationale is that we are asking folks who manage address (and AS#) allocation to act as CAs , and we want to limit their liability. One way to do this is to restrict the fields and extensions in resource certs to make then not very useful for other applications. we also wanted to make it as easy as possible for relying parties to process resource certs. X.509 has a lot of potentially complex "features" and RFC 5280 did not kill off as many as some of would have liked :-). So, profiling certs (and CRLs) for the RPKI makes sense. Allowing unknown, non-critical extensions would undermine this stragey. Much as I liked Jon Postel, and worked with him on the IAB for a decade, his oft cited dictum is bad design advice in the security arena. I also note that we want to impose these constraints on both CAs and RPs, because we have lots of examples of CAs issuing "bad" certs, accidentally. se want to use RP strictness to help "motivate" CAs to do the right thing :-). I must admit that I found it a bit amusing that you chose to illustrate the potential for a change that would motivate being less stringent by citing RFC 3779, which you noted didn't have the problem in question :-). (Also note that integers usually are not very much constrained in ASN.1 in general, so the observation you made there seems a bit odd to me.) Nonetheless, I get your point. My response is that IF we discover a need to change the profile, we could do so, e.g., by changing the cert policy (since the policy is specified in the CP, which references this version of the cert profile. Any change of this sort would have to be phased in over a long time scale. I suggest you look at the algorithm agility I-D for RPKI to see the sort of planning envisioned for that sort of change. I do agree that there is a typo in the doc, re the validity interval. Sean noted that after the doc was released, and we agreed that it can be fixed after last call. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: (Additionx
At 5:08 PM -0800 3/8/11, Eric Rescorla wrote: On Tue, Mar 8, 2011 at 3:55 PM, Peter Gutmann wrote: Martin Rex writes: Truncating HMACs and PRFs may have become first popular in the IETF within IPSEC. It wasn't any "may have become first popular", there was only room for 96 bits of MAC data in the IP packet, so MD5 was truncated to that size. This is an odd claim, since: (a) RFC 1828 (http://tools.ietf.org/html/rfc1828) originally specified not HMAC but a keyed MD5 variant with a 128-bit output. (b) The document that Martin points to has MACs > 96 bits long. Can you please point to where in IP there is a limit that requires a MAC no greater than 96 bits. -Ekr What Peter probably meant to say was that IPsec chose to truncate the HMAC value to 96 bits because that preserved IPv4 and IPv6 byte-alignment for the payload. Also, as others have noted, the hash function used here is part of an HMAC calculation, and any collisions have to be real-time exploitable to be of use to an attacker. Thus 96 buts was viewed as sufficient. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NAT behavior for IP ID field
... Curious; RFC2402 says " Flags -- This field is excluded since an intermediate router might set the DF bit, even if the source did not select it." which is a licence to set the bit but I had not thought to reset the bit. RFC791, RFC1122 and RFC1812 would appear to be silent on this. I'm curious abut RFC 2402, then. Firstly, the host might not implement PMTUD, and hence setting the DF bit on its behalf could possibly cause interoperability problems. Secondly, some hosts clear the DF bit if the advertised MTU in an ICMP "frag needed" is below some specified threshols. This RFC2402-behavior could cause problems in this scenario, too. We made the decision ton exclude the DF bit from the ICV computation in 2402, based on what we believed was happening in the net, irrespective of what should have been happening ;-). We retained this behavior in RFC 4202, for the same reason. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-ietf-csi-send-cert-03
At 1:47 AM -0400 6/2/10, Suresh Krishnan wrote: ... Hmm. The ETA certificate itself does not need to have the RFC3779 extension in it, but the relying party needs to fetch an RTA certificate which will contain a RFC3779 extension. more precisely the ETA MUST NOT have such an extension. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: On the IAB technical advice on the RPKI
At 2:17 PM -0400 3/18/10, Phillip Hallam-Baker wrote: Before declaring victory, lets see if anyone actually uses it to validate any data. fair enough. anything else is speculation by both of us, so lets table the discussion for a year or so. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: On the IAB technical advice on the RPKI
At 9:15 PM -0500 3/13/10, Phillip Hallam-Baker wrote: So what has me annoyed about the IAB advice is that they gave advice about a particular means where they should have instead specified a requirement. Phil, I am not commenting on your proposal, but I do want to make a few observations that are relevant to this discussion. I believe that the point the IAB was making is that if each RIR acts as a TA, any one of them could make an error (or suffer a compromise) that would allow for conflicting certs to be issued below the affected RIR. The certs used for the RPKI include RFC 3779 extensions. If IANA acts as the only TA, then it will issue certs to the RIRs representing their allocations from IANA. Unless IANA makes an error in this cert issuance procedure (which should be aligned with its allocation of address space to the RIRs), then there can be no (undetected) conflicts among the RIRs re resource holdings. Also recall that IANA needs to act as a TA anyway, for unallocated, legacy, and reserved address space. So the choice the IAB was addressing was one TA vs. six. You commented that using X.509 certs in this context requires "completely new path validation semantics." The semantics are well-defined in RFC 3779, which was issued in June 2004. I also observe that OpenSSL already supports cert path validation using 3779 extensions, and has done so for at least a couple of years. Note also that the RPs here are primarily ISPs. They will use software that yields outputs consistent with their goals of origin AS validation. Based on the SIDR WG activities, this means validating ROAs, using EE resource certs (which contain 3779 extensions). This is not a context where browsers or other commodity cert processing software will be used. I know of at least two independently-developed, open source implementations of RP software that deal validate ROAs using resource certs. There may be 1 or 2 more implementations in process. Four of the five RIRs have working CA software that issues resource certs, and several of them have adopted the offline/online CA model to which you refer. So concerns about the difficulty of using X.509 certs here seem unfounded. Given these observations, the public declaration last year by the NRO that all 5 RIRs will offer RPKI service as of 1/1/11, and the ongoing SIDR WG efforts, most of this discussion seems OBE at this stage. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
At 8:50 AM -0800 2/12/10, David Conrad wrote: On Feb 12, 2010, at 7:57 AM, Stephen Kent wrote: Who gets to decide on what algorithms get first class status and based on what criteria? If we look at what the CP developed in the SIDR WG for the RPKI says, the answer is the IESG So, they're going to flip a coin or what? "Who" is largely irrelevant. The criteria is the interesting bit. Both issues are relevant. Most of the other WGs dealing with this issue have been in the secruity area and feel comfortable making these decisions. The IESG has been comfortable with their decisions. Note that change have been made, for other than technical reasons, e.g., initially TLS had DH 7 DSA as MUST and RSA as SHOULD, because of patent issues. When the RSA patent expired, the roles were reversed. So the IESG has been an active participant in these decisions in the past. >> Steve brought up "national" algorithm, but we have also "personal" algorithms such as curve25519 or threefish. WGs like IPsec, TLS, and SMIME have been able to say no to "personal" algs for a long time. IPsec, TLS, and SMIME are all one-to-one. DNSSEC (in this context) is one-to-many. Your observation is applicable to IPsec, not to S/MIME, and, for practical purposes, not for TLS. An S/MIME message may be sent to multiple recipients, so it is not literally one-to-one. S/MIME accommodates algorithm diversity best for the public key algorithms used to encrypt the content encryption key. It also can accommodate diversity for the algorithm used to sign the message, but at a higher cost. It does poorly if different recipients make use of different content encryption algorithms. TLS is nominally 1-1, but in reality, the vast majority of TLS use is for access to web sites that have a very diverse set of clients. That requires a small set of mandatory algorithms, to ensure interoperability. Finally, the question posed was about how have decisions on which algorithms are mandatory to implement have been decided in the IETF in the past. My reply addressed that question. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
At 2:18 PM -0500 2/12/10, Edward Lewis wrote: At 10:57 -0500 2/12/10, Stephen Kent wrote: If we look at what the CP developed in the SIDR WG for the RPKI says, the answer is the IESG (going forward, after an initial set of algs are adopted based on the SIDR WG process). In the IPSEC, TLS, and SMIME contexts, the WGs themselves have made the decisions, which the IESG then approves by virtue of the usual standards track RFC approval process. I do not believe that the criteria have been documented uniformly across these WGs. What is "CP?" Sorry for the acronym ambiguity. the CP is the certificate policy (for the RPKI). Every major PKI has a CP. These documents follow the outline provided in RFC 3647. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
... As a document shepeard I have made note that this is desired, but at the same time this is a topic that was outside the scope of the working group. This is on the other hand a topic that belongs in the IETF review. So my questions to the IETF (paraphrashing George Orwell) "Are all crypto algorithms equal, but some are more equal than others?" not all are equal, from a purely cryptanalytic perspective. Among those that may be equivalent from that perspective, there are other meaningful differences, e.g., how widely are the algs implemented and used. Who gets to decide on what algorithms get first class status and based on what criteria? If we look at what the CP developed in the SIDR WG for the RPKI says, the answer is the IESG (going forward, after an initial set of algs are adopted based on the SIDR WG process). In the IPSEC, TLS, and SMIME contexts, the WGs themselves have made the decisions, which the IESG then approves by virtue of the usual standards track RFC approval process. I do not believe that the criteria have been documented uniformly across these WGs. Steve brought up "national" algorithm, but we have also "personal" algorithms such as curve25519 or threefish. WGs like IPsec, TLS, and SMIME have been able to say no to "personal" algs for a long time. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-ietf-dnsext-dnssec-gost
I recommend that the document not be approved by the IESG in its current form. Section 6.1 states: 6.1. Support for GOST signatures DNSSEC aware implementations SHOULD be able to support RRSIG and DNSKEY resource records created with the GOST algorithms as defined in this document. There has been considerable discussion on the security area directorate list about this aspect of the document. All of the SECDIR members who participated in the discussion argued that the text in 6.1 needs to be changed to MAY from SHOULD. The general principle cited in the discussion has been that "national" crypto algorithms like GOST ought not be cited as MUST or SHOULD in standards like DNESEC. I refer interested individuals to the SECDIR archive for details of the discussion. (http://www.ietf.org/mail-archive/web/secdir/current/maillist.html) Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt
At 1:11 AM -0700 10/13/09, SM wrote: Hi Steve, At 12:18 12-10-2009, Stephen Kent wrote: When the site closed, do you believe that all of the material published there will become inaccessible, not archived anywhere? I doubt that. I am not sure whether all the material will be available at archive.org or other archiving sites. If the material is archived on one site only, there's a risk of "too big to fail". I can change the material I publish. That's not always good if the material is to be used as a reference (immutability). It took me some time to understand that sometimes we need access to an old version of a specification, and not the latest one, even if that version contains mistakes. T I agree with your observations, but I don't think that the RFC series is the only way to achieve the characteristics you cite. hat's part of the intrinsic qualities I mentioned in my earlier message. The status quo does not mandate that the RFC Editor and the IESG agree; it allows the RFC Editor to make a unilateral decision to ignore an IESG note. So, I don't agree with the second part of your statement above. I do agree that the change diminishes the independence of the RFC Editor. You are trying to persuade me to change my stance while I am trying to persuade you to change yours. It is in essence a dialogue. If one of us is the authority which makes the decision, that person can make an unilateral decision and ignore the other person's opinion. By invoking that authority, the person causes a break down of the dialogue. When two parties are bound to work together on a regular basis, that can result in an uncomfortable situation. Now, if we have to add an appeal (it's not being made in an individual capacity) to that, we can end up with a larger issue instead of a difference of perspectives between an individual and a body. Good points. My view is that a shift in the balance of power is appropriate, and that an appeal process can increase confidence that the IESG will not abuse its power (if granted). But, that is not a guarantee. Not sure about your last sentence above, since the RFC Editor is no longer an individual, but a function effected by a set of individuals. At least the IESG, another set of individuals, least appointed through in open process, unlike the RFC Editor. Let's step away from the draft being discussed for a few minutes and ponder on whether either of us is being unreasonable. Now, if we cannot figure out the answer, let's ask (figuratively) someone else for advice. We have the choice of accepting the advice even though we are right or seeking an advice that will suite us. Of course you and I are reasonable people :-). Not sure how the rest of the paragraph above fits into our discussion though. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt
At 10:29 AM -0700 10/9/09, SM wrote: ... Section 1.1 of the draft mentions that: "The IESG may provide an IESG note to an Independent Submission or IRTF Stream document to explain the specific relationship, if any, to IETF work." That's a "may". From what you said, I deduce that you would prefer that line to say: The IESG will provide an IESG note to an Independent Submission ... The reasons for the IESG Note are mentioned in Section 3. None of them are about a label saying that the RFC is not a product of a WG. I think may is the right term here. But, if the IESG chooses to assert this prerogative, I would like to see the note inserted, without the need for RFC Editor concurrence. When the RFC series was first established, the need for archival, searchable, open publication of Internet-related documents was a good argument for the autonomy of the RFC Editor function. Moreover, the RFC Editor function pre-dates the existence of the IETF and the IESG, by many years. But, times change. The availability of search engines like Google make it possible for essentially anyone to publish material that is widely accessible, relatively easy to find, and more or less archival. Also, the vast majority of the RFCs published for many years are documents approved by the IESG. Thus it seems reasonable to revisit the degree of autonomy the RFC Editor enjoys relative to the IESG. The current proposal does not change the relationship very much in practice, but I understand that it is an important issue in principle, and the IETF membership has debated it in this context, extensively. An open source advocate once suggested to me that I could use Geocities to publish material. That site is closing this month. There are differences between publishing something on your web site and publishing a RFC. The latter does not require search engine optimization for wide dissemination. A RFC has intrinsic qualities because of the way it is produced. There are some RFCs with IESG notes, such as RFC 4144, which I read as good advice. When the site closed, do you believe that all of the material published there will become inaccessible, not archived anywhere? I doubt that. The current proposal undermines the independence of the RFC Editor (ISE in practice). It changes the relationship from one where the various parties should work together and come to an agreement to a tussle between the RFC Editor and the IESG. I don't think that an appeal is a good idea. I didn't object to it as the IESG folks may feel better if they had that mechanism. However, I do object to making the outcome mandatory. The status quo does not mandate that the RFC Editor and the IESG agree; it allows the RFC Editor to make a unilateral decision to ignore an IESG note. So, I don't agree with the second part of your statement above. I do agree that the change diminishes the independence of the RFC Editor. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt
Dave, I'd like to address some of the points you made in your message to Russ re 3932bis: ... The first assumption is that there is a real problem to solve here. Given 40 years of RFC publication, without any mandate that the RFC Editor must include a note from the IESG, and without any critical problems resulting, we have yet to see any real case made for changing the current rule, which makes inclusion of an IESG note optional. As ads for financial products remind us "Past performance is not a guarantee of future performance." Since we have been making changes in IETF functions over time, including the RFC Editor function, I don't think it is unreasonable to formalize this aspect of the relationship between the IESG and the RFC Editor, before a problem arises. The second assumption is that an IESG note is sometimes, somehow essential. I believe you will be very hard-pressed to make an empirical case for that assumption, and the problem with trying to make only a logical case is that a competing logical case is always available. In other words, in 40 years of RFCs, the damage that was caused by not having a note added by an authority that is separate from the author, or the damage that was prevented by adding one, is almost certainly absent. That does not make it a bad thing to add notes, but it makes the case for /mandating/ such notes pretty flimsy. I believe that most folks recognize that the public, in general, does not distinguish between RFCs that are the product of IETF WGs, individual submissions, independent submissions, etc. I think the IESG has a legitimate role in ensuring that RFCs that are not the product of WGs are appropriate labelled, and inclusion of an IESG note is a reasonable way to do that. When the RFC series was first established, the need for archival, searchable, open publication of Internet-related documents was a good argument for the autonomy of the RFC Editor function. Moreover, the RFC Editor function pre-dates the existence of the IETF and the IESG, by many years. But, times change. The availability of search engines like Google make it possible for essentially anyone to publish material that is widely accessible, relatively easy to find, and more or less archival. Also, the vast majority of the RFCs published for many years are documents approved by the IESG. Thus it seems reasonable to revisit the degree of autonomy the RFC Editor enjoys relative to the IESG. The current proposal does not change the relationship very much in practice, but I understand that it is an important issue in principle, and the IETF membership has debated it in this context, extensively. The third assumption is that the real locus of control, here, needs to be the IESG. Even though you are now promoting an appeal path, it's a fallback position that derives from the assumption that the IESG should be the ultimate arbiter of all quality assessment, not just for IETF RFCs but for all RFCs. For independent submissions, this distorts the original model, which is that the IESG is merely to be consulted for conflicting efforts, not general-purpose commentary on the efficacy or dangers of an independent document. Really, Russ, it's OK for some things to proceed without having the IESG act as a gatekeeper. My comment above addresses this issue as well. The fourth assumption is that an added layer of mechanism, in the form of an appeal path, is worth the cost. An honest consideration of those costs has been absent, yet they are significant. I think the biggest cost of an appeal mechanism is incurred when appeals arise, although there are costs associated with defining the mechanism. Since you argued above that we ought not expend a lot of effort to deal with problems that have not arisen, maybe we ought not worry about the costs of appeals that have not yet arisen :-). The fifth assumption is the odd view that Jari put forward, namely that creating an appeal path somehow "retains the independence of the editor". In other words, impose a mechanism designed to reverse decisions by the editor, but say that the editor retains independence. Confusing, no? I agree that the quote cited above is not a good way to characterize the value of an appeals process. Perhaps a better way to state the value of the appeal process is to say that it provides a way for the Editor to address a situation when it believe that the IESG has insisted on inserting an inappropriate note. I support 3932bis, with the appeal provision. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Joel, I agree that IESG notes should be rare, but primarily because independent stream submissions should be rare :-). Long ago, when I served on the IAB, we grappled with this problem, and failed to find a good solution. Despite what we say about RFC status and origin markings, the public sees RFCs as carrying the imprimatur of the IETF (not just that of the RFC Editor). When Jon Postel was the RFC editor, we were pretty comfortable with his judgement on these matters, this was less of an issue. However, time have changed and I would be happy to see inclusion of an IESG note be mandatory, contrary to historical practice. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard
At 10:05 AM -0400 8/5/09, Dean Anderson wrote: Ned and Stephen, If you mean the recent message traffic about the 'intention to remove' extractor from a list of patented documents, that hasn't happened so far and an 'intention to remove' doesn't mean it isn't patented. It is possible that Certicom can later say it was a misunderstanding and that the official documents were correct. As evidence of their view, they have the official documents. As evidence of your view, you have an unofficial and vague email message apparently contrary to the official documents, and you will have to argue you based your decision on the unofficial and vague message rather than the official IPR Disclosures. I think one cannot get to a Qualcomm v. Broadcomm finding under such circumstances. I reiterate my support for the cited I-D. period. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard
I too support publication of this document as a Standards Track RFC, in light of the salient message traffic of late. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
At 10:32 PM -0400 6/11/09, David Conrad wrote: Hi, On Jun 11, 2009, at 8:35 PM, Stephen Kent wrote: But, in a DNSSEC environment, IANA performs two roles: - it coordinates the info from the gTLDs and ccTLDs and constructs the authoritative root zone file - it signs the records of that file Nope. Just to clarify things: IANA (well, ICANN as the IANA functions operator) receives and validates root zone changes. VeriSign constructs and publishes the root zone to the root server operators. In the context of DNSSEC, as documented at http://www.icann.org/en/announcements/announcement-2-03jun09-en.htm, VeriSign will have operational responsibility for the zone signing key and ICANN will manage the key signing process. David, Thanks for the clarification. I just wanted to emphasize the two distinct functions that IANA performs in the DNSSEC context, without getting into the ZSK/KSK details and the current proposed split of responsibility between IANA and VeriSign (which is outside the IETF DNSSEC architecture, right?). Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Phil, The examples you give about backed-in trust anchors are valid, but they point to decisions by vendors to simplify their designs at the cost of secruity and functionality. I've been told that it is very hard, if not impossible, to permanently remove some vendor-supplied TAs in a popular browser. These are not fundamental results of architectural decisions of the sort the IETF makes, but vendor choices that lead to possible problems for user. I think I understand the multi-party, RP-centric threshold approach to managing the DNSSEC root that you outlined. But, in a DNSSEC environment, IANA performs two roles: - it coordinates the info from the gTLDs and ccTLDs and constructs the authoritative root zone file - it signs the records of that file Any scheme that allows multiple entities to "confirm" the content of the root zone file also has to include a means for these entities to independently acquire and verify the master file data and to create a separate, distinct master file if they disagree. This is a lot more complex that what you outlined in your message (from an from an administrative vs. crypto perspective). It also raises questions about how complex RP software has to be in dealing with multiple sets of quasi-authoritative root authorities. All experience to date suggests that RPs fare poorly when trying to deal with much less complex trust anchor situations in other PKI environments today. It is conceivable (under the new administration) that ICANN will stop being under the control of the U.S DoC, but it also is not clear that such a change would ameliorate the concerns of all governments with regard to this issue. I think the set of folks who feel a need to use other than the current, proposed model (IANA as the DNSSEC root) are a very small minority of the set of public Internet users and thus they should bear the burden of dealing with the resulting costs and complexity for managing alternative root schemes. I don't think that such costs and complexity should be borne by the vast majority of Internet users. Its also not clear how long one might spend debating the question of whether any single scheme would satisfy all of the players who are not comfortable with the current model. Steve___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
Joe, Having served on NOMCOM more than once, and having been solicited for inputs every year, I much prefer publishing the names of folks have consented to be considered for IAB and IESG positions. The addition of "ringers" to lists that are sent out (to hide the identities of the true candidates) wastes the time of a lot of folks who are asked to provide feedback on these non-candidates. It also means that someone who is a real candidate may not receive feedback because people assume the individual is a ringer! Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publicizing IETF nominee lists [Fwd: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP]
At 10:51 AM +0200 6/11/09, Lars Eggert wrote: Content-Type: multipart/signed; boundary=Apple-Mail-5-115115602; micalg=sha1; protocol="application/pkcs7-signature" I agree with Sam and Jari. This is a good and overdue change. Lars I also agree with this proposal, based on several experiences serving on NOMCOM. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
At 10:41 AM +1000 6/11/09, Mark Andrews wrote: In message , Stephen Kent writes: Joe, You have argued that DNSSEC is not viable because it requires that everyone adopt IANA as the common root. Which isn't even a requirement. Alternate root providers just need to get copy of the root zone with DS records and sign it with their own DNSKEY records for the root. ISP's that choose to use alternate roots might get complaints however from their customers if they are validating the answers using the trust-anchors provided by IANA. This however should be seen as a good thing as the ISP can no longer tamper with the DNS without being detected. If a ISP can convince all their customers that the alternate roots are a good thing then this won't become a issue. Fair point, although I think we all want to avoid the sort of Balkionization that this suggests. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's move on - Let's DNSCurve Re: DNSSEC is NOT secure end to end
Joe, You have argued that DNSSEC is not viable because it requires that everyone adopt IANA as the common root. I agree that under the current IANA management situation many folks may be uncomfortable with IANA as the root. However, in practice, the world has lived with IANA as the root for the non-secure version of DNS for a long time, so it's not clear that a singly-rooted DNSSEC is not viable based on this one concern. Moreover, DNSSEC is a form of PKI, an din ANY PKI, it is up to the relying parties to select the trust anchors they recognize. In a hierarchic system like DNS, the easiest approach is to adopt a single TA, the DNS root. But, it is still possible for a relying party to do more work and select multiple points as TAs. I would expect military organizations in various parts of the world to adopt a locally-managed TA store model for DNSSEC, to address this concern. However the vast majority of Internet users probably are best served by the single TA model. As for DNSCurve, I agree with the comments that several others have made, i.e., it doe snot provide the fundamental security one wants in DNS, i.e., an ability to verify the integrity and authenticity of records as attested to by authoritative domains, din the face of caching. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments requested on recent appeal to the IESG
At 7:06 PM -0800 2/20/09, Dave CROCKER wrote: Stephen Kent wrote: At 9:00 PM -0800 2/19/09, Hallam-Baker, Phillip wrote: Just as a matter of observation, ... ... I have not read the doc in question,... Hey guys. As someone who is frequently faced with trying to parse out what are and are not the commonly held views among the security community, I'm actually interested in this type of exchange. But as you both note, this exchange isn't critical to resolution of the the appeal. For those of who want to see this appeal dispatched as quickly and as painlessly as possible, is there a chance that you can continue the exchange under a different guise, at a minimum under an entirely independent thread? d/ Dave, My belief is that IF the doc conflates authentication and authorization, then some intelligent editing probably can fix that problem quickly. Since, as you and other have noted, the WG is n board with this doc, the issue Phil raised, and to which I responded, ought not affect approval of the document. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Comments requested on recent appeal to the IESG
At 9:00 PM -0800 2/19/09, Hallam-Baker, Phillip wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="_=_NextPart_001_01C99318.3582B8D8" Just as a matter of observation, there is not and never has been a security requirement to rigidly separate authentication and authorization. Indeed there is no real world deployment in which authentication and authorization are not conflated to some degree. Authentication and authorization (aka access control) are distinct security services. Too often they are confused, and the result of such confusion is never a great outcome. I have not read the doc in question, but your dismissal of this issue is not persuasive. The separation of authentication and authorization is a matter of administrative and operational convenience. nonsense. the two are implemented via a wide range of mechanisms, many of which are independent of one another. I may use passwords or challenge-response mechanisms or PKI technology for authentication, and use various identity-based authorization mechanisms with any of these means of verifying an identity. Thus there are good technical and design reasons to consider the services and mechanisms separately, as part of a modular design approach. It is very rarely the case that every privilege that might potentially be granted to a user is known in advance. Hence the benefit of maintaining a distinction. But in practice the fact that a party holds a valid authentication credential is in itself often (but not always) sufficient to make an authorization decision in low-risk situations. True, but the fact that you had to employ several qualifiers in these sentences to make them true illustrates the benefits of distinguishing between the terms. Thus an objection based on the mere risk that such a conflation may occur is not justified as such conflation has occured in every practical security system ever. I don't know if the objection is an important one here, but I do think it is important in general. We do not issue employee authentication badges to non-employees. Thus an employee-authentication badge will inevitably carry de-facto authorization for any action that is permitted to every employee (like open the office door). A good example to make my point. It is typically the case that if all employees have ID badges, these badges grant access to most buildings/rooms of the employer's facilities. But many other rooms of an employer's facilities typically are off limits to all but a few employees. The Authorization/Authentication model is in fact broken, in a modern system such as SAML you actually have three classes of data with the introduction of attributes. SAML allows one to make security assertions of all sorts. The fact that one can make both authentication and authorization assertions using the same construct is distinct from the question of whether conflating the two terms is a good idea in general, as you seem to be arguing. Steve___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: how to contact the IETF
Alex, The conclusion I draw from this experience differs from yours. If the individuals who sent the messages in question choose to become involved constructively, then there can be some benefit. But, the act of sending the messages in question has generated ill will, so it was a bad way to begin a constructive, contributory process. Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: RNET: Random Network Endpoint Technology
Chad, Your message of 4/8 ended with a list of changes needed to IPv6 implementations to implement RNET. Changes to processing logic are just as serious as change to the format. Steve --- The following changes need be made to the IP Version 6 Protocol Logic, in routers, in order to impliment this technology: 1) encryption routines 2) recognization of RNET Route Requests 3) generation and recognization of RNET errors 4) routing table modifications NB: the RNET Host address may be stored in the host address of the route entry. The Target Host address may be stored in the Netmask of the route entry. The Gateway address may be stored in the gateway of route entry. The Route Decay may be stored in the Metric or be implimented through some system timer. 5) routines to acquire keys from the RNET Centralized Server 6) storage of the IP address of the RNET Centralized Server 7) storage of the router's unique key 8) storage of the RNET Global Key 9) an additional flag for route entries marking them as RNET Route entries The following changes need be made to the IP Version 6 Protocol Logic, in hosts, in order to impliment this technology: 1) encryption routines 2) generation of RNET Route requests 3) recognization of RNET errors 4) routines to acquire keys from the RNET Centralized Server 5) storage of the IP address of the RNET Centralized Server 6) storage of the host's unique key 7) storage of the RNET Global Key 8) an additional flag in the IP Stack to identify the assigned host address as being an RNET Host address so that the IP Stack is aware of the protocol to follow in initiating connections. This allows differentiation from RNET Host addressess and regular IPs___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Thoughts on the nomcom process
Mike, I have to disagree with your characterization of the proper role of the IAB with regard to the NOMCOM process. I have been on three NOMCOMs, including the one prior to this, so I too have some experience in the process. My feeling is that the IAB may have been trying to assert too much authority in the process recently. That certainly was my perception with the previous NOMCOM, and the report about this year's activities suggests that the problem continues. RFC 3777 is ambiguous wrt some details of the process, especially the IAB's purview re confirming IESG candidates selected by the NOMCOM. One could read 3777 so as to allow the IAB to effectively supplant the NOMCOM, e.g., by refusing to approve a slate of candidates until one candidate, acceptable to the IAB, is named for a given position. This is clearly not what 3777 intends, as undermines the NOMCOM role, yet I have seen behavior that comes close to this. I think the preferred way forward is to clarify 3777 to make clear that the IAB must not engage in actions that are tantamount to usurping the rile of the NOMCOM. As for the IAB publication you cited in your message, I don't recall seeing the RFC number for it. If it was just an informational RFC, I don't believe that has standing relative to 3777, which is the result of the usual IETF process. The IAB is not empowered to write an interpretation of an RFC to expand the IAB's role unilaterally. Steve___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt
At 2:06 PM -0600 1/14/08, Nicolas Williams wrote: ... Ipsec does support ^ You're slipping :) :) oh my! > per-user authentication if protocol ID and port pairs can be used to distinguish the sessions for different users. I thought this was feasible (see above) but I thought the RFC4301 model didn't quite deal with this (or at least Sam once convinced me that the name selector of the SPD didn't quite work the way I would think it should). I am glad to be wrong on this. (So then, the name selector in the SPD can be used to select the local ID and credentials?) The following text from pages 28-29 of 4301 seems pretty clear on this point. I have marked some of the text as bold, to call attention to especially relevant parts. - Name: This is not a selector like the others above. It is not acquired from a packet. A name may be used as a symbolic identifier for an IPsec Local or Remote address. Named SPD entries are used in two ways: 1. A named SPD entry is used by a responder (not an initiator) in support of access control when an IP address would not be appropriate for the Remote IP address selector, e.g., for "road warriors". The name used to match this field is communicated during the IKE negotiation in the ID payload. In this context, the initiator's Source IP address (inner IP header in tunnel mode) is bound to the Remote IP address in the SAD entry created by the IKE negotiation. This address overrides the Remote IP address value in the SPD, when the SPD entry is selected in this fashion. All IPsec implementations MUST support this use of names. 2. A named SPD entry may be used by an initiator to identify a user for whom an IPsec SA will be created (or for whom traffic may be bypassed). The initiator's IP source address (from inner IP header in tunnel mode) is used to replace the following if and when they are created: - local address in the SPD cache entry - local address in the outbound SAD entry - remote address in the inbound SAD entry Support for this use is optional for multi-user, native host implementations and not applicable to other implementations. Note that this name is used only locally; it is not communicated by the key management protocol. Also, name forms other than those used for case 1 above (responder) are applicable in the initiator context (see below). So, although support for this capability (for initiators) is not strictly required for a multi-user system, we do explain how it is intended to work in those systems. So, if you want to restrict the cited motivation to applications that multiplex different users onto a single TCP/UDP session, that would be accurate. I don't want to restrict it only to such applications, _no_. Then you should include the sort of text you provided below, to justify why BTNS is appropriate in these circumstances, since it is not accurate to say that IPsec cannot provide the required support. ... I think the examples that you object to can remain in the I-D, but it should be clear that BTNS is not 'RECOMMENDED' (nor 'NOT RECOMMENDED') for those -- that those examples are speculative. Provided that such examples are feasible. my only requirement is that the motivation text be factually accurate. Steve___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [anonsec] review comments on draft-ietf-btns-prob-and-applic-06.txt
At 6:00 PM -0600 1/11/08, Nicolas Williams wrote: ... Finally, multi-user systems may need to authenticate individual users to other entities, in which case IPsec is inapplicable[*]. (I cannot find a mention of this in the I-D, not after a quick skim.) [*] At least to my reading of RFC4301, though I see no reason why a system couldn't negotiate narrow SAs, each with different local IDs and credentials, with other peers. But that wouldn't help applications that multiplex messages for many users' onto one TCP connection (e.g., NFS), in which case even if my readinf of RFC4301 is wrong IPsec is still not applicable for authentication. IPsec has always allowed two peers to negotiate multiple SAs between them, e.g., on a per-TCP connection basis. Ipsec does support per-user authentication if protocol ID and port pairs can be used to distinguish the sessions for different users. So, if you want to restrict the cited motivation to applications that multiplex different users onto a single TCP/UDP session, that would be accurate. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
review comments on draft-ietf-btns-prob-and-applic-06.txt
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is not well structured, i.e., in many places it rambles. The document has more of an architectural framework feel to it than the title suggests. It spends too much time saying how BTNS will work, rather than focusing on the nominal topic of the document, i.e., the problem to be solved and the anticipated applicability of the solution. It never provides a clear, concise characterization of the problem to be solved, and why the functionality offered by BTNS-IPsec is the preferred way to solve the problem. (I believe this problem arises because, from the beginning, there were been multiple, independent motivations for the BTNS work and the WG never reconciled them.) There seem to be two types of problems/solutions that motivate BTNS, both starting with the assumption that use of IPsec is the goal (an assumption that needs to be justified itself, as noted below). The solutions are presented before examples of the problems, which does not help matters, but I'll characterize the problems in terms of the solutions, in keeping with the style of the I-D: - creating IPsec/IKE SAs w/o authentication, for use in contexts where it is perceived that IPsec is not used because the effort to deploy an authentication infrastructure compatible with IKE is too great a burden AND the confidentiality and integrity offered by unauthenticated SAs is "better than nothing." Since IKE supports use of passwords, this presumes that the threshold for what constitutes too great a burden is pretty low, but this is not explicitly stated. Also, the BGP use case was disputed, when this work started, and has proven to be a bad example given continuing developments, but it persists in the document. There is also a not-well-articulated argument that TLS/DTLS is not a suitable alternative, presumably because those protocols do not protect the transport protocol per se. It's true that IPsec does a better job here, but the need for using it (vs. TLS) in such circumstances does not seem to be widely accepted. - creating IPsec/IKE SAs w/o authentication, for use in contexts where an application will perform its own authentication, but wants the layer 3 confidentiality, integrity and continuity of authentication offered by ESP. Here a critical part of the argument is that these applications cannot use the authentication provided by IKE, but the explanation for this is poor. For example there is no recognition of the use of EAP authentication methods with IKE. The text also does not address the possibility that a suitable API could allow an application to acquire and track the ID asserted during an IKE exchange, in lieu of the unauthenticated SA approach that is being motivated. The document fails to introduce important concepts like continuity of authentication and channel binding near the beginning. If leap of faith authentication is important enough to be included, then it too needs to be described early in the document. The document never provides a clear, concise definition of channel binding, and the definition of LoF is mostly by example. The failure to define these terms early in the document leads to ambiguity and confusion in the problem statement sections. Several of the examples provided in the applicability section do not seem congruent with security efforts in the relevant areas. I mentioned the BGP connection example above, which is even less relevant today, given the ongoing TCPM work on TCP-AO. There is also an assertion that BTNS-IPsec is a good way to protect VoIP media, yet the RTP folks never believed that and the RAI area has recently reaffirmed its commitment to use of SRTP for this purpose, with DTLS for key management. Another questionable example is the suggestion to use both BTNS-IPsec and TLS to protect client/server connections against TCP RST attacks. This is theoretically a valid use of BTNS-IPsec, but there is no indication that web server operators believe this is a "necessary" capability, as the I-D argues. The security considerations section is too long, mostly because much of the material should be earlier, e.g., the CB discussion. One might also move the rekeying attack example (which I expanded to be more accurate) to the CB document, and just reference the notion here. I am unable to attach a copy of the I-D, with MS Word charge tracking for detailed comments and edits, because it is too big for these lists. A copy of that file was sent to tge cognizant Security AD, WG chairs, and authors. Steve ___
Re: Last Call: draft-shimaoka-multidomain-pki-11.txt
At 7:34 PM +0100 12/4/07, Martin Rex wrote: The document - 'Memorandum for multi-domain Public Key Infrastructure Interoperability' > as an Informational RFC creates the impression that "trust anchors" must always be self-signed CA certificates. What is a trust anchor MUST remain completely up to local policy (which might be a client-local policy in some scenarios), there should be NO restriction whatsoever what can be configured as a trust anchor. The idea of a trust anchor is that we trust the (public) key of the trust anchor, that the PKI implementation may perform a reduced (certificate) path validation only up to the trust anchor. The management of trust anchors is also completely a local (policy) issue, i.e. what keys are considered trust anchors, how they are distributed, managed and updated. I am violently opposed to the documents requirements and restrictions what may an what may not be a trust anchor certificate. Document published by the IETF (even if just Informational) should neither make unconditional restrictions (MUST NOT) nor unconditional requirements (MUST) for the selection of trust anchors. Instead, Protocols and implementations SHOULD support the use of arbitrary trust anchors as desired by local policy. -Martin Martin, You are right that a TA need not be a self-signed cert, although this is the most common format for TA representation. Your statement about how a TA allows a relying party to "perform a reduced (certificate) path validation" is confusing. I believe that we always assume that cert path validation terminates at a TA for the RP. We both agree that the selection and management of TAs is purely a local matter for each RP. In general I do not worry too much about what an informational RFC that is not the product of a working group says. However, looking at the abstract for this document I do see some words that cause me some concern, i.e., "The objective of this document is to establish a standard terminology for interoperability of multi-domain Public Key Infrastructure (PKI), where each PKI Domain is operated under a distinct policy ..." We ought not make such strong statements in a document of this sort. I agree that the authors need to soften the wording to indicate that this document defines terminology to describe multi-domain PKI models, as an aid to discussing issues in these contexts. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-pkix-rfc3280bis (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) to Proposed Standard
Sam Hartman identified an issue with one name type (URI) that may appear in the Subject/Issuer alternative names, when applying the Name Constrains extension to such names. The issue arises when the URI does not contain an authority component (a host name in a DNS name or e-mail address), because the 3280bis description of how to apply name constraints to URIs assumes the presence of such a component. The WG is working on text to address this issue in response to the last call comment . Steve ___ 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)]
Joe, This discussion seems to have moved from a discussion of crypto use on home/office computers, to use in routers. There is no good motivation for other than edge (CPE?) routers to make use of IPsec for subscriber traffic. We know, from discussions with operators, that use of IPsec to protect BGP is a non-starter, because of where in the router the processing would be done (given current router designs). In any case, use of IPsec by routers is a very different topic that use in home/office computers and ought not be brought into this discussion. As for the original topic, yes, performance hits come in various flavors when we discuss crypto protocol use. For example, there was a good paper at NDSS a few years ago that showed how "marshalling" of data in SSL implementations was a very big part of the performance hit. Nonetheless, the bottom line is that for mainstream users, most of us are not convinced that performance is the primary reason for not using crypto. Steve ___ 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)]
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. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Internet 2.0 box Was: IPv6 addresses really are scarce after all
At 11:23 AM -0700 8/23/07, Hallam-Baker, Phillip wrote: If we can meet the needs of 80% of Internet users with some form of shared access there will be more addresses left for the 20% with greater needs. I suspect that the actual percentages are more like 95% and 5%. My Internet use is certainly not typical, it is considerably more intensive than the median user. And as for the claim that I would saddle the Internet with a 1970s technology, I don't think that DNS counts. For a start the SRV record only appeared in the late 90s. It is much easier to rant against something when you don't bother to find out what it is. The DNS is a 1980's technology. We used hosts.txt prior to that. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Review of draft-hartman-webauth-phishing-05
Henning, Some WGs issue Informational RFCs that represent WG consensus, but which are not viewed as suitable Standards track documents, for various reasons. For example, RFC 3647 is one of the most widely cited of the PKIX RFCs, yet it is Informational because its a policy and procedures document, not a protocol document. Some WGs also choose to publish a requirements spec as Informaitonal, even thought the document that will meet the requirements will itself be standards track. So I think we have a wide variety of document types that wind up as informational RFCs, even today. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4
At 11:40 AM -0700 8/9/07, Bill Manning wrote: O... ICANN is also a legal entity, with the same vulnerabilities as all other companies including RIR's... which was my point. "Special" is reserved for governments... :) The U.S. Dept. of Commerce recognizes ICANN exclusively (via an MoU) with regard to certain Internet functions, so maybe that makes ICANN "special," once removed :-). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4
At 9:03 AM -0700 8/9/07, Bill Manning wrote: ... > The RIRs are recognized as neutral, primary address space allocators who have contractual relationships with the folks to whom they allocate addresses. I think it might be more attractive to the new holder of address space to have a relationship with an RIR vs. the former address space holder, a company that might be acquired by another company, change business orientation, declare bankruptcy, ... "...are recognsied..." - by whom? "... I think..." - may not be a shared point of view. On the IETF list many messages represent points of view that are not widely shared :-). One might assume that when GE issues certs for subnets of its address space, that a contractual relationship would exist. I agree that a legal agreement with a large company (e.g., GE or HP) might be just as good a guarantee as an analogous agreement with an RIR. And I am pretty sure that GE has been around for quite a few years longer than all the RIR's combined. It has, but it has been in and out of various business areas as the CEO and Board have decided what is and is not a good place to make money as times change. RIR's are legal entities, just like other companies... and are subject to the same problems that companies have, e.g. aquired, changed orientation, bankruptcy... etc. They are NOT special. I disagree with your suggestion that the RIRs are not special. They are recognized as being "special" by ICANN. I will not pursue a rat hole discussion on whether ICANN is "special" :-). Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4
At 6:35 AM -0700 8/9/07, Bill Manning wrote: ... > The RIRs are working to enable clean transfer of address space holdings, using X.509 certs. While one could do what what Harald suggested, the new address space holder would have to worry about HP revoking the cert it issued to effect the transfer. A "cleaner" model would call for HP to effect the transfer through a registry, so that HP is no longer in the cert path. and they would then not have to worry about the RIR revoking the cert? --bill The RIRs are recognized as neutral, primary address space allocators who have contractual relationships with the folks to whom they allocate addresses. I think it might be more attractive to the new holder of address space to have a relationship with an RIR vs. the former address space holder, a company that might be acquired by another company, change business orientation, declare bankruptcy, ... Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-shirey-secgloss-v2-08.txt
At 9:32 AM -0400 8/9/07, David Harrington wrote: Hi, The issue was raised during ISMS WGLC that there is a difference between our use of the word authenticate and the glossary in RFC2828. Since ISMS extends SNMPv3, ISMS is using terminology consistent with the SNMPv3 standard, which reflects English usage. Could you identify the specific I-D with which this mismatch between the 2828(bis) definition arises? I think re-defining the word authenticate is not a good idea. I think it will not help the IETF write clear and unambiguous specifications to redefine words for IETF usage that are already clearly defined in English. if we want new keywords, then the IETF should invent new terms, not redefine existing terms. I would not make that argument in general, because technologies very often assign special or narrow definitions for common English words. In the IETF context, "tunnel" might be a good example, "peer," etc. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4
At 4:36 PM +0200 8/8/07, Iljitsch van Beijnum wrote: On 8-aug-2007, at 12:07, Harald Alvestrand wrote: Routing certificates are simple. If HP "sells" (lends, leases, gifts, insert-favourite-transaction-type-here) address space to someone, HP issues a certificate (or set of certificates) saying that this is how HP wants the address space to be routed; the fact that the routes point to non-HP facilities is nothing that the route certificate verifiers can (or should) care about. If this is how it works, then apparently you CAN de facto own address space after all. The RIRs are working to enable clean transfer of address space holdings, using X.509 certs. While one could do what what Harald suggested, the new address space holder would have to worry about HP revoking the cert it issued to effect the transfer. A "cleaner" model would call for HP to effect the transfer through a registry, so that HP is no longer in the cert path. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: PKI is weakly secure (was Re: Updating the rules?)
At 1:13 PM -0700 7/10/07, Douglas Otis wrote: On Jul 8, 2007, at 10:34 PM, Eliot Lear wrote: This can be said of any technology that is poorly managed. So, you merely believe that the infrastructure of PKI is well managed. In all but a single instance I have no evidence to the contrary. The one case of an exploit was extremely well publicized and ameliorated within days. And that was years ago. Trust Models. Once a CA is vetted, it can be leveraged as a point of trust. The trust is of an association with a URL validated by the certificate. your reference to a URL is a very specialized (not generic) description of how one might interpret the security services associated with a CA. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: PKI is weakly secure
At 10:54 AM +0900 7/10/07, Masataka Ohta wrote: ... Stephen Kent wrote: The notion of CA compromise and ISP comprise are not completely comparable, which makes your comparison suspect. As I already mentioned, social attacks on employees of CAs and ISPs are equally easy and readily comparable. the attacks may be comparable but not all of the effects are the same. > Also, the security implications of errors (or sloppiness) by ISPs is very different from that of CAs, so I don't think your comparison makes sense in that regard as well. Given the sloppiness of current DNS management, secure DNS CAs, which is an PKI, will be no different from that of ISPs. DNSSEC is very analogous to a PKI in many respects, but it too is not quite the same. A major difference is that the DNS hierarchy is authoritative for the bindings it establishes, whereas the common, trusted-third party CA model involves organization who are authoritative for nothing. It hard for you to recognize that most, if not all, of the effort of IETF security area has been wasted in vain. As opposed to wasting efforts constructively? But that's the reality. Masataka Ohta It's so generous of you to provide the rest of us with your wisdom with regard to the reality of security. I'm not sure we are deserving, and so maybe it would be fairer to not share so much. Steve___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: PKI is weakly secure (was Re: Updating the rules?)
At 6:36 PM +0900 7/7/07, Masataka Ohta wrote: Keith Moore wrote: Also from the draft: "At least for the strong security requirement of BCP 61 [RFC3365], the Security Area, with the support of the IESG, has insisted that all specifications include at least one mandatory-to-implement strong security mechanism to guarantee universal interoperability." I do not think this is a factual statement, at least when it comes to HTTP, which is where my interest lies. note that it is not necessary to have at least one mandatory-to-implement strong security mechanism to guarantee What, do you mean, strong security? Given that CAs of PKI can be compromised as easily as ISPs of the Internet, PKI is merely weakly secure as weakly as the plain Internet. Masataka Ohta The notion of CA compromise and ISP comprise are not completely comparable, which makes your comparison suspect. Also, the security implications of errors (or sloppiness) by ISPs is very different from that of CAs, so I don't think your comparison makes sense in that regard as well. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Questions on my role as the 2007-8 nomcom chair and the various discussions on the IETF list
At 12:29 AM -0700 6/13/07, Lakshminath Dondeti wrote: Folks, One person has voiced concerns on my "taking a strong public position" in the "Should I* opinions be afforded a special status?" thread while serving as the chair of the 2007-8 nomcom. Perhaps there are others with similar concerns. The role of the nomcom chair is clearly described in 3777 and I intend to conform to that RFC. Beyond my assigned duties, I am an ordinary contributor at the IETF and my opinions count no more than other contributors' opinions. For those who don't want to rely on my assurance, RFC 3777 comes to their rescue and mine. The adviser and the at least three liaisons are expected to ensure that the chair in particular executes the assigned duties in the best interests of the IETF community. If you have further questions, please do not hesitate to contact me. I think there is nothing wrong with your dual roles as individual participant in IETf discussions and as NOMCOM chair, especially since the chair is a non-voting member of the NOMCOM. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [TLS] Review of draft-housley-tls-authz-extns-05
Russ, I concur with Pasi's observations. I don't recall seeing a similar structure in an RFC, where a part is informative, in what is otherwise a standards track document. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Fwd: TLS authorizations draft
At 10:16 AM -0400 5/18/06, Russ Housley wrote: I received this note from Angelos Keromytis regarding the draft-housley-tls-authz-extns document. I plan to accommodate this request unless someone raises an objection. Russ OK, I'll object :-). KeyNote has no IETF status, to the best of my knowledge. It is closely aligned with the SDSI/SPKI work for which the IETF created a WG, but ultimately rejected as a standards track effort. So, I find it inappropriate to extend this standards track document to include support for a technology that, via a tenuous link, never made it to standards track status in the IETF. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what is a threat analysis?
At 3:08 PM -0700 8/11/05, Ned Freed wrote: I thought that what Russ asked for was not a threat analysis for DKIM, but a threat analysis for Internet e-mail, the system that DKIM proposes to protect. The idea is that only if we start with a characterization of how and why we believe adversaries attack e-mail, can we evaluate whether any proposed security mechanism, e.g., DKIM, is appropriate, relative to that threat analysis. This is more less my guess as to what's being asked for, although I disagree with the implication that DKIM proposes to protect email in its entirety. Regardless, others do not appear to agree and instead apppear to be doing very different sorts of analyses. Ned I agree that DKIM need not protect e-mail in all security dimensions. My definition of threat analysis for this context does not require that, although I admit the wording could have been clearer. In any threat analysis, the author decides what threats he/she wants to address. The reader decides if the author has omitted any that the reader believes are important (to the reader), and thus may reject the analysis if threats of interest to the reader were not addresses. In this case, I believe the informal discussion centered on adversaries who wish to inject spam into the Internet e-mail system, or who wish to engage in phishing attacks via e-mail. If so, then the author merely states that, and proceeds to discuss the motivations for such adversaries (what constitutes success for them) and by what means they can/do carry out attacks. With this as background, the author then explains how a proposed set of countermeasures prevents such attacks, or makes them harder, etc. The reader then evaluates the claims of the author re the effectiveness of the proposed countermeasures, given an agreed upon threat model. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what is a threat analysis?
Folks, I thought that what Russ asked for was not a threat analysis for DKIM, but a threat analysis for Internet e-mail, the system that DKIM proposes to protect. The idea is that only if we start with a characterization of how and why we believe adversaries attack e-mail, can we evaluate whether any proposed security mechanism, e.g., DKIM, is appropriate, relative to that threat analysis. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: what is a threat analysis?
Dave & Michael, In the DoD environment, a threat analysis for a system identifies the classes of adversaries that the author believes are of concern, and describes their capabilities and motivations. Russ's three questions are a concise way of stating this: - The "bad actors" are adversaries. - Their capabilities allude to where the adversaries "fit into the system" and what sorts of attacks they may employ of effect their goals. - Their motivations indicate what they are trying to do, the flip side of "what are we trying to prevent them from doing." The term is often used more broadly in the commercial world today, encompassing activities that might be better termed "threat assessment" "risk analysis" etc. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Port numbers and IPv6(was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)
Phil, > layered defenses are a good notion, but mostly when the layers are under the same administrative control. all too often people forget that relying on the security provided by someone else is a risky proposition, as in your example of ISPs providing ingress filtering. I would restate your assertion: It is a bad idea to rely on another party that cannot be held accountable to you. We all rely on other parties, the Internet is an example of extended interdependency. The critical issue is accountability. So in the question of ingress filtering what I am looking at is mechanisms to create accountability. the Internet is composed of Autonomous Systems, and they take the first word of the name very seriously. I suspect ISP accountability in China, for example, may be as successful as copyright enforcement in that region. > If it weren't a good analogy I don't think I would have received so many private responses congratulating me for it :-) This forum is very much wedded to a security architecture based on a particular set of academic theories. It is no surprise that you find support here, any more than the original pontifex maximus would no doubt receive congratulations on his correct determinationof the auspices from the entrails of a goat. I'm more a fan of goat cheese than entrails, but to each his own. Maybe we would all be happier if you decided to not waste your time arguing with the folks in "this forum," since we are so out of touch and irrelevant to the future of network security, at least as defined by the practitioners who appear to emphasize the appearance of security over security per se. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Port numbers and IPv6(was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)
Phil, ... Boy are you in for a shock when you try to connect to an ethernet with 802.1x. I have yet to do so. I do have the facility on my Mac, but I've never had to turn it on. Authentication is being built into the NIC cards. At some point in the future it will not be possible for any device to connect to an Intranet without first authenticating itself. It could happen, but then too it might not. And it will all have to be 100% transparent to the user. only when it works :-) > if folks rely on such distributed enforcement, they will get what they deserve. You are behind the times, single point of failure approaches to security are out. layered defenses are a good notion, but mostly when the layers are under the same administrative control. all too often people forget that relying on the security provided by someone else is a risky proposition, as in your example of ISPs providing ingress filtering. What people are looking to do is to contain attacks from within their networks. Most large companies now have networks that are large enough for what is inside the firewall to be at least as worrying as what is outside. fair statement why not just propose rigorous enforcement of setting the evil bit by all network attachment devices, etc? Sarcasm is not a particularly useful mode of debate, particularly when you are defending a dogma that has little practical success to recommend it. If it weren't a good analogy I don't think I would have received so many private responses congratulating me for it :-) Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Port numbers and IPv6(was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)
At 2:35 PM -0700 7/19/05, Hallam-Baker, Phillip wrote: > Host and application security are not the job of the network. They are the job of the network interfaces. The gateway between a network and the internetwork should be closely controlled and guarded. Nobody is really proposing embedding security into the Internet backbone (at least not yet). But the backbone has always had controls enforced such as ingress and egress filtering. no, it does not, although many folks might like to believe this is true. relying on every ISP to perform such filtering also would be a blatant violation of the principle of least privilege anyway. Most people think that carriers should not be allowing people to inject bogons. Modern security architectures do not rely exclusively on application security. If you want to connect up to a state of the art corporate network the machine has to authenticate. the notion that one has to "log into the net" is a quaint one, perhaps inspired by Windows and the registry. as a mac user, I can't relate to this notion, nor can most Unix users, I bet. In the future every hub, every router, every NIC will be performing policy enforcement. if folks rely on such distributed enforcement, they will get what they deserve. why not just propose rigorous enforcement of setting the evil bit by all network attachment devices, etc? De-perimeterization is not really about removing the firewalls, it is really about making every part of the *network* into a security control point. Firewalls were created, in part, because site admins realized that they were unable to perform configuration management for the many devices on their nets. a firewall was a device owned by the admin and under his control, and if it acted as a gatekeeper for the net, then his job was easier. the fact that it is am imperfect gatekeeper is a second order issue. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When to DISCUSS?
Yakov, Ultimately the marketplace will decide, but when a WG provides multiple solutions to the same problem it has the potential to confuse the marketplace, retard adoption of any solution, interfere with interoperability, etc. Standards ought to avoid confusion, not contribute to it. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: E911 location services (CAS system too)
Harald, You are right that the scheme I proposed inn 1422 did not succeed, and today I would not suggest it. But, the reason I would not suggest it today is because I have come to believe that one should adopt CAs that are authoritative for the certs they issue, not "trusted" third parties. The DNS root is an example of such a CA, whereas RSA (proposed as the IPRA) was not. If we deploy DNSSEC in a full, top down fashion, the effect is the same as what Kevin is suggesting, expect that we would be using a standard cert format that is employed by many security protocols. steve ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: UA 893 compensation
At 12:40 -0500 3/5/04, John C Klensin wrote: --On Friday, March 05, 2004 11:26 -0500 Stephen Kent <[EMAIL PROTECTED]> wrote: Thius is a note for all of the folks who flew on UA 893 on Friday, 2/27, with the unexpected 24 hour delay via Seattle. I just got off the phone with UA Customer Service (not Mileage Plus). They offered a 5K mile "good will" compensation for our inconvenience. These miles will not count toward Premiere Qualification. You could also request some 500 mile domestic upgrades as an alternative. They were firm in refusing to offer qualifying miles, because they insist that such miles can be offered only as a result of paid travel, and we already received miles consistent with out paid travel. Steve, and others, Negotiating about this sort of thing with the airline many of us love to hate may not be productive or worth the trouble, but, suppose that, instead of flying you nearly halfway to Taiwan from SFO and then bringing you back to Seattle and starting over, you had, e.g., originated in Seattle (assuming they have such a flight at this time of year), they had equipment problems and then rebooked you onto a Seattle-LAX flight and then an LAX-Taipei flight. Under that situation, they award (occasionally after some yelling and screaming, but usually without it) the SEA-LAX-Taipei mileage (you actually took those flights) and not the shorter SEA-Taipei mileage. And those miles count for elite qualification. This situation is different, but the difference has to do with the subtle issues of flight numbers and segments, not with paid miles flown. Good luck. john John, Good suggestion for a line of argument. Steve
UA 893 compensation
Thius is a note for all of the folks who flew on UA 893 on Friday, 2/27, with the unexpected 24 hour delay via Seattle. I just got off the phone with UA Customer Service (not Mileage Plus). They offered a 5K mile "good will" compensation for our inconvenience. These miles will not count toward Premiere Qualification. You could also request some 500 mile domestic upgrades as an alternative. They were firm in refusing to offer qualifying miles, because they insist that such miles can be offered only as a result of paid travel, and we already received miles consistent with out paid travel. Steve
Re: TCP over IPSec ESP??
At 2:51 -0800 2/21/04, chintan sheth wrote: Hi, Is there anything called TCP over IPSec ESP? I believe it should be IPSec ESP over TCP. Please clarify. Also, point me to the relevant RFC #. Thanks, Chintan TCP can be encapsulated by ESP. The correct spelling for the protocol is IPsec, not IPSec. ESP is not generaly run over TCP. RFC 2402 describes the use of ESP. Steve Kent author of 2401, 2402, 2406, ...
Re: Visa for South Korea
At 11:34 -0500 12/30/03, Ken Hornstein wrote: >From my reading of the Korean Embassy web page, it seems that US residents will require a visa to attend the Seoul IETF. I'm wondering if anyone has gotten a visa to enter South Korea before, and if so, can they provide any tips on the visa process? (The only requirement that looks like it will be a pain is the letter from your employer). --Ken I attended a technical meeting in Seoul in the summer of 2003, and did not require a visa. We should get a reading on this from our hosts. Steve
Re: PKIs and trust
At 6:08 +0900 12/16/03, Masataka Ohta wrote: Stephen Kent; I'm having a feeling that you call a set of software/hardware to handle certs a PKI. no, there is a lot more to a PKI than hardware and software. The problem for such PKI is that, if we have certs based on existing trust (e.g. I trust some organization have an authority to issue passports) relationships, we can exchange shared secret using the relationships that we don't need any public keys. In principle, yes, but in practice it is preferable to use public keys for a variety of security reasons, In practice, I see no security reason not to use shared key cryptography. See below about the practice of the cases you choose (passports, frequent traveller cards, etc.) not to mention the existence of a lot of software that can make use of certs and public keys. I'm afraid you are saying we should have PKI because we have PKI. why do we use browsers to access many databases where other mechanisms might be more appropriate? because we all have "free" browsers, users and developers are comfortable with the paradigm, ... This is what happens in the physical world with most physical credentials: passports, frequent traveller cards, etc. Our trust relationships in these cases are so strong that we can be delivered not only PINs (shared secret) but also physical credentials. Yes, but it is cheaper to issue credentials in the form of certs and avoid postage and related physical credential costs. In all (passports and frequent traveller cards) cases, it is required that applicants physically contact authorities. True for an initial contact for a passport, not for renewal. When I referred to frequent traveller cards I had in mind the airline/hotel/car rental frequent traveller programs to which I belong, not credentials that get me through security with less examination. (Although my frequent flyer cards DO get me into shorter lines in many airports.) In Japan, and maybe in other countries, use of material mail is inevitable to get passport, because it is the way to confirm the addresses of applicant. The address of an applicant is not even printed on a US passport. It is not part of what the U.S. Department of State attests to when issuing a passport. One can pick up frequent travellor cards, at least paper ones, at airport. I can get my form of frequent traveller card via a web interaction, with no physical presence! Also, PINs are meant to be remembered by users and thus are mire vulnerable to guessing than key pairs. So we have to put into place attack monitoring and response schemes, e.g., locking down an account after N bad login attempts, which creates DoS opportunities! So there are many reasons to prefer PKI here, although there are downsides too. Here, we are talking about physical credentials optionally accompanied by PINs. So, long PINs may be securely stored in the physical credentials (maybe with additional short PINs to activate the physical credentials, which is also the case for devices storing secret keys of public key cryptography). DoS is to steal the physical credentials. I think we are talking about different use models. If I have a frequent flyer account with web access, and if someone tries to break in by guessing my PIN, the airline will have to shut down the account after some small number of tries, to prevent an effective guessing attack. This denies ME access, and it imposes costs for the airline, because I may have to make a toll free call to someone to cause my account to be reactivated. That is a DoS attack that could be avoided if we used crypto keys for auth. The next question is, does a, two or millions of PKIs worth having? I don't think they do. I don't know how many we need. But, when I look in my travel bag I see about 30+ paper and plastic credentials, all of which could be turned into certs under the right circumstances, without creating new "trusted" organizations, I think we can, at least, agree that we need no "new trusted organizations" or commercial CAs. agreed! and with the benefit of greater security and less bulk (bits are thin and light weight!). That you have paper and plastic credentials means that you don't need much security. not really. I rarely uses most of those credentials today. They are largely replaced by web accesses where knowledge of the account number and a PIN provides the authentication that used to be inferred by physical possession of the card. That you have an IC card containing 30+ secret keys activated with a short PIN does not mean so much security. How do you think about an IC card erases all the secret information after N bad PINs, which creates DoS opportunities? I am not too worried about physical security for a crypto hardware token, because I am careful to not lose such tokens, just like I am, careful to not lose physical (paper/plastic) cards today. The advantage to
Re: PKIs and trust
At 4:31 +0900 12/16/03, Masataka Ohta wrote: Stephen Kent; I've authored several papers that capture what I see as the essence of your characterizations, in a simple form. The central notion is that most of these relationships are NOT about trust, but rather about authority. if one views them in this fashion, then it becomes apparent that the entities that are authoritative for identification and authorization assertions should be CAs, and we, as individuals with many distinct identities, should expect to hold many certs, each corresponding to one identity. The problem for such PKI is that, if we have certs based on existing trust (e.g. I trust some organization have an authority to issue passports) relationships, we can exchange shared secret using the relationships that we don't need any public keys. In principle, yes, but in practice it is preferable to use public keys for a variety of security reasons, not to mention the existence of a lot of software that can make use of certs and public keys. This is what happens in the physical world with most physical credentials: passports, frequent traveller cards, etc. Our trust relationships in these cases are so strong that we can be delivered not only PINs (shared secret) but also physical credentials. Yes, but it is cheaper to issue credentials in the form of certs and avoid postage and related physical credential costs. Also, PINs are meant to be remembered by users and thus are mire vulnerable to guessing than key pairs. So we have to put into place attack monitoring and response schemes, e.g., locking down an account after N bad login attempts, which creates DoS opportunities! So there are many reasons to prefer PKI here, although there are downsides too. Then, who need public key cryptography? Thus, many expect thatm once a PKI is formed, it can create any trust relationship for anything. We know a PKI does not. agreed. The next question is, does a, two or millions of PKIs worth having? I don't think they do. I don't know how many we need. But, when I look in my travel bag I see about 30+ paper and plastic credentials, all of which could be turned into certs under the right circumstances, without creating new "trusted" organizations, and with the benefit of greater security and less bulk (bits are thin and light weight!). Steve
Re: PKIs and trust
Keith, I've authored several papers that capture what I see as the essence of your characterizations, in a simple form. The central notion is that most of these relationships are NOT about trust, but rather about authority. if one views them in this fashion, then it becomes apparent that the entities that are authoritative for identification and authorization assertions should be CAs, and we, as individuals with many distinct identities, should expect to hold many certs, each corresponding to one identity. This is what happens in the physical world with most physical credentials: passports, frequent traveller cards, etc. Steve
RE: ITU takes over?
At 8:39 -0800 12/12/03, Tony Hain wrote: vinton g. cerf wrote: ... Unfortunately, the discussion has tended to center on ICANN as the only really visible example of an organization attempting to develop policy (which is being treated as synonymous with "governance" To further your point, an area completely outside of ICANN's purview, yet an area requiring governance is PKI. We are at the point where deployment of a PKI has moved beyond technical issues, becoming almost completely the policy & politics of "trust". Until the politicians broker the trust relationships, there is nothing technology can do. Tony Not everyone agrees that PKIs are all about trust :-). Still, even if one establishes PKIs based on who is authoritative for the data in certs, as I always suggest, I agree that the major remaining problems are business and political, not technical. Steve
Re: Pretty clear ... SIP
At 19:03 -0700 8/23/03, Karl Auerbach wrote: On Sat, 23 Aug 2003, Dean Anderson wrote: H.323 and ASN.1 eventually surpass ... Ummm, based on my own direct experience with ASN.1 since the mid 1980's (X.400, SNMP, CMIP...), I disagree. It has been my experience that ASN.1, no matter which encoding rules are used, has proven to be a failure and lingering interoperability and denial-of-service disaster. For example, the flaws in ASN.1 parsers in SNMP engines have proven to be a decades+ old vulnerability for the net. To be fair, the flaws were in an implementation that one person developed and many used. The same sort of problem with a vulnerability being widespread has occurred in other contexts, w/o regard to the encoding scheme. So, this really is a red herring in this argument. We'd be much better off with XML, Scheme expressions, or Python pickles than with ASN.1 both for expressing data structures in documents and for encoding data structures into binary for carriage in packets. Certainly XML is not going to yield a smaller encoding, so your reasons for preferring it have to be based on value judgements in other dimensions. steve
Re: requiring payment (was spam)
At 3:10 PM -0700 5/30/03, Einar Stefferud wrote: Pity the poor Zealot; who, when he loses sight of his objective, simply redoubles his efforts. For sure, do not let any new ideas leak into the IETF! Cheers...\Stef Pity the poor fellow who ventures outside his realm of knowledge and then recommends dreck. New ideas ought not be confused with sound ideas. Those with no background in an area are easily impressed by the new, without benefit of the wisdom that comes from familiarity with knowledge of the old. We can continue this repartee as long as you wish. I do have a day job, but debating with you represents such a slight diversion of effort ... Steve
Re: requiring payment (was spam)
At 1:36 AM -0700 5/29/03, Einar Stefferud wrote: I suggest that those who wish to more fully understand all this trust stuff might find it useful to look at http://mcg.org.br/. Cheers...\Stef I would recommend this web site only to folks who want to see a very narrow view of what trust and certification are about, a view not consistent with most standards in the PKI arena, and one not shared by most legal experts, ... Steve
RE: .p7s attachment
At 9:27 AM +1200 3/13/03, Franck Martin wrote: I think the trouble with this attachment is that the whole e-mail is encrypted "in clear" (anybody can decrypt) to save space when you send the e-mail (SSL/TLS includes compression). It's not encrypted, it's encoded in a form (base 64) that is unlikely to mangled by "helpful" mail relays, and thus ensures that the signature is likely to not fail because of "friendly fire." Let's be accurate in our comments. Steve
Re: IPv6 and child pornographers
Mr. Baptista, In reading your message re the history of security and the Internet I my attention was drawn to the following paragraph: DARPA planners unfortunately were short sighted and did not anticipate the technology would become an international standard for communications. The community of users and networks connected to DARPA were small and trusted so security concerns were a low priority. The end result was the deployment of insecure protocols that have kept many security experts gainfully employed. Even secure protocols are hacked. Today there are millions of compromised computer systems busy trying to hack other computers. And many of those busy hacking computers may no longer be under the control of the original script kiddy hacker who launched them. In fact I suspect many such computers are operating independently of a human operator. As one of the fortunate folks who participated in the ARPANET and the beginning of the Internet, I can attest to the accuracy of the first sentence. Unfotunately, most of the rest of the paragraph, and the rest of your message, is incorrect. The first crypto-based security protocols for packet nets (and devices that implemented them) were developed in the mid-70s, here at BBN, and deployed in the ARPANET. In the later half of the 70s we also developed the first IP-based end-to-end crypto protocols and devices, using KDC-style technology well before the development of Kerberos at MIT under project Athena. So, it is inaccurate to suggest that the DoD did not pay attention to security concerns in the development of IP. The primary security mechanisms that are part of IPv6, are the same ones that are available for IPv4 today, namely IPsec. So it would also be inaccurate to suggest that IPv6 offers significant new security options relative to v4. Although one can argue that the address space capabilities of v6 offer the potential for increased privacy relative to v4, even this may not be true in practice, as there are many ways by which privacy is likely to be compromised by higher layer protocols. Depending on the type of traffic that Carnivore is being used to intercept, I doubt that the transition to v6 form v4 will be a concern, absent use of IPsec or S/MIME or SSL/TLS. IPsec does not make IP "less prone to man in the middle interception ..." It makes v4 and v6 immune to such interception. IPv6 will NOT do this automatically. It still requires user/admin configuration and key management, which has often proved to be an impediment, largely because of poor management designs/interfaces. I could go on to identify many more errors in the statements you made re various security matters. As the military would say, you message is a "target rich environment." But, I think this ones noted above suggest that you don't really understand the nature of security in the Internet. Steve
Re: Global PKI on DNS?
At 11:58 AM -0400 6/25/02, Keith Moore wrote: > > We seem to agree that the DNS could be sued to distribute certs, so >> the question is what should the certs attest to and who should issue >> them. I argue that we need certs that support validation of DNS >> bindings, and that the only authoritative sources for that info are >> the folks who manage the DNS. > >and there is no assurance that they're trustworthy. since trustworthiness is a relative term, that can always be said about any CA. that's why I don't like dealing with CAs based on trust. authoritativeness is a quality that is less contentious in many contexts, including this one. > > Anyone else is a TTP, with all the >> problems that implies. > >the problems associated with TTPs may actually be less than the problems >associated with implicitly trusting the TLDs. you *choose* whether to >trust a TP. limited trust of the TLDs is essentially forced on you, >but it's a mistake to extend that trust beyond the minimum necessary. and a DNS-based PKI would not require anyone to trust it. people could choose to make use of it, or could continue to make use of the insecure system we have today. nobody said that making use of the certs would be mandatory; it would be an option we currently do not have. you fear that people would decide to rely on this new aspect of the infrastructure and you think that, because of the specific organizations operating some TLDs, that this would be a bad choice. but, since we agree that people implicitly rely on it anyway, I don't see the change as a a bad one. >it's one thing to get an address RR of a server from a TLD. you still >have the opportunity to authenticate that server via other means that >you trust. the worst the TLD can do in this case is a DoS attack. > >OTOH if the TLD has the capability of issuing a bogus cert for the >server you want to contact, and you are foolish enough to trust it, >you're screwed. and the TLDs will mislead the public into trusting >them, because they'll be the "obvious" choice, and because there's >nobody to keep them honest. if you really do have viable means of independently verifying the accuracy of the binding, then you can always choose to employ them. I think that such means are rare in practice. but, in any case, these means could still be available. >this is why a DNS-based PKI is a Bad Idea. > >OTOH being able to access TP certs via DNS could be quite useful. > >the most trust that should be invested in the TLDs (or any zone) >should be the ability to authenticate the RRs in their zone, >and specifically NOT to authenticate servers. and we don't need >a DNS PKI to authenticate RRs, we have other mechanisms for that. let's just say we disagree. Steve
Re: Global PKI on DNS?
At 5:25 PM -0700 6/20/02, Ed Gerck wrote: >Stephen Kent wrote: > >> Your example does not require cross-certification. It only >>requires that the relying parties be members of, or have access to >>the (CA) credentials for, the communities to which the individuals >>belong. Cross certification is one way to accomplish this, but it >>is not the only way. > >Cross-certification is the way to do it automatically, tamperproof and that. >But PKI does not work with cross-certification, so cross-certifcation must >not be useful ;-) there is an important difference between what one can do and what one must do. my point was that your example does not require cross certification, that's all. Moreover, there are many instances of PKI-like systems where cross certification is definitely not a desired feature, e.g., credit card issuers. > > You keep asserting that a single root does not permit scaling, >but I have yet to see a good argument supporting that assertion. > >;-) for starters, just read your own emails in this thread. You >mentioned at least >two reasons why a single root is not good for PKI. My reasons include the >observation that a single point of control is also a single point of >failure. One >perverse aspect of the single root is, thus, that as the PKI grows >and the single root >gathers all the liability there is a point after which the liability >at that single root >may not even be insurable. Just think of it: all world e-commerce >compromised because >of one snafu at one point? This would be involution, not evolution. I don't recall having said that a single root is bad for an individual PKI. Please refresh my memory. Yoru example here is also flawed. Consumer e-commerce today relies on credit cards, and there are multiple issuers each of which is independent of the others. Each acts analogously to a root for an island of certification. > > In part this seems to result from your approach to defining a >PKI, a definition not consistent with most others in the literature. > >I have not defined what a PKI is. I guess there are already plenty >of definitions >around. I just said that a PKI would need to be an infrastructure >-- that pesky >"I" at the end of PKI. We have lots of physical world infrastructure examples where there are the equivalent of multiple, independent roots. Infrastrucucture need not imply the universality that you seem to imply. >But failure to be an infrastructure is IMO one of the reasons why >PKI is at a dead >end. The DNS, OTOH, is an infrastructure. Mixing both will reduce >the infrastructure >property of the DNS, reduce interoperation and alienate business drivers. I don't see how any of these assertions are supported by what you have said. >There are many problems with the DNS, surely. I have catalogued >more than forty >serious problems. But the DNS has scaled from 10^4 users to almost 10^8 users >without much change. We should be careful in adding a limited technology such >as PKI to the DNS. The converse seems to be more reasonable -- >using the DNS to >add distribution channels (for certs and revocation information) to >a PKI. This can >be done right now. We seem to agree that the DNS could be sued to distribute certs, so the question is what should the certs attest to and who should issue them. I argue that we need certs that support validation of DNS bindings, and that the only authoritative sources for that info are the folks who manage the DNS. Anyone else is a TTP, with all the problems that implies. No other names that we might put in certs will provide the same sort of security features that DNS-based certs will provide, because people and software use DNS names to identify the machines they initiate communication with in the Internet. So, the fact that we could store certs issued by arbitrary TTPs, with non-DNS names, is true, but ultimately not very useful for basic Internet security. Steve
Re: Global PKI on DNS?
At 11:03 AM -0500 6/18/02, Alex Audu wrote: >Ed, > >You made some interesting points which leads me to wonder if >we can define Trust in such a way that its parameters are verifiable, >then we can verify that it is transitive. In other words, if Jon gets >a dollar from Mike, and Jon can verify the parameters of the dollar, >then Jon doesn't care about the "trustworthyness" of Mike's source. >Or should he? > >Regards, >Alex. I didn't want to comment on this example, but your message forces me to do so. Jon verifies the dollar, which is a bearer credential, and not Mike, the person from whom he received the dollar. (The dollar could have been stolen by Mike!) This example says nothing about transitivity of trust. Steve
Re: Global PKI on DNS?
Stef, >Hi Steve -- Now we are beginning to connect with the real meta issue. > >I am talking about "Trust Transitivity" in general. >We agree that the DNS offers no trust functions, useful or otherwise. >So, my focus is not on PKI as related to DNS, which is what you >addressed here. > >It the fundamental issue of trust transitivity in PKI. > >I will concede that PKI is transitive in terms of "connectedness" as is DNS. >Both have relations of relatedness, but this does not confer >transitivity on trust. >Trust still has to be earned, not awarded, in any case. > >I am questioning the validity of the widely held assumption that trust is >(or can be) transitive in PKI (or anywhere for that matter). > >So, back to my basic question: > >Is trust transitive anywhere under any conditions? > >I question that it is, until someone proves that: > > "Trust is transitive somewhere/anywhere in real life"; > >and then prove that: > > "Trust is transitive in PKI Theory"; > >and then prove that: > > "Trust is transitive in PKI reality". > >HINT: It will help if you can refer to some Formal Logical Theory of TRUST. > >First, forget PKI and forget DNS, and show that trust is transitive >somewhere under some describable conditions. Then show that trust >is transitive in PKI. > >I know that many people assume that Trust is transitive in PKI. >I am not asking about popular opinion here. >We need some formally logical facts. >If you have some, please show them to us. > >Cheers...\Stef This is getting tiresome. I have the feeling that you do not read to the end my messages. I'll keep this short: - I have never stated that trust is transitive; in fact, I have given numerous talks and written a number of papers that state the opposite, so my position has been consistent and on the record for many years. - although many popular PKIs (including PGP) assume on transitive trust, this it not an intrinsic feature of PKIs. - a PKI in which each CA is authoritative for the name space in which it issues certs need not involve transitive trust. - cross-certification in such a PKI need not involve trust; it can merely represent a recognition by one CA of the authority of another CA for a different part of a name space In the case of DNS, where authority for each part of the name space is well defined, I argue that having the folks who are responsible for the domains assume the role of CA for their domains is a natural way to create a PKI that attests only to the binding of DNS names to keys. I maintain that this does not involve transitive trust. Steve
Re: Global PKI on DNS?
At 11:30 AM -0700 6/14/02, Ed Gerck wrote: >Stephen Kent wrote: > >> >> Could you elaborate, perhaps privately, with why you believe a "true >> PKI" needs multiple roots? >> >> >> My view is that too many >> folks have tried to get too much out of any single PKI, and that has >> caused a lot of our headaches. if we admit to the need for many PKIs, >> each serving a well-defined user community, then I think each of >> these PKIS would be easier to create, manage, and deal with from a >> liability standpoint. > >Steve: > >You have answered your own question above. As you say, folks have >tried too much out of a single PKI and failed. That is why a true PKI (ie, >one that works as an infrastructure) would need to include many PKIs. >Each one of these "many PKIs" represents one root, with multiple >PKIs creating multiple roots. Now, unless you want each one of these >many PKIs to be isolated -- and not create an infrastructure -- there >is a need for cross-certification allowing users of one PKI community >to talk to users of another PKi community. In DNS parlance, you need to >find AND validate routes among multiple roots. I see what you mean by a "true" PKI, but I don't want one :-) My examples of disjoint credential spaces in the physical world are not unified and they ought not be. There usually is no incentive for the issuers to cross certify in most cases for these separate roots, and it creates new liability concerns, and raises trust issues. > > if I look in my wallet, I have a lot of credentials, each issued by a >> different organization. Each is useful only in certain contexts. Each >> tends to uniquely identify me via a number of some sort and often >> that number is meaningful only in the context for which the >> credential was developed. We would be in pretty good shape if we had >> PKIs that parallel these paper and plastic credentials. > >Agreed. The fundamental problem is that the PKI architecture cannot >directly provide mutiple root functionality. You need to overlay bridge >CAs and other artifacts in order to create the paths. Now, imagine a >different mathematical structure, one that is not based on a hierarchy >and yet works with hierarchical systems (as well as non-hierarchical >systems liek a peer-to-peer network). Such structure could allow paths >to be found, and validated, from one hierarchy (PKI, DNS) to another >(PKI, DNS). I disagree; PKIs can accommodate multiple roots. Mesh certification is and old concept (intrinsic in X.509), but it is way too complex for most (if not all) folks to comprehend and manage. I always point to the inability of people to program VCRs as an example of a lower bound for people's tolerance of complexity. Mesh PKIs go way beyond VCR programming. >Someone may add that the DNS is not really a hierarchy, it is just an >ontology. My argument still holds for ontologies and also applies >to how names are used in PKI certificates (as I have discussed >elsewhere, see google). A certificate is just an authenticated assertion >made within the context of a name space. The name space in a PKI >forms an ontology and that ontology is defined by name space >ownership, just like in the DNS. I don't know who would argue that the DNS is other than a singly rooted tree, but I think we are in agreement re what a cert is. > > The security >> would be better and with good software, the convenience would be >> better for users. Trying to create a single PKI that issues a cert >> that replaces all of these credentials is just not going to work. > >Agreed again. What we may see, because it is the only thing that will >work, are small PKIs using the DNS as a "directory". These PKIs do >not need to interoperate and so they will be useful. But one will not >see a single PKI that issues certs for all the DNS space. For that we >would need a different beast. I don't think you've substantiated the last part of the above assertion. >Cheers, >Ed Gerck > >PS: IMO the PKI market has been grossly exaggerated. There are only >30,000 servers worldwide that can do SSL -- which limits PKI server certs >to that number worldwide, with a factor for virtual server usage. PKI >client certs have the private key problem, that cannot be solved by >PKI, and has not really taken off (except for military apps, with smart >cards controlling access to the private key). And I am not the only >saying that PKI is at a dead end. Which is good -- because now >perhaps some serious consideration will be given to solutions. >PKI is not dead, though. It is just at a dead end. I used to be CTO for a PKI product/service ven
Re: Global PKI on DNS?
At 2:05 PM -0400 6/14/02, John Stracke wrote: > >In a system >>like DNS which makes clear who is authoritative for which names, I >>don't think the term "trust" is applicable, and that is the crux of >>our disagreement. > >The problem is that, although the owner of the domain is authoritative >for who gets to use which name, that doesn't mean their users want >them to issue certificates. The first requires that the owner trusts >the users; the second requires that the users trust the owner. And >trust is not symmetric. I see your point, but there are a lot of ways to look at this issue of in the general case. The state in which I reside determines who is authorized to issue my driver's license. The country of which I am a citizen determines who issues my passport. The employer for whom I work determines who issues my employee ID. The banks with whom I elect to have credit card relationships determine the numeric spaces fro which my credit card numbers are selected. In each case the issuer of the credential is precisely the entity who "owns" the name space in which the credential is issued. Why should a DNS-based PKI be different? As soon as you decide to allow 3rd parties to issue credentials in name spaces for which they are not authoritative, you DO introduce a whole raft of trust issues, and that makes PKIs very hard to manage and for users to understand. Maybe if I don't want my DNS cert issued by the admin for the DNS subdomain in which you "live" I should "move" to a new subdomain, a better neighborhood in cyberspace? Steve
Re: Global PKI on DNS?
Stef, >Thank You Steve for clarifying your simple little error and >correcting the record on what I did or did not say. I admit that >the error was small in commission but you must admit that it was >huge in affect, so it is good for you to corrected the record. > >I will assume that it was not intentional. no, it was not intentional. >Now, all I did was ask you to offer proof that trust is ever >transitive, as a separate sub-question of the general debate, >because in my view, this question is central to the reasons for >bothering to discuss the rest of this thread. > >In short, if trust cannot be proved to be transitive, like DNS zone >control delegation is transitive, then there is no reason to >continue with PKI designs that ASSUME TRUST IS TRANSITIVE. The essence of our disagreement is that I don't view the relationship between the CAs in a DNS-based PKI to be one of trust. We rely on DNS admins to correctly bind addresses to names in the zones they control. This is the seenace of the semantics of DNS operation. If these folks acted as CAs, we would rely on them in the same fashion to bind the same names to public keys, which just provides a secure mechanism to effect the binding of the name. If we don't call the first relationship trust, then I don't feel we should call the second one a trust relationship either. You uses the term "delegation" above and that's critical. In a system like DNS which makes clear who is authoritative for which names, I don't think the term "trust" is applicable, and that is the crux of our disagreement. Pn a less polite note, your line of argument has been to saddle me with a need to prove something that I have never asserted, which is pretty silly, at best. It's not surprising that I continue to decline to take a side of a debate that you have tried to define for me and which does not represent my position. Steve
Re: Global PKI on DNS?
Ed, >Stephen Kent wrote: > >> Ed, >> >> >> I think your sample CPS, while more than a little tongue in cheek, is >> a good example of what a CA may assert. But, in the DNS context, many >> of the issues you note are much less serious concerns than in a >> general CA context, because of the existing limitations on the names, >> the existing semantics associated with names by the DNS, ... > >Steve: > >I am in substantial agreement with your comments, especially the last one >above. However, as I commented earlier, I believe that the DNS and the >PKI models are incompatible IF you truly want to have a PKI. The reason >is that a true PKI would need to work with multiple roots while the DNS >cannot do it. HOWEVER, since Verisign de facto controls the DNS >name space (the space that matters, anyway) AND is a CA, there is >a possibility (some might say the danger) for Verisign to use this >position to de facto control a quasi-PKI space and the domain name >space. Could you elaborate, perhaps privately, with why you believe a "true PKI" needs multiple roots? >As a last comment, and already abusing the list patience, we need to >reinvent/revisit PKI! Changes are needed also in the DNS. > >One just needs to take a look to the PKI space (and sales) to realize that >it is at a dead end, topped off. PKI experience is proving my assertion of >5 years ago that PKI cannot scale beyond a certain size and only works >in a friendly context, or in one where liabilities to the user are >utterly denied >(in the military or as US law still allows -- "user beware"). > >Thus, perhaps the DNS PKI experience will be good, after all. It may help >increase/motivate the need for reinventing both, PKI and the DNS. >Perhaps, in this new design, we will be able to build in that elusive trust, >which has evaporated. As you can tell from my messages, I have a broad view of what PKIs are and what they are good for, and so I have a different spin on the relative lack of success re PKI deployment. My view is that too many folks have tried to get too much out of any single PKI, and that has caused a lot of our headaches. if we admit to the need for many PKIs, each serving a well-defined user community, then I think each of these PKIS would be easier to create, manage, and deal with from a liability standpoint. if I look in my wallet, I have a lot of credentials, each issued by a different organization. Each is useful only in certain contexts. Each tends to uniquely identify me via a number of some sort and often that number is meaningful only in the context for which the credential was developed. We would be in pretty good shape if we had PKIs that parallel these paper and plastic credentials. The security would be better and with good software, the convenience would be better for users. Trying to create a single PKI that issues a cert that replaces all of these credentials is just not going to work. Steve
Re: Global PKI on DNS?
At 11:30 PM -0700 6/13/02, Einar Stefferud wrote: >[EMAIL PROTECTED] said: > >>On Fri, 14 Jun 2002 10:52:47 +1200, Franck Martin <[EMAIL PROTECTED]> said: >> >> > Ideally, we should rate each CA in our applications and the application >> > should give us a level of risk... >>> >>>Hey.. it's the PGP Web of Trust. ;) >>> >>>Content-Type: application/pgp-signature >> >>Attachment converted: Macintosh HD:Untitled 1 (/) (0009FFDB) > >By George -- I think You've Got It;-)... > >Trust must be earned, and cannot be delegated;-)... > >And cannot be transmitted via any single communication path. > >Enjoy;-)...\Stef PGP is the epitome of transitive trust! Multiple cert paths do not necessarily make for more trust, but they do add enough complexity to make the system unscaleable, not to mention the revocation issues ...
Re: Global PKI on DNS?
Ed, >Keith Moore wrote: > >> > A PKI modeled on the DNS would parallel >> > the existing hierarchy and merely codify the relationships expressed >> > by it in the form of public key certs. >> >> so what you're saying is that the cert would mean something like: > >;-) actually, to a lawyer, a PKI cert says something like: > > "By issuing this certificate We state in accordance with the >rules which We > make and vary as We think fit for that purpose from time to time without > accepting any obligation to any other person (including any Internet > standardization entity) for the effect or consequences of Our choice of > those rules or of Our variation of them, hereafter called "CPS," that: Good start. > 1. The text string herein designated 'name' contains the string >received by Us > from a person, entity or machine, hereafter called entity, >claiming it as that > entity's name. Note that we are talking about certs with DNS names, not general DNs, and the DNS name is precisely what any DNS admin already asserts is accurately represented in the DNS sever he/she manages. > 2. We may have taken some measures at some time to receive >evidence (which > We may not have preserved and may not be able to produce) of a > connection between the name and the entity from whom it was apparently > received. Again, because of the name space in question, and the intrinsic limitations on what names can be asserted as one goes deeper in the hierarchy, the issue you cite here is not that big a deal. > 3. We have reproduced the string as We believe that We received it, which > We have denoted and formatted as to Our exclusive understanding of it, > of its context and of its validity, as regulated by Our CPS. Formatting is well defined and limited in DNS names, e.g., they are restricted to a restrictive, caseless character set (prior to internationalization). > 4. We may have tested the bit string herein designated 'key' to >test whether, > at the date appearing in this certificate, it appears to correspond to a > counterpart apparently available to the entity from whom We apparently > received the name. Whether POP was employed or not should be part of the CPS, as you know, so this point is inappropriately vague. > > 5. We are whom We claim to be. This claim can be verified by >checking Our > signature on this certificate We supply with a key which We >claim to be Our > public key. We do not offer you any grounds for believing that >the public > key in question is Our public key or that it has not been revoked before > or after the date of signature of this certificate. The only evidence We > provide of the correctness of the date of signature stated in >this certificate is > that it is dated before the date on which you are reading this >certificate. Except at the root, the CA is who the next higher tier has verified it to be, which is precisely what the DNS asserts today, but without any security mechanisms for assurance. > 6. We may revoke this certificate at any time without telling >you or anyone > else. The fact that you have downloaded this certificate from Our server > does not mean that it has not previously been revoked. The fact that no > revocation for it can be found in Our server does not mean that this > certificate is valid either. > 7. You may rely on this certificate only at your own risk, and >by so doing > you confirm your acceptance of the conditions subject to which >it is issued > as stated in the CPS for the time being in force, which is not to be > construed as any obligation regarding the time this certificate >was signed by Us or > used by you. These conditions include terms prohibiting you >from claiming > to be inadequately qualified or trained to understand or apply >the conditions, > or to have relied upon Us as an expert, or that you were forced >to rely on > Us through lack of information with which to verify Our >statements, or that > you were forced to rely on Us through lack of choice by any >reason such as > the named entity's lack of alternatives for certificates, the >browser's lack > of alternatives for embedded root keys, etc. And how would this be worse than relying on unsecured DNS responses? > 8. What public-key cryptography has joined, may time and >machines not part, > but of such binding We provide no assurance. > > In Honor of Our Root-Certificate, which attests to Our faith in the > Root-Key, until We decide to revoke them but maybe not both." > Again, if one established a PKI that paralleled the DNS, item 8 would apply to only one point in the system, and that could be managed in a parallel, distributed signature fashion. I think your sample CPS, while more than a little tongue in cheek, is a
Re: Global PKI on DNS?
At 2:54 PM -0700 6/13/02, Einar Stefferud wrote: >At 2:15 PM -0400 6/13/02, Stephen Kent wrote: > >[snip]... [snip]... [snip]... [snip]... [snip]... [snip]... >[snip]... [snip]... >> >>You are the one who keeps saying that trust is transitive. I'm the >>one saying that it's not, and that a DNS-based PKI does not imply >>transitive trust. >> >>>constructive, or generally relevant to the topic ... >> >>Steve > >I am simply astounded. Where in my texts have I said that trust is >ever transitive. > >I asked on for an explanation of why some in this list think trust >is transitive. >And I cited the only instance I can think of where it might be >transitive by mutual agreement between a SPY and her handler! But >this is not to be construed as my "saying that trust is transitive." > >If you can find he message and the text where I state that trust is >transitive. please return the message to me so I can compare it with >the copy of it that I kept in my outgoing mail folder. > >For clarity, I will now more simply restate my QUESTION: > >Explain for me (and others here) how trust is ever transitive! > >That is what I am really driving at. I don't think you can prove it. Stef, I should have said that you are the one who keeps focusing on the question of whether trust is transitive, not that you said it was transitive. You keep trying to cast this as a debate about the transitivity of trust, and I keep saying that it is not. I made a slight type in my message, as you cited above. You keep ignoring what I have said about the irrelevance of trust in a PKI where CAs are authoritative for the data they bind into certs. As Tina Turner would have said, "What's trust got to do with it?" Steve
Re: Global PKI on DNS?
At 2:47 PM -0400 6/13/02, Keith Moore wrote: > > A modest, realistic ambition for a DNS-based PKI would be to improve >> the security of the binding between DNS entries and the associated >> machines > >yes, I think this is right. it eliminates some kinds of threats. but >it still doesn't guarantee that you're talking to the service you think >you're talking to. and that's a difficult distinction to communicate >to users. It is unlikely that we can ever create a system that ensures that every user is " talking to the service you think you're talking to" because users can make all sorts of mistakes in trying to express who they really want to talk to. That's why I think it makes sense to settle for a more modest aim, i.e., authenticating that you are connected to the entity registered with the DNS name that you asserted that you wanted to talk to. >that and putting this much trust in the registries makes them very >attractive targets. Which registries? DNS servers are already attractive targets. Absent other forms of strong authentication, we rely on the integrity of the DNS to ensure that we are talking to who we Steve
Re: Global PKI on DNS?
At 3:32 PM -0400 6/13/02, Harald Koch wrote: >Of all the gin joints in all the towns in all the world, Stephen Kent >had to walk into mine and say: >> >> Why does everyone keep thinking that explicit trust is an essential >> element of every PKI? > >If the reasonably intelligent, technically skilled persons in the IETF >can't "get it", what makes you think anyone else will? > The technical skill of most of the individuals in this debate is not in the area of security. Also, there has been a very big PR campaign for many years that was designed to cause people to equate explicit trust and PKIs, because those who funded the campaign were public CAs requiring such trust. That campaign has been effective in creating a perception among many folks, technical or not, intelligent or otherwise, and it is this perception that clouds this discussion, in large part. But, on any case, it is not necessary for everyone to "get it" for everyone to "use it." Steve
