From nobody Fri Aug 1 06:56:04 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B251A0025 for ; Fri, 1 Aug 2014 06:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55vM5JK8E_9f for ; Fri, 1 Aug 2014 06:56:02 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A5B1A0012 for ; Fri, 1 Aug 2014 06:56:02 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gl10so3214764lab.21 for ; Fri, 01 Aug 2014 06:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5vLV/zx4EFYMtgs6TOc3/C3DxNoOfwZ0Xoen9/hFGbQ=; b=ZDsjD2NPARDrNspavoFHeRoZt4d664ln7OKfOaFJaa3R/GdJ8vQOnTXpnKfrpMIjfI Mqfmrz2zRmaTeUpJL43coLdrOnSUwAkVUJC1GlwXUT416XytisFwPSkMpaHxYbXzz5hD dSethhdeiEpfRmQwORc7FUnVoGnN32x433stdqTAJ6GKDBxJvqPRMzZwqqbWaCPgSstS znaT1hMUkO0cVvmFYGiOKcSzPsh+rG3c/6BFiM4OhAFu18CN+TSN4eq5lIiOZGoCzpZ+ UeN2paQ2t6lCVMxfZ39P+qnaBZb5rO0I/vNia5X6JKT8uOyBsjsSwEi0FEKsGVjb9Mp8 Ionw== MIME-Version: 1.0 X-Received: by 10.152.245.171 with SMTP id xp11mr6111850lac.61.1406901360058; Fri, 01 Aug 2014 06:56:00 -0700 (PDT) Received: by 10.112.147.168 with HTTP; Fri, 1 Aug 2014 06:56:00 -0700 (PDT) Date: Fri, 1 Aug 2014 09:56:00 -0400 Message-ID: From: Kathleen Moriarty To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a11345e12cce47304ff91bf88 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/f3thgW3ETecbjTWYbXrCelud5W8 Subject: [saag] Off today X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 13:56:04 -0000 --001a11345e12cce47304ff91bf88 Content-Type: text/plain; charset=UTF-8 Hello, I am off today and will be offline for at least a portion of the day and will be offline completely tomorrow. Stephen is also out. I'll try to check email when I can today in case anything pops up that needs attention. -- Best regards, Kathleen --001a11345e12cce47304ff91bf88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I am off today and will be offli= ne for at least a portion of the day and will be offline completely tomorro= w. =C2=A0Stephen is also out. =C2=A0

I'll try to check email whe= n I can today in case anything pops up that needs attention.

--

Best regards,
Kat= hleen
--001a11345e12cce47304ff91bf88-- From nobody Sun Aug 3 08:14:43 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543FC1A0365; Sun, 3 Aug 2014 08:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lG9LvpL_vMNh; Sun, 3 Aug 2014 08:14:36 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED3BF1A0375; Sun, 3 Aug 2014 08:13:44 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 398D42AB2BD; Sun, 3 Aug 2014 15:13:43 +0000 (UTC) Date: Sun, 3 Aug 2014 15:13:43 +0000 From: Viktor Dukhovni To: ietf@ietf.org, saag Message-ID: <20140803151342.GI15044@mournblade.imrryr.org> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53D2D7F6.7080306@dcrocker.net> <53D9152D.80903@bbn.com> <20140730173114.GB15044@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140730173114.GB15044@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/0Dos9DYIczy_XV85OOvMoZwY-Ms Subject: Re: [saag] Last Call: (pushed -02 update) (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 15:14:41 -0000 On Wed, Jul 30, 2014 at 05:31:14PM +0000, Viktor Dukhovni wrote: > > "OS strives to greatly broaden the use of encryption in IETF protocols, > > to combat PM. To facilitate incremental deployment, OS operates in > > a fashion that may result in a plaintext connection/session." > > This is I think addressed by the "Encrypt by default" principle, > but perhaps the below change helps to get the point across: > > [...] That change and a few more are in the -02 version: A new version has been submitted for draft-dukhovni-opportunistic-security: http://www.ietf.org/internet-drafts/draft-dukhovni-opportunistic-security-02.txt Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-dukhovni-opportunistic-security-02 Summary of changes: - Replaced undefined "strong protection" with "protection against both passive and active attacks". - Moved Terminology section up between the Introduction and the Design Principles (body) section. - More references. - Split some run-on sentences. If anyone feels strongly that some of the original text was better, please speak up... -- Viktor. From nobody Tue Aug 5 11:14:34 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A1D1A008B for ; Tue, 5 Aug 2014 11:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5GqaCvdkDYR for ; Tue, 5 Aug 2014 11:14:23 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E2C1A0091 for ; Tue, 5 Aug 2014 11:14:20 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 617512AB0B4; Tue, 5 Aug 2014 18:14:19 +0000 (UTC) Date: Tue, 5 Aug 2014 18:14:19 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140805181419.GF15044@mournblade.imrryr.org> References: <53BFDC9A.5060307@iang.org> <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53E0FB86.7000803@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FQJ5r36aUniTqo-GMJe68pnYvvQ Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 18:14:29 -0000 On Tue, Aug 05, 2014 at 11:43:02AM -0400, Stephen Kent wrote: > The abstract uses the phrase "the established approach" to refer to > employing protection against passive and active attacks, or no protection at > all. Since opportunistic security (OS) is a term being defined for use in > IETF standards, a reader might interpret the phase in quotes as referring to > our standards, vs. deployment. While it is true that our security standards > generally try to address both active and passive attacks, offering no > protection at all is not a goal of these standards. The author should > rephrase the text to clarify whether he is discussing standards or > deployment. In the abstract, I think it is not essential to distinguish between goals and consequences. The abstract is not blaming anyone, and we do not need to apportion blame. One way or another, at present, the situation is as described. I am discussing the present state of the Internet, which results from a combination of standards and deployment, and it is not clear why additional precision is required here. > *Section 1* > > Despite the fact that the abstract says the memo defines OS, the intro does > not do so. A number of others have made this comment, both during the SAAG > discussion of the document and during IETF last call, but the author has > repeatedly ignored these comments. I suggest a definition of OS should > appear within this section. Since the document's goal is to define opportunistic security, rather than use such a definition to do something else, I felt it appropriate to offer motivating material in the Introduction, and the definition in the body of the draft. There seemed to be significant feedback supporting the document as-is. > The text says: > > Since protection against active attacks relies on authentication, which at > Internet scale is not universally available, while communications traffic > was sometimes strongly protected, more typically it was not protected at > all. > > This statement is in the past tense, but the situation described is present > tense. The use of the past tense here may confuse readers, causing them to > believe that the problem described is in the past. The tense mismatch should probably be fixed at the next opportunity to revise the document, thanks. > More importantly, the > phrase "at Internet scale" is not defined anywhere in the document, yet it > is a recurring theme in the document. I don't think anyone is likely to be confused about what "Internet-scale" means. Nor is it essential that their interpretation of the phrase match mine. > The text later says: > > ... with encrypted transmission accessible to most if not all peers, and > protection against active attacks still available where required by policy > or opportunistically negotiated. > > Our current security protocols offer protection against active attacks > "where required by policy" (e.g., IPsec) so this text is misleading, again. The above quote leaves out essential context: Indiscriminate collection of communications traffic would be substantially less attractive if security protocols were designed to operate at a range of protection levels; with encrypted transmission accessible to most if not all peers, and protection against active attacks still available where required by policy or opportunistically negotiated. In this context, the discussion of designs that operate at a *range* of protection levels, with encryption ubiquitous and stronger protection used where appropriate, thus a *range* of protection levels. > And the term "opportunistically negotiated" is not defined, so it's use here > adds to the confusion. When protection against active attacks is not unconditional policy, a party that strives to maximize security might "discover" (say via presence of DANE TLSA RRs) that its peers can in fact be authenticated, and thus employ the appropriate measures to thwart active attacks. This is an instance of opportunistic security that goes beyond unauthenticated encryption. Likely the below would be an improvement: Indiscriminate collection of communications traffic would be substantially less attractive if security protocols were designed to operate at a range of protection levels; with encrypted transmission accessible to most if not all peers, and protection against active attacks still employed where unconditionally required by policy or else discovered to be possible with a given peer. > The next paragraph refers to key management, again at "Internet scale" > without definition or explanation. I'm pretty sure the author intends to > refer to "authenticated" key management, at a specific (but unstated) > granularity of authentication. The ambiguity of "Key Management" has already been discussed separately. I think the text is sufficient as-is. Overly precise definitions require more ink on side-issues which distract from the main goal of the document. > The bottom line is that a primary > motivation for OS is a desire to remove barriers to the use of encryption, More strongly: * Yes at least encrypt when possible, but more generally, * Avoid needlessly weak options, and finally, * Strive for stronger security than just unauthenticated encryption, with any peer for which this is possible. Do no forget that during the saag discussion that preceded this draft, this was one of the main differences between our views, and that I do not subscribe to the view that opportunistic security is a narrow response to PM or that it should be limited to promoting just unauthenticated encryption. > and removing the need for authentication based on certificates is a good way > to do this. Not "removing", rather "not requiring". We lower the floor, but not the ceiling of the range of acceptable protections. > But, this simple statement appears nowhere in this document. > (DANE is cited later in this paragraph, but is dismissed because DNSSEC is > not yet widely deployed. This is an accurate statement, but the say it is > presented fails to convey the fundamental issues at play here.) That's because the simple statement in question over-emphasizes lowering the floor, and leaves the treatment of the ceiling unaddressed. Instead the draft's design principles are: * Interoperate to maximize deployment. * Maximize security peer by peer. * Encrypt by default. * No misrepresentation of security. The second and third of these both explain that unauthenticated encryption may well be the best available, and should be employed when that is the case. > The second paragraph in this section says: > > The PKIX ([RFC5280]) key management model, which is based on broadly trusted > public certification authorities (CAs), introduces costs that not all peers > are willing to bear. > > This is another example of inaccurate terminology that engenders confusion. > I believe the author meant to refer to the Web PKI CA model (currently being > documented in the WPKOPS WG), not to RFC 5280. Subsequent references to PKIX > should be removed whenever they are not specifically tied to PKIX RFCs. I am not alone in conflating the PKIX standards with their deployed infrastructure. Here again higher precision is I think not essential, however we can avoid the problem cheaply enough: Encryption is easy, but key management is difficult. Key management at Internet scale remains an incompletely solved problem. The Web PKI key management model, which is based on broadly trusted public certification authorities (CAs), introduces costs that not all peers are willing to bear. Web PKI public CAs are not sufficient to secure communications when the peer reference identity ([RFC6125]) is obtained indirectly over an insecure channel or communicating parties don't agree on a mutually trusted CA. by replacing PKIX with "Web PKI" if that is better. > The second paragraph of this section is trying to explain why extant means > of key management systems (that are used in the Internet today), do not meet > the author's goal of Internet scale key management. This is an example of > the author avoiding the task of creating a definition, and instead relying > on a set of examples to convey meaning. This is a bad strategy for an RFC. The RFC is informational (even aspirational), and the introductory text is informal motivating background. Simplicity and accessibility are prioritized over precision where precision imposes a cost on the complexity of the document. Perhaps the trade-off is not quite right in some places, I welcome further feedback on that point. > When authenticated communication is not possible, unauthenticated encryption > is still substantially stronger than cleartext. > > This would be better stated as: > > When authenticated communication is not possible, unauthenticated encryption > is preferable to cleartext transmission, relative to the concerns identified > in [RFC7258]. This is fine by me. Anyone else care to comment? > The section ends with another observation about OS, without defining it: > > In particular, opportunistic security encourages > unauthenticated encryption when authentication is not an option. > > This is a fine statement, that would be appropriate if only a definition of > OS had preceded it. The definition is in the body of the document, not the Introduction. > *Section 3* > > This section describes the author's design philosophy for OS, which would be > appropriate IF OS had already need defined! Ditto. > The first goal says: > > The primary goal of designs that feature opportunistic security is to be > able to communicate with any reasonably configured peer. > > I'm pretty sure that, given the vagueness of the phrase "reasonably > configured peer:" that this is a goal of ALL IETF protocol standards. > Perhaps the author meat to say that the goal is to maximize the ability of > communicating peers to encrypt their traffic. No, the point here is that opportunistic security is first and foremost not a barrier to communicating. Security takes a back seat to moving the bits, provided none of the peers are misconfigured. I can replace the word "reasonably" with "correctly" if that is less confusing. This is reiterated in the final sentence: Opportunistic security must not get in the way of the peers communicating if neither end is misconfigured. What is different here from extant security protocols is the relative priority of security and interoperability. With OS interoperability is generally prioritized over security, when all peers are properly configured (possibly to offer only weak or no security services). However, when peers are advertising (say via DANE) particular security services, then OS is expected to demand that the peer delivers on its promise (peers that promise, but don't deliver are misconfigured). > The text then says: > > If many peers are only capable of cleartext, then it is acceptable to fall > back to cleartext when encryption is not possible. > > The term "many" here is misleading, unless this is referring primarily to > some multicast scenario. Perhaps the author meant to say: Many as in a non-negligible fraction of potential peers as with legacy applications or infrastructure. Not "many" as in multicast. I'll change the text to: If a non-negligible number of potential peers are only capable of cleartext, then it is acceptable to fall back to cleartext when encryption is not possible. if there are no objections to that. > If a peer is not OS-capable, then an attempt to initiate unauthenticated, > encryption communication may fail. In that case, plaintext communication is > an acceptable outcome. No, "OS-capable" is not a synonym for "Encryption-capable". The two are quite distinct. > The text then says: > > Interoperability must be possible without a need for the administrators of > communicating systems to coordinate security settings. This is borne of a decade of experience with exactly such bilateral administrator interactions when setting up Web PKI secure channels for SMTP. The parties need to agree on which CAs to employ and what names to validate at the peer domain's MX hosts. > This is an important principle but the phrase "security settings" is a bit > vague. Does this really need elaboration? The real point is that OS can be deployed organically with any prior bilateral coordination between the communicating parties. Perhaps I should add the word "prior": Interoperability must be possible without a prior need for the administrators of communicating systems to coordinate security settings. > But, for TLS, is configuration of a mutually > acceptable set of cryptographic algorithms a problem? Yes, though not algorithms, rather trusted CAs and in the case of SMTP also reference identities, since MX indirection makes the natural reference identities insecure. > I think this statement > implies a mandatory to implement set of cryptographic algorithms that will > be part of OS standards (else coordination will be needed to ensure > overlap). Yes, security protocol designs (OS or otherwise) need to interoperate by default, but in the case of OS, the need to not get in the way of communication is even more important, because security is secondary. > Also, because this statement appears after the comment on > authentication as a part of OS (if possible) it opens up the question of > whether the security settings refer just to encryption or also to > authentication. The text needs to be clearer on this. Both, but most of the historical friction is with authentication. > Applications employing opportunistic security need to be deployable at > Internet scale, with each peer independently configured to meet its own > security needs (within the practical bounds of the application protocol). > > This wording suggests that use of OS is tied to an application. The TCPINC WG > is working on what they view as an OS-motivated change to TCP that would not > change the TCP API. An application would not be aware of encryption provided > at that layer. Does the author intend to rule out a TCP-based OS approach? > If not, the this text needs to be fixed, and the fix may not be easy. I can drop the word "application" if that is an improvement. There is no intention to specify the protocol layer in question to be an "application" protocol. > The description of the first goal ends with this statement: > > Opportunistic security must not get in the way of the peers communicating if > neither end is misconfigured. > > Surely we can state this intent more clearly, especially since what > constitutes "misconfiguration" of a peer is not described anywhere in this > document. Misconfiguration here means promising (publishing or negotiating) security services that are not available or don't work correctly. How about: Opportunistic security must not get in the way of the peers communicating if neither end is misconfigured (i.e., neither publishes or negotiates security services that are not available or don't function correctly). > The next goal states: > > Subject to the above Internet-scale interoperability goal, opportunistic > security strives to maximize security based on the capabilities of the peer > (or peers). > > The last three words are confusing. If we assume that communication involves > at least two parties, then the capability of the peers trying to engage in > communication is what matters. > > Change "peer (or peers)" to "peers". OK. > The text then says: > > For others, protection against active MiTM attacks may be an option. > > An MiTM attack is ALWAYS active, so the wording here is redundant, and thus > potentially confusing. I thought it was reasonable emphasis, but I can drop MiTM here if preferred. > The text then says: > > Opportunistic security protocols may at times refuse to operate with peers > for which higher security is expected, but for some reason not achieved. > > There is a subtle issue at play here. It suggests that a protocol that is > deemed an example of OS might require security services beyond > confidentiality, e.g., authentication. Yes, absolutely. This is one of the main reasons why I wrote an alternative draft. Not only might this happen, I am recommending that OS designs support authentication when possible (peer by peer). > This seems to contradict the notion > that an OS protocol require no coordination between administrators to enable > communication, as stated in the first goal. No contradiction at all. Administrator Bob publishes DANE TLSA RRs. Administrator Alice independently (before or after Bob's action) enables DANE TLSA support. When both are done Alice's traffic to Bob is authenticated and encrypted. > Also, the phrase "at times" is > misleading, unless it is intended to suggest that inconsistent behavior > between the same set of peers, perhaps based on time of day, is OK. At times, depends on the peers, and their published capabilities at the times in question, not just the time of day. However, it may be better to say "in some cases". > The description of this goal ends with the following text: > > The conditions under which connections fail should generally be limited to > operational errors at one or the other peer or an active attack, so that > well-maintained systems rarely encounter problems in normal use of > opportunistic security. > > This sentence immediately follows the discussion of refusing to communicate > when peers have differing requirements for security services. It is > confusing, as it appears to ignore the scenario described in that sentence. The two sentences go together. Though active attack protection may block communication, this should only happen when under attack, or when someone botches their configuration. > The next goal, encryption by default, begins with a strong statement, that > is muddled by the choice of words: > > An opportunistic security protocol MUST interoperably achieve at least > unauthenticated encryption between peer systems that don't explicitly > disable this capability. > > Perhaps the author meant to say: > > If two peer systems make use of the same OS protocol, they MUST, at a > minimum, establish unauthenticated, encrypted communication when they > connect, unless either has explicitly disabled this capability. How is this different or better? > Still, this simpler statement would conflict with the prior goal of allowing > a system to reject unauthenticated communication with a peer, e.g., because > it require use of additional security services. This needs to be reconciled > with prior goals. No conflict. This discusses the floor case of *at least* unauthenticated encryption. The other text is about the ceiling case of authenticated encryption when possible. > The text then says: > > Over time, as peer software is updated to support opportunistic security, > only legacy systems or a minority of systems where encryption is disabled > should be communicating in cleartext. > > This seems to ignore the possibility that an active attack might prevent > peers from enabling OS, even though they are both capable. The word "should" allows for some exceptions, such as an occasional active attack. > The description of this goal ends with a mention of PFS. This is out of > place in this definition. It should appear elsewhere. Why is it wrong to encourage the encrypt by default goal to use PFS? Your own draft made PFS a central goal of OS. Must this be a separate design principle? Why? > The next goal starts by using the undefined phrase "strong security". > Several others have suggested that this phrase be removed from the I-D, and > I concur. If the author wants to use the phrase, it must be defined in > section 2. It is largely gone, now in just two places, otherwise mostly replaced by "protection against both passive and active attacks" or similar language. Now in this paragraph we're talking about *representation* to users, and here I see few better alternatives. On UI issues "strategic ambiguity" that gets the point across is important. > The penultimate paragraph in this section finally offers a definition for > OS. This needs to be moved near the beginning of this document. I still prefer to defer the definition until after the Introductory material that motivates its and the design principles that it summarizes and which are a core part of the definition. > The word > "actual" should be elided from the second sentence of the definition. The > definition ends with: Given unequal security policy floors and security policy ceilings, actual protection may differ from minimum required or maximum available. > ... while allowing fallback to cleartext with peers that do not appear to be > encryption capable. > > Change "encryption capable" to OS-capable or "OS-enabled". The peer may not be OS-capable, but may still support encryption. The cleartext fallback is for lack of encryption support. > The final paragraph in this section says: > > When possible, opportunistic security SHOULD provide stronger security on a > peer-by-peer basis. > > This is an obvious attempt to make the definition of OS be very broad, Not "obvious attempt", but rather clear and multiply stated goal of the draft. And as mentioned earlier a clear point of difference during the saag discussion, and the key reason this draft exists. > well beyond the primary goal cited earlier. No, exactly as intended and stated. > It also conflicts with the goal of > not requiring coordinated security configuration between peers, another goal > cited earlier. No conflict. See DANE Alice/Bob example above. > The last sentence in the section appears > to be the authors per peeve, and probably does not belong in this document. It clearly illustrates much of what is wrong with the status quo and how OS can make things better. The blunder in question is rather common, and even if the draft achieves nothing beyond discouraging such blunders, that would progress. > The use of "MUST" here is also questionable, as it is stated w/o explicit > context. (The author did not say, for example, that this behavior in an > OS-capable MTA violates the criteria established for OS.) This blunder MUST be avoided in any MTA, OS or otherwise, but an appreciation for the fact that the MTA in question is in fact engaging in OS (by falling back from authenticated transmission), and making a botch of it (by falling back to cleartext instead of continuing the encrypted session) is helpful. > *Section 4* > > Again there is use of the phrase "strong security" which is problematic for > the reasons cited above. I think by this point it is understood what this means given all the earlier text. If necessary, it can be made more verbose as in most of the other cases. > *Section 6* > > The references are not described as informative vs. normative. The draft is informational, so I thought this was not essential. If the separation is none-the-less important, that's an easy fix. -- Viktor. From nobody Tue Aug 5 14:04:42 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96E31B2BCC; Tue, 5 Aug 2014 14:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlb2sP855-6x; Tue, 5 Aug 2014 14:04:36 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D82EB1B2BC7; Tue, 5 Aug 2014 14:04:36 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id B8BAF67C072; Tue, 5 Aug 2014 14:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=ORxF0aQi7+hqj5to2w1J6O+3dhE =; b=tHBc5epwG2YllaLikmFxQBTIe6/7KG4dMI31lF/+HiwsGe6Yy79bgf36Laz Lj0F/ud3LMRtE7jypF/9f6UqYL+i0QBdAL6Xy3oj5kpQEKknnlztl1RCWomtEMuW iAWyFsDNHAMUW0pZJHobNCwA6fwZzQnW78dMj+h5/znonFag= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPA id 73FDC67C056; Tue, 5 Aug 2014 14:04:36 -0700 (PDT) Date: Tue, 5 Aug 2014 16:04:35 -0500 From: Nico Williams To: saag@ietf.org, ietf@ietf.org Message-ID: <20140805210434.GB23449@localhost> References: <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140805181419.GF15044@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/9RpPGhNOZVA8xyUyrxU7oe-IgmM Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 21:04:39 -0000 On Tue, Aug 05, 2014 at 06:14:19PM +0000, Viktor Dukhovni wrote: > On Tue, Aug 05, 2014 at 11:43:02AM -0400, Stephen Kent wrote: > > The bottom line is that a primary > > motivation for OS is a desire to remove barriers to the use of encryption, > > More strongly: > > * Yes at least encrypt when possible, but more generally, > * Avoid needlessly weak options, and finally, > * Strive for stronger security than just unauthenticated encryption, > with any peer for which this is possible. Yes. To be more specific OS must not preclude things like DANE that can be opportunistic and provide strong authentication. It's worth mentioning DNSSEC/DANE because a lot of concerns I've seen stated about OS (indeed, that I myself have stated) go away when one considers the use of DNSSEC for learning how to authenticate a service. (Or, perhaps, such concerns get transmutated into concerns about the lack of compromised/adversarial parent zone MITM detection in DNSSEC.) > Do no forget that during the saag discussion that preceded this > draft, this was one of the main differences between our views, and > that I do not subscribe to the view that opportunistic security is > a narrow response to PM or that it should be limited to promoting > just unauthenticated encryption. More than that: why should OS stop there? > > and removing the need for authentication based on certificates is a good way > > to do this. > > Not "removing", rather "not requiring". We lower the floor, > but not the ceiling of the range of acceptable protections. More +1. And, really, +1 to the rest of Viktor's response. Nico -- From nobody Tue Aug 5 16:41:38 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467721A0339 for ; Tue, 5 Aug 2014 16:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqkSOJtaq15y for ; Tue, 5 Aug 2014 16:41:34 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01C141A036C for ; Tue, 5 Aug 2014 16:41:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 33C22E04C; Tue, 5 Aug 2014 19:41:31 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GgDjcfr1uwb; Tue, 5 Aug 2014 19:41:29 -0400 (EDT) Received: from [192.168.3.137] (71-80-163-186.static.lsan.ca.charter.com [71.80.163.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id EDEA9E056; Tue, 5 Aug 2014 19:41:28 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_94A14731-2F0A-4B1D-89E7-8639A080FE42" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Henry B Hotz In-Reply-To: <53D6C902.50200@iang.org> Date: Tue, 5 Aug 2014 16:41:27 -0700 Message-Id: References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BFDC9A.5060307@iang.org> <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> To: ianG X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/wPNinwhAzHFeEjCiSxXcqN7RUJ8 Cc: saag@ietf.org Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 23:41:36 -0000 --Apple-Mail=_94A14731-2F0A-4B1D-89E7-8639A080FE42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 Can we do clearer text with this as a starting point? On Jul 28, 2014, at 3:04 PM, ianG wrote: > Instead we want to change the paradigm. We want to lift the bar to = the > height that the jumper can leap, not filter the jumper by the height = of > the bar, set arbitrarily high. Conceptually, we may be doing nothing more than pre-empting the = existing/default mechanism selection order for a protocol. Personal email. hbhotz@oxy.edu --Apple-Mail=_94A14731-2F0A-4B1D-89E7-8639A080FE42 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii iang@iang.org> wrote:
Instead we want to change the = paradigm.  We want to lift the bar to the
the bar, set arbitrarily = high.
Personal = email.  hbhotz@oxy.edu



= --Apple-Mail=_94A14731-2F0A-4B1D-89E7-8639A080FE42-- From nobody Tue Aug 5 17:17:43 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6225E1A03FD for ; Tue, 5 Aug 2014 17:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xRTA752Yxkz for ; Tue, 5 Aug 2014 17:17:40 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ED171A03FA for ; Tue, 5 Aug 2014 17:17:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2C4262AB0B4; Wed, 6 Aug 2014 00:17:38 +0000 (UTC) Date: Wed, 6 Aug 2014 00:17:38 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140806001737.GM15044@mournblade.imrryr.org> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BE6765.5080902@iang.org> <53BFDC9A.5060307@iang.org> <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/mNYJn6gzyen_lMqVslu-ebsIi8o Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 00:17:42 -0000 On Tue, Aug 05, 2014 at 04:41:27PM -0700, Henry B Hotz wrote: > +1 > > Can we do clearer text with this as a starting point? The draft already says this with different words, and (to stretch the analogy) with additional emphasis that the bar should be set higher when the jumper assures everyone he can clear that height. > On Jul 28, 2014, at 3:04 PM, ianG wrote: > > > Instead we want to change the paradigm. We want to lift the bar to the > > height that the jumper can leap, not filter the jumper by the height of > > the bar, set arbitrarily high. We are prioritizing success over absolute security, but trying to get as much security as possible while leaving room for non-trivial minimum standards where appropriate (local policy or securely published peer capabilities, ...). So I do not disagree with the substance of above alternative language, but don't see a need for a restart to say the same thing. > Conceptually, we may be doing nothing more than pre-empting the > existing/default mechanism selection order for a protocol. There's likely to be a lot more going on than that. New DNSSEC lookups, outcome dependent initial policy selection, then further adaptation based on direct communication with the peer, ... -- Viktor. From nobody Tue Aug 5 18:07:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49371A04E7; Tue, 5 Aug 2014 18:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PK2VKQYm8Lgj; Tue, 5 Aug 2014 18:07:13 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1001A0515; Tue, 5 Aug 2014 18:07:09 -0700 (PDT) Received: from [10.251.200.130] ([69.162.16.14]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s76173ep004869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 Aug 2014 18:07:07 -0700 Message-ID: <53E17F34.9090804@dcrocker.net> Date: Tue, 05 Aug 2014 18:04:52 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nico Williams , saag@ietf.org, ietf@ietf.org References: <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> In-Reply-To: <20140805210434.GB23449@localhost> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 05 Aug 2014 18:07:07 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/3M__lh8sFuzeXYXhpoB9O2N1UHo Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 01:07:15 -0000 On 8/5/2014 2:04 PM, Nico Williams wrote: > To be more specific OS must not preclude things like DANE that can be > opportunistic and provide strong authentication. A reference like that has been made several times, and I don't understand it. DANE provides authenticated keys. Given the reliance on DNSSec, the authentication is substantial. So while use of DANE has some interesting differences from using a classic CA-based key, using it as a basis for encryption ought to qualify as fairly straightforward authenticated encryption. That doesn't seem at all 'opportunistic' to me. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Aug 5 18:27:11 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F6B1A0645; Tue, 5 Aug 2014 18:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDAoCmkL885l; Tue, 5 Aug 2014 18:27:08 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148A61A034B; Tue, 5 Aug 2014 18:27:08 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2CB942AB0B4; Wed, 6 Aug 2014 01:27:07 +0000 (UTC) Date: Wed, 6 Aug 2014 01:27:07 +0000 From: Viktor Dukhovni To: saag@ietf.org, ietf@ietf.org Message-ID: <20140806012706.GN15044@mournblade.imrryr.org> References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53E17F34.9090804@dcrocker.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/yte0Y9t-0iw8J3NUsJNPBHKqKyc Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 01:27:10 -0000 On Tue, Aug 05, 2014 at 06:04:52PM -0700, Dave Crocker wrote: > So while use of DANE has some interesting differences from using a > classic CA-based key, using it as a basis for encryption ought to > qualify as fairly straightforward authenticated encryption. > > That doesn't seem at all 'opportunistic' to me. It is when authentication is then used *only* with peers that publish TLSA RRs and not with peers that don't. You get opportunistic authentication, which is employed when possible (or at least promised by the peer system's DNS administrator) and not otherwise. See: https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-11 -- Viktor. From nobody Tue Aug 5 19:28:37 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C891A0AEB; Tue, 5 Aug 2014 19:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DxiLEOg8a5d; Tue, 5 Aug 2014 19:28:33 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5C11A0AE4; Tue, 5 Aug 2014 19:28:33 -0700 (PDT) Received: from [10.251.200.130] ([69.162.16.14]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s762SLQS009879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 Aug 2014 19:28:33 -0700 Message-ID: <53E19242.5030208@dcrocker.net> Date: Tue, 05 Aug 2014 19:26:10 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> In-Reply-To: <20140806012706.GN15044@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 05 Aug 2014 19:28:33 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/leRwuxBsXx2BjlWW-rWTPdatdeM Cc: ietf@ietf.org Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 02:28:35 -0000 On 8/5/2014 6:27 PM, Viktor Dukhovni wrote: > It is when authentication is then used *only* with peers that > publish TLSA RRs and not with peers that don't. My point was/is that reliance on DNSSec means that there is an INDEPENDENT authentication hierarchy. Taking a look at the entire 'system' that DANE is part of, the authentication is NOT only between peers. Use DANE without DNSSec, and calling it opportunistic probably makes sense. Using it with DNSSec and it doesn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Aug 5 19:55:41 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C201A0B05; Tue, 5 Aug 2014 19:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI3NQd2jA8WT; Tue, 5 Aug 2014 19:55:38 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E319A1A0AFB; Tue, 5 Aug 2014 19:55:37 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CFBCB2AB0B4; Wed, 6 Aug 2014 02:55:36 +0000 (UTC) Date: Wed, 6 Aug 2014 02:55:36 +0000 From: Viktor Dukhovni To: ietf@ietf.org, saag@ietf.org Message-ID: <20140806025536.GO15044@mournblade.imrryr.org> References: <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53E19242.5030208@dcrocker.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/RUsbnorDfL0e70kWAQy0VY_fpZU Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 02:55:39 -0000 On Tue, Aug 05, 2014 at 07:26:10PM -0700, Dave Crocker wrote: > On 8/5/2014 6:27 PM, Viktor Dukhovni wrote: > > It is when authentication is then used *only* with peers that > > publish TLSA RRs and not with peers that don't. > > > My point was/is that reliance on DNSSec means that there is an > INDEPENDENT authentication hierarchy. > > Taking a look at the entire 'system' that DANE is part of, the > authentication is NOT only between peers. > > Use DANE without DNSSec, and calling it opportunistic probably makes > sense. Using it with DNSSec and it doesn't. We'll have to disagree on this. From the perspective of an MTA delivering mail to all possible domains, its security policy is opportunistic, doing the best it can with each destination. When DANE support is enabled, it becomes possible to authenticate some peers, this is still opportunistic security, with the bar set to the right level for each peer, and mail delivery in cleartext should a previously DANE-enabled domain withdraw its TLSA RRs, ... If opportunistic security is mutually exclusive with protection against active attacks, it is a step sideways not forward. I am proposing to make encryption more ubiquitous *without* lowering the achievable security. I believe I have strong support for this in this forum (both saag and ietf general). For SMTP, the resulting protocol is "opportunistic DANE TLS", which is an example of an "opportunistic security" design. You're bringing baggage to this discussion in the form of assumptions about what opportunistic security means. The draft proposes a more ambitious definition. -- Viktor. From nobody Tue Aug 5 20:01:09 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF661B2794; Tue, 5 Aug 2014 20:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfcrteu7CCa9; Tue, 5 Aug 2014 20:01:06 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4531A0B11; Tue, 5 Aug 2014 20:01:06 -0700 (PDT) Received: from [10.251.200.130] ([69.162.16.14]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s763129k010381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 Aug 2014 20:01:06 -0700 Message-ID: <53E199EB.8070403@dcrocker.net> Date: Tue, 05 Aug 2014 19:58:51 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org, ietf@ietf.org References: <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <20140806025536.GO15044@mournblade.imrryr.org> In-Reply-To: <20140806025536.GO15044@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 05 Aug 2014 20:01:06 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/tg4C-5MLcLEvvrmkK0OFBNa4luw Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 03:01:08 -0000 On 8/5/2014 7:55 PM, Viktor Dukhovni wrote: > We'll have to disagree on this. From the perspective of an MTA > delivering mail to all possible domains, its security policy is > opportunistic, doing the best it can with each destination. When > DANE support is enabled, it becomes possible to authenticate some > peers, this is still opportunistic security, with the bar set to > the right level for each peer, and mail delivery in cleartext should > a previously DANE-enabled domain withdraw its TLSA RRs, ... I've read the above several times but do not really understand what it means. Also the issue is not whether we agree but what the technical details are that qualify this as "opportunistic" rather than authenticated encryption that happens to use DNSSec as a form of CA. For a term to be useful, there must be a clear and consistent way of applying it. The exchange we are having right now makes the meaning -- and therefore utility -- of opportunisitc (foo) -- questionable. It is simply not useful to have such a basic assessment reduce to "we'll have to disagree"... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Aug 5 20:16:47 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59DC1B2A6C; Tue, 5 Aug 2014 20:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E03NZLww5_ty; Tue, 5 Aug 2014 20:16:41 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85651B2C2D; Tue, 5 Aug 2014 20:16:23 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0BC142AB0B4; Wed, 6 Aug 2014 03:16:23 +0000 (UTC) Date: Wed, 6 Aug 2014 03:16:22 +0000 From: Viktor Dukhovni To: saag@ietf.org, ietf@ietf.org Message-ID: <20140806031622.GP15044@mournblade.imrryr.org> References: <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <20140806025536.GO15044@mournblade.imrryr.org> <53E199EB.8070403@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53E199EB.8070403@dcrocker.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/GOz-gOzjjvbmC3k7hDLMaBBT6l8 Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 03:16:44 -0000 On Tue, Aug 05, 2014 at 07:58:51PM -0700, Dave Crocker wrote: > On 8/5/2014 7:55 PM, Viktor Dukhovni wrote: > > We'll have to disagree on this. From the perspective of an MTA > > delivering mail to all possible domains, its security policy is > > opportunistic, doing the best it can with each destination. When > > DANE support is enabled, it becomes possible to authenticate some > > peers, this is still opportunistic security, with the bar set to > > the right level for each peer, and mail delivery in cleartext should > > a previously DANE-enabled domain withdraw its TLSA RRs, ... > > I've read the above several times but do not really understand what it > means. DANE with authentication can be either opportunistic (enabled via discovery on a peer by peer basis) or mandatory (required by local policy, URI scheme, ...). Postfix for example supports both opportunistic and mandatory DANE TLS: http://www.postfix.org/TLS_README.html#client_tls_dane > Also the issue is not whether we agree but what the technical details > are that qualify this as "opportunistic" rather than authenticated > encryption that happens to use DNSSec as a form of CA. The term "opportunistic security" is new, and can be defined, within reason, as we see fit. The proposed definition includes authentication that is based on published peer capabilities (discovered authentication support) under the umbrella term of opportunistic security, and rightly so. > For a term to be useful, there must be a clear and consistent way of > applying it. Opportunistic peers are willing to set the bar at various levels depending on peer capabilities. They don't operate at a single fixed (all or nothing) security policy. Publication of TLSA RRs (for example) is one way of signalling a higher bar for a particular peer, STARTTLS is another (though not as high, and not immune to active attack). > The exchange we are having right now makes the meaning -- and therefore > utility -- of opportunistic (foo) -- questionable. It is simply not > useful to have such a basic assessment reduce to "we'll have to disagree"... Perhaps I said that wrong, I did not mean to shut down the conversation, however, I am more than willing to clarify my stance on a definition that ranges from cleartext to authenticated encrypted comms that resist both passive and active attacks. I think we are well past the point where I need to consider substantively narrower definitions. We can certainly debate the clarity and wording of the text. -- Viktor. From nobody Tue Aug 5 20:22:39 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A9A1B2C3B; Tue, 5 Aug 2014 20:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ON9G1AFdkex; Tue, 5 Aug 2014 20:22:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257431B2C3A; Tue, 5 Aug 2014 20:22:35 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7FB3C2AB0B4; Wed, 6 Aug 2014 03:22:34 +0000 (UTC) Date: Wed, 6 Aug 2014 03:22:34 +0000 From: Viktor Dukhovni To: ietf@ietf.org Message-ID: <20140806032233.GQ15044@mournblade.imrryr.org> References: <53DA9B74.8040706@bbn.com> <20140806025536.GO15044@mournblade.imrryr.org> <53E199EB.8070403@dcrocker.net> <1602527.XOcXWRByOV@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1602527.XOcXWRByOV@scott-latitude-e6320> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zm2hzBXVUbfEERmFgNhfWfZIM7o Cc: saag@ietf.org Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ietf@ietf.org, saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 03:22:36 -0000 On Tue, Aug 05, 2014 at 11:14:27PM -0400, Scott Kitterman wrote: > > For a term to be useful, there must be a clear and consistent way of > > applying it. > > > > The exchange we are having right now makes the meaning -- and therefore > > utility -- of opportunistic (foo) -- questionable. It is simply not > > useful to have such a basic assessment reduce to "we'll have to disagree"... > > It seems to me that all it means is that the MTA is taking the opportunity > to make the most secure connection it can on a peer basis. Sometimes that's > going to be a full DANE negotiated session protected by DNSSEC. Other > times it's not. I think the major point of opportunistic isn't how good > the resulting security is, but the idea of taking advantage of the best > option available on a per peer basis rather than treating it as all or > nothing. Exactly. Opportunistic security operates at a variable protection level, not fixed by a-priori policy. Rather, it is tuned to the apparent capabilities of the peer. Some appearances are not downgrade resistant (enabling active downgrade attacks), and some don't reflect reality (breaking interoperability when the peer promises more than it can deliver). -- Viktor. From nobody Tue Aug 5 21:28:53 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BA91B27FB; Tue, 5 Aug 2014 21:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgpHfecC4xWw; Tue, 5 Aug 2014 21:28:45 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE8E1B27D4; Tue, 5 Aug 2014 21:28:45 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 885AC2AB219; Wed, 6 Aug 2014 04:28:43 +0000 (UTC) Date: Wed, 6 Aug 2014 04:28:43 +0000 From: Viktor Dukhovni To: ietf@ietf.org Message-ID: <20140806042843.GS15044@mournblade.imrryr.org> References: <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140805181313.GE15044@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/td2Qw2SYzmYHcd1W-73N9hlVrzE Cc: saag@ietf.org Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ietf@ietf.org, saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 04:28:48 -0000 Proposed wording updates to address some of Steve Kent's comments (plus one or two minor other fixes). Note, this is not a major rewrite or restructuring. Just nit fixes. diff --git a/draft-dukhovni-opportunistic-security b/draft-dukhovni-opportunistic-security index ff29c55..c3ff1a3 100644 --- a/draft-dukhovni-opportunistic-security +++ b/draft-dukhovni-opportunistic-security @@ -55,7 +55,7 @@ comprehensive protection against both passive and active attacks - for peers capable and motivated to absorb the associated costs. + for peers able and motivated to absorb the associated costs. Since protection against active attacks relies on authentication, which at Internet scale is not universally available, while - communications traffic was sometimes strongly protected, more - typically it was not protected at all. The fact that most + communications traffic is sometimes strongly protected, more + typically it is not protected at all. The fact that most traffic is unprotected facilitates nation-state pervasive @@ -67,4 +67,4 @@ accessible to most if not all peers, and protection against - active attacks still available where required by policy or - opportunistically negotiated. + active attacks still employed where unconditionally required + by policy or else discovered to be possible with a given peer. @@ -74,10 +74,10 @@ management at Internet scale remains an incompletely solved - problem. The PKIX () key management + problem. The Web PKI key management model, which is based on broadly trusted public certification authorities (CAs), introduces costs that not all peers are - willing to bear. PKIX is not sufficient to secure communications + willing to bear. Web PKI public CAs are not sufficient to secure communications when the peer reference identity () is obtained indirectly over an insecure channel or communicating - parties don't agree on a mutually trusted CA. DNSSEC () is not at this time sufficiently widely + parties don't agree on a mutually trusted CA. At this time, + DNSSEC () is not sufficiently widely adopted to make DANE () a viable @@ -93,3 +93,3 @@ When protocols only offer the options of authenticated secure - channels or else cleartext, most traffic is sent in the clear. + channels or cleartext, most traffic is sent in the clear. Therefore, in order to make encryption more ubiquitous, @@ -97,5 +97,6 @@ communication is not possible, unauthenticated encryption is - still substantially stronger than cleartext. Opportunistic + preferable to cleartext transmission, in that it addresses + pervasive monitoring . Opportunistic security encourages peers to employ as much security as possible, - without falling back to unnecessarily weak options. In + without falling back on unnecessarily weak options. In particular, opportunistic security encourages unauthenticated @@ -159,4 +160,5 @@ goal of designs that feature opportunistic security is to be - able to communicate with any reasonably configured peer. If - many peers are only capable of cleartext, then it is acceptable + able to communicate with any correctly configured peer. If a + non-negligible number of potential peers are only capable of + cleartext, then it is acceptable to fall back to cleartext when encryption is not possible. If @@ -164,10 +166,12 @@ acceptable to authenticate only those peers and not the rest. - Interoperability must be possible without a need for the + Interoperability must be possible without a prior need for the administrators of communicating systems to coordinate security - settings. Applications employing opportunistic security need + policy. Applications employing opportunistic security need to be deployable at Internet scale, with each peer independently configured to meet its own security needs (within the practical - bounds of the application protocol). Opportunistic security + bounds of the employed protocol). Opportunistic security must not get in the way of the peers communicating if neither - end is misconfigured. + end is misconfigured (i.e., neither publishes or negotiates + security services that are not available or don't function + correctly). @@ -176,7 +180,7 @@ security strives to maximize security based on the capabilities - of the peer (or peers). For some opportunistic security + of the peers. For some opportunistic security protocols the maximal protection possible may be just unauthenticated encryption to address passive monitoring. For - others, protection against active MiTM attacks may be an option. - Opportunistic security protocols may at times refuse to operate + others, protection against active attacks may be an option. + Opportunistic security protocols may, when applicable, refuse to communicate with peers for which higher security is expected, but for some @@ -192,3 +196,3 @@ this capability. To facilitate incremental deployment, - opportuistic security protocols may tolerate cleartext connections + opportunistic security protocols may tolerate cleartext connections or sessions with peers that don't support encryption. Over @@ -213,6 +217,6 @@ encompasses protocol designs that remove barriers to the - widespread use of encryption in the Internet. The actual + widespread use of encryption on the Internet. The actual protection provided by opportunistic security depends on the - capabilities of the communicating peers; opportunistic security - MUST attempt to at least encrypt network traffic, while allowing + capabilities of the communicating peers. Opportunistic security + MUST at least aim to encrypt network traffic, while allowing fallback to cleartext with peers that do not appear to be @@ -228,3 +232,3 @@ MAY be a reason to abort a connection to a peer that is expected - to be authenticated, it MUST NOT instead lead to communication + to be authenticated, it MUST NOT then lead to communication in cleartext when encryption is an option. Some Message -- Viktor. From nobody Wed Aug 6 03:08:33 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3EA1B2D05 for ; Wed, 6 Aug 2014 03:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UBDbS3zi0AD for ; Wed, 6 Aug 2014 03:08:28 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA86E1B2D14 for ; Wed, 6 Aug 2014 03:08:25 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 6F05D6D6B1; Wed, 6 Aug 2014 06:08:24 -0400 (EDT) Message-ID: <53E1FE96.60303@iang.org> Date: Wed, 06 Aug 2014 11:08:22 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> In-Reply-To: <53E17F34.9090804@dcrocker.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/MirOVz8V_88NzY5SgqSdFGTaaUI Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 10:08:30 -0000 On 6/08/2014 02:04 am, Dave Crocker wrote: > On 8/5/2014 2:04 PM, Nico Williams wrote: >> To be more specific OS must not preclude things like DANE that can be >> opportunistic and provide strong authentication. > > > A reference like that has been made several times, and I don't > understand it. > > DANE provides authenticated keys. Given the reliance on DNSSec, the > authentication is substantial. > > So while use of DANE has some interesting differences from using a > classic CA-based key, using it as a basis for encryption ought to > qualify as fairly straightforward authenticated encryption. > > That doesn't seem at all 'opportunistic' to me. Opportunistic refers to the choice made by the protocol on the day, not the strength of the outcome. iang From nobody Wed Aug 6 03:20:18 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BFD1B2D1B for ; Wed, 6 Aug 2014 03:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfoltWq25Att for ; Wed, 6 Aug 2014 03:20:11 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 278CE1B2D17 for ; Wed, 6 Aug 2014 03:20:11 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 4E0F06D6C7; Wed, 6 Aug 2014 06:20:10 -0400 (EDT) Message-ID: <53E20159.4060709@iang.org> Date: Wed, 06 Aug 2014 11:20:09 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <20140806042843.GS15044@mournblade.imrryr.org> In-Reply-To: <20140806042843.GS15044@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/b_nqg0ieDumAk9O4B5OWQ6X1bos Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 10:20:12 -0000 On 6/08/2014 05:28 am, Viktor Dukhovni wrote: > @@ -159,4 +160,5 @@ > goal of designs that feature opportunistic security is to be > - able to communicate with any reasonably configured peer. If > - many peers are only capable of cleartext, then it is acceptable > + able to communicate with any correctly configured peer. If a > + non-negligible number of potential peers are only capable of > + cleartext, then it is acceptable > to fall back to cleartext when encryption is not possible. If s/reasonably/correctly/good. The causality of "many peers" I don't understand. I would have thought it should say If a peer is only capable of cleartext, then it is acceptable to fall back to cleartext when encryption is not possible. If Why are we making the fallback conditional on multiple peers? iang From nobody Wed Aug 6 06:41:58 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEE81B2A06 for ; Wed, 6 Aug 2014 06:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpacC_hPKXUE for ; Wed, 6 Aug 2014 06:41:52 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E52D1B2D2D for ; Wed, 6 Aug 2014 06:41:52 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 729922AB219; Wed, 6 Aug 2014 13:41:50 +0000 (UTC) Date: Wed, 6 Aug 2014 13:41:50 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140806134150.GT15044@mournblade.imrryr.org> References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <20140806042843.GS15044@mournblade.imrryr.org> <53E20159.4060709@iang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53E20159.4060709@iang.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/pkStY5KE7R2oAq361zE4fKkQX6k Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 13:41:54 -0000 On Wed, Aug 06, 2014 at 11:20:09AM +0100, ianG wrote: > If a peer is only capable of cleartext, then it is acceptable > to fall back to cleartext when encryption is not possible. If > > Why are we making the fallback conditional on multiple peers? We are not. Rather the idea was that as deployed systems that speak a legacy protocol migrate from just cleartext to OS, once only a negligibl minority support only cleartext, the bar could be raised to "at least encrypt" leaving the negligible minority in the dust. In such situations it will still be possible to apply local policy overrides to communicate with the laggards, but otherwise, everyone will refuse to fail to encrypt. -- Viktor. From nobody Wed Aug 6 07:30:26 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FE01B28C1; Wed, 6 Aug 2014 07:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URMlYLJVaxyE; Wed, 6 Aug 2014 07:30:21 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F9C1B27D3; Wed, 6 Aug 2014 07:30:21 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C54852AB29E; Wed, 6 Aug 2014 14:30:20 +0000 (UTC) Date: Wed, 6 Aug 2014 14:30:20 +0000 From: Viktor Dukhovni To: ietf@ietf.org Message-ID: <20140806143020.GV15044@mournblade.imrryr.org> References: <53DA9B74.8040706@bbn.com> <20140806025536.GO15044@mournblade.imrryr.org> <53E199EB.8070403@dcrocker.net> <1602527.XOcXWRByOV@scott-latitude-e6320> <53E1A0C3.9030603@dcrocker.net> <53E21E92.8040409@cs.tcd.ie> <53E2311C.6010604@bbiw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53E2311C.6010604@bbiw.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Cb4LNuyFT4dqhOpRtwFEWPHfxHE Cc: saag@ietf.org Subject: Re: [saag] Best Effort Key Management (was Re: Last Call: X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ietf@ietf.org, saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 14:30:25 -0000 On Wed, Aug 06, 2014 at 06:43:56AM -0700, Dave Crocker wrote: > All of the above means that this term is for use only by security > experts, since it makes the term unwieldy for use by anyone else. The draft's core audience is designers of security protocols, and implementors of protocol toolkits. They'll make the technology available to users, but users also need a vocabulary to understand what they are getting. Postfix has had support for "opportunistic TLS" since at leeast 2006. There has been little user confusion. In January 2014 we added "opportunistic DANE TLS", and still no user confusion. Perhaps users will understand the concept more easily in the context of their particular application and its documentation. > I'll also note that the draft says nothing like the above. That should > bother you, and everyone else. More accurately, the draft leaves some things unsaid, that can only be made concrete in a particular protocol that makes the appropriate choices. For example, there is a common myth that in client-server protocols authentication of the server by the client and authentication of the client by the server have essentially similar semantics. This misconception is especially common with regard to TLS, where I've observed that many users believe that if authentication of the server by client can protect against active attacks, then surely so must authentication of the client by the server even absent the client authenticating the server. This is false. Sloppy reasoning about the security properties of protocols leads to nonsense. So I focused on what could be said about opportunistic security, and left out what could not be said. Perhaps some disclaimers belong in the text. Perhaps the text can be made clearer, I wonder what it is specifically that makes the text clear to Scott K., but fails to get the idea across to you. If you could highlight where I've lost you, perhaps the text can be improved. > Worse, the different responses from folks who have been active in the > discussion and who try to explain the term show different > understandings/meanings. Still. After all this time and discussion. Different words, same tune. > The only "end-to-end" protection function that has been seriously > discussed is confidentiality through encryption. All other protections > really have no concrete basis in practice or even in discussion focus, > within the context of this 'opportunistic' framework. This is clearly not the case. Multiple people have expressed some concern that even the draft's definition of OS makes it too easy to weasel out, implement only opportunistic unauthenticated encryption and stop there, ignoring active attacks entirely. They and I want more than that, and in fact we have a soon to be published and already deployed (small number of early adopters so far, gated by currently low deployment of DNSSEC) protocol "SMTP opportunistic DANE TLS", that does more. > Of the various terms that were originally suggested, the one that has > the simplext, clearest and most useful meaning is "best effort". > Opportunistic is clearly a much sexier word, but the continuing lack of > coherent community understanding of its meaning makes it problematic. At > the least, it means that it will not be particularly intuitive for the > rest of the world. Perhaps you're projecting your own surprise at the meaning of the term onto the community at large. Yes, I would like the draft to be accessible to all, and we may yet need to revise it to be more clear, but I don't think there's a broad failure by the community to understand the term. It seems that most people are able to express the same ideas in their words and still end-up saying the same thing. Ideally, we can increase the size of that purported "majority". > In contrast, best effort is a commonly used term and it means exactly > what is at issue here, as the common thread to everyone's attempted > explanations. > > To the extent that folks really can't abide having the term be focused > specifically on encryption, then focus on the functional component that > is also common to everyone's explanations: key management. How the key > is administered is the essence of what the current topic is focused on. > > Best Effort Key Management If "best effort" is the right prefix, it is still "best effort security", not "key management". But "best effort" misses the point, and we've already chosen a term by rough consensus, and any problems with the draft are with its wording, not the term chosen to be defined. If we keep revisiting every decision, we'll never be done. I would like to suggest strongly that we let "OS" stand, and focus on the clarity of the definition instead. -- Viktor. From nobody Wed Aug 6 07:51:33 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759ED1B27DE; Wed, 6 Aug 2014 07:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_hafKzjWYZZ; Wed, 6 Aug 2014 07:51:30 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F991B2B8F; Wed, 6 Aug 2014 07:51:30 -0700 (PDT) Received: from [10.251.200.130] ([69.162.16.14]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s76EpQ9H026786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Aug 2014 07:51:29 -0700 Message-ID: <53E24069.1020002@dcrocker.net> Date: Wed, 06 Aug 2014 07:49:13 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ietf@ietf.org, saag@ietf.org References: <53DA9B74.8040706@bbn.com> <20140806025536.GO15044@mournblade.imrryr.org> <53E199EB.8070403@dcrocker.net> <1602527.XOcXWRByOV@scott-latitude-e6320> <53E1A0C3.9030603@dcrocker.net> <53E21E92.8040409@cs.tcd.ie> <53E2311C.6010604@bbiw.net> <20140806143020.GV15044@mournblade.imrryr.org> In-Reply-To: <20140806143020.GV15044@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 06 Aug 2014 07:51:30 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/mK7LCkJ1A7zS5gDistVGX51yfz4 Subject: Re: [saag] Best Effort Key Management (was Re: Last Call: X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 14:51:32 -0000 On 8/6/2014 7:30 AM, Viktor Dukhovni wrote: > On Wed, Aug 06, 2014 at 06:43:56AM -0700, Dave Crocker wrote: > >> All of the above means that this term is for use only by security >> experts, since it makes the term unwieldy for use by anyone else. > > The draft's core audience is designers of security protocols, and > implementors of protocol toolkits. In terms of legitimate need for a term and likely use of it, I suggest that it is seriously misguided to believe that this term will be used only by that extremely restricted community. They'll make the technology > available to users, but users also need a vocabulary to understand > what they are getting. Exactly. Your earlier recitation of TLS as an example of why saying 'security' is ok is indicative of the problem here. The severely limited real-world uses of TLS is widely misunderstood amongst users. They hear the word security and believe all sorts of protections are in force that rarely -- or never -- are. Even in IETF discussions, the fact that client authentication is essentially never done is an example of the problems caused by sloppy, vague terminology. >> I'll also note that the draft says nothing like the above. That should >> bother you, and everyone else. > > More accurately, the draft leaves some things unsaid, that can only > be made concrete in a particular protocol that makes the appropriate > choices. Viktor, Stephen was providing a broad-based and conceptual description of the term that covers a wide variety of uses. The only place that's going to happen is in this definition. What will happen in specifications for particular protocols will be about particular protocols. They will not -- and must not -- be making broad statements of the sort that Stephen made. >> Worse, the different responses from folks who have been active in the >> discussion and who try to explain the term show different >> understandings/meanings. Still. After all this time and discussion. > > Different words, same tune. An unfortunate effect of small-group dynamics is that it's members can develop a shared sense of things that is widely at variance with what th rest of the world will see and understand. The challenge, then, is to treat publishable statements with skepticism and put effort into considering how they will be seen by those not already familiar with the language. So I do understand that your view is what some of you have convinced yourselves of. However it is not what I'm seeing in the different statements. >> The only "end-to-end" protection function that has been seriously >> discussed is confidentiality through encryption. All other protections >> really have no concrete basis in practice or even in discussion focus, >> within the context of this 'opportunistic' framework. > > This is clearly not the case. Multiple people have expressed some > concern that even the draft's definition of OS makes it too easy > to weasel out, implement only opportunistic unauthenticated encryption > and stop there, ignoring active attacks entirely. Forgive me but this response seems a non-sequitor to me. I do not understand how it is relevant to the concerns I've raised or suggestions I've made. >> Of the various terms that were originally suggested, the one that has >> the simplext, clearest and most useful meaning is "best effort". >> Opportunistic is clearly a much sexier word, but the continuing lack of >> coherent community understanding of its meaning makes it problematic. At >> the least, it means that it will not be particularly intuitive for the >> rest of the world. > > Perhaps you're projecting your own surprise at the meaning of the > term onto the community at large. It's always self-comforting to choose an ad hominem counter-argument. Please try to refrain from repeating that indulgence. > Yes, I would like the draft to > be accessible to all, and we may yet need to revise it to be more > clear, but I don't think there's a broad failure by the community > to understand the term. I do acknowledge that you are not seeing the problem I am asserting. >> To the extent that folks really can't abide having the term be focused >> specifically on encryption, then focus on the functional component that >> is also common to everyone's explanations: key management. How the key >> is administered is the essence of what the current topic is focused on. >> >> Best Effort Key Management > > If "best effort" is the right prefix, it is still "best effort > security", not "key management". But "best effort" misses the > point, and we've already chosen a term by rough consensus, and any > problems with the draft are with its wording, not the term chosen > to be defined. We have? What consensus process was that? This is an individual submission. The repeated citation of previous discussions in saag, as if they resolved issues, is a basic and serious error in IETF process. > If we keep revisiting every decision, we'll never be done. Casual dismissal of basic concerns might produce output, but it will be problematic output. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Aug 6 08:42:24 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310F11B27F6; Wed, 6 Aug 2014 08:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQjmGAPz413x; Wed, 6 Aug 2014 08:42:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF241B2822; Wed, 6 Aug 2014 08:42:18 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:34073 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XF3MF-0001Lo-4i; Wed, 06 Aug 2014 11:42:31 -0400 Message-ID: <53E24CD9.2060309@bbn.com> Date: Wed, 06 Aug 2014 11:42:17 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ietf@ietf.org, saag References: <53BFDC9A.5060307@iang.org> <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> In-Reply-To: <20140805181313.GE15044@mournblade.imrryr.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/nmFrfa6opiHIBLOTJ8qNbwq0QVY Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 15:42:21 -0000 Viktor, Rather than deal with each of your responses to my comments individually, I'll just provide some overall responses. 1. My comments on the abstract are not about blame, but about clarity in writing. It is important to distinguish between standards and what is deployed, especially because we can control only the former. 2. I have seen considerable feedback from various sources, including the GEN-ART review, that does not suggest that the doc is fine "as-is." 3. I've rarely seen someone suggest that being more precise in terminology is a bad thing. I think we owe it to readers of RFCs to be a clear as possible. Clarity in writing, and concision, yield good docs. You seem to believe that making a doc more precise makes it verbose. That is not a necessary outcome. 4. The term "collection" is generally defined as passive wiretapping, so encryption suffices, irrespective of using other security services. 5. Yes, you are not alone in making an erroneous statement that conflates PKIX standards and the Web PKI. However, that does not justify perpetuating such errors in an RFC. 6. The definition of OS appears at the end of Section 3, after all of the background. My comments argued that it appear sooner, which is not the same as saying that it needs appear in the Intro, contrary to your complaints. 7. I called into question the phrase "reasonably configured peer." Your reply was wordy and missed the point of my criticism. 8. You seem to have misunderstood why I found the term "many" to be confusing; changing it to "non-negligible number" misses the point. The point is that the text is clearer is one discusses a pair of peers trying to communicate. Also, I note that another person cited the same problem; it's not just me! 9. The phrase "security settings" is vague, since it means different things in different security protocol contexts. You later seem to acknowledge this when you observe that TLS and SMTP security settings are different. Saying that OS can be deployed "organically" suggests spreading around a lot of manure :-). 10. yes, do drop the term "application" when there is no intent to restrict solutions to be app-specific. 11. Your effort to clarify what you mean by "misconfigured" was a revelation to me. I did not get any sense of that meaning from the text. 12. Saying that an OS-capable peer may demand more than unauthenticated encryption does conflict with the stated goal of not requiring coordination (between administrators). I think this is an example of trying to make the term OS all encompassing. 13. Your attempts to reconcile what you refer to as "no ceiling" for OS and the simple notion of unauthenticated encryption between OS-capable peers yields text that is confusing, borderline contradictory. I noted several examples. Your replies either insist there is no problem (and that the meaning is clear) or offer additional text that is marginally better. 14. I said that the suggestion to use PFS was out of place in the goal where it appeared. Your reply missed the point entirely. 15. I observed that the closing MTA example is inappropriate in a doc of this sort. I should also have noted that the use of MUST here makes no sense in an informational RFC defining terminology. Your reply suggests that you again missed the point. From nobody Wed Aug 6 08:44:36 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CD41B283B; Wed, 6 Aug 2014 08:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz3u9JRZ-Fzu; Wed, 6 Aug 2014 08:44:31 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F431B282D; Wed, 6 Aug 2014 08:44:31 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 370772AB29E; Wed, 6 Aug 2014 15:44:30 +0000 (UTC) Date: Wed, 6 Aug 2014 15:44:30 +0000 From: Viktor Dukhovni To: saag@ietf.org, ietf@ietf.org Message-ID: <20140806154429.GX15044@mournblade.imrryr.org> References: <53DA9B74.8040706@bbn.com> <20140806025536.GO15044@mournblade.imrryr.org> <53E199EB.8070403@dcrocker.net> <1602527.XOcXWRByOV@scott-latitude-e6320> <53E1A0C3.9030603@dcrocker.net> <53E21E92.8040409@cs.tcd.ie> <53E2311C.6010604@bbiw.net> <20140806143020.GV15044@mournblade.imrryr.org> <53E24069.1020002@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53E24069.1020002@dcrocker.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/8GN45SMI27sNCenQ51G9g2MvWBY Subject: Re: [saag] Best Effort Key Management (was Re: Last Call: X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 15:44:33 -0000 On Wed, Aug 06, 2014 at 07:49:13AM -0700, Dave Crocker wrote: > >> Of the various terms that were originally suggested, the one that has > >> the simplest, clearest and most useful meaning is "best effort". > >> Opportunistic is clearly a much sexier word, but the continuing lack of > >> coherent community understanding of its meaning makes it problematic. At > >> the least, it means that it will not be particularly intuitive for the > >> rest of the world. > > > > Perhaps you're projecting your own surprise at the meaning of the > > term onto the community at large. > > It's always self-comforting to choose an ad hominem counter-argument. > Please try to refrain from repeating that indulgence. Apologies, no ad-hominem attack intended. I am trying to say that it seems that the problems with the text are far from universal, but if it fails to reach some people, perhaps we can do better, without losing yet a different group of people... Is the problem at all partly the possibility that you're bringing a prior conception of what "opportunistic security" might mean to the table? Or is it that I am simply failing to explain the term? Either way, now that you've seen various formulations of the idea of a range of security levels, dynamically tailored to the purported capabilities of the peer, what would you like the draft to do differently? Would all become light if I in fact added something like this at the beginning of the introduction: Opportunistic security: A security protocol in which the ability to communicate is prioritized over absolute security. This is achieved by replacing a fixed all or nothing security level expected of all peers with a range of security levels, such that the minimum acceptable level is tailored to the purported capabilities of the particular peer system. Provided the communicating peers are not misconfigured to promise greater capabilities than they can correctly deliver, security does not get in the way of the ability to communicate. While, in order to address Pervasive Monitoring (PM [RFC7258]), opportunistic security aims to always achieve at least unauthenticated encryption, with legacy protocols or infrastructure it may be acceptable to fall back to cleartext with peers that are not encryption capable. Opportunistic security protocol designs are strongly encouraged to strive for more than just unauthenticated encryption. Designs should, if possible, enable peers to advertise (in a downgrade-resistant manner) support for authenticated communication to thwart active attacks. When peers advertise such capabilities, it is expected that opportunistic security protocols will require greater security with those peers, and will refuse to communicate when the expected security level is not achieved. -- Viktor. From nobody Wed Aug 6 08:56:14 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8D51A000C; Wed, 6 Aug 2014 08:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHrAuVVdAFcj; Wed, 6 Aug 2014 08:56:04 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549251A0002; Wed, 6 Aug 2014 08:56:04 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id hn18so3067177igb.16 for ; Wed, 06 Aug 2014 08:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=/tAxo7ahrvWTeb2VQAxiuTTIYBtTGSNsZnvoCq2doCA=; b=tu6ZS9E6nHqHWVjMP5A5h+EWhdVqVninm02YwOjJINOrEMx2fymZd6VGwsh+gUIcdR 2+VrU/nbQZtqku/wLxirXYlwJdJoRu+uB3RxNBJQ7qQiJlGZNGAD07es6/7i1jF1C1Xi 47C2Y+1r9tsZuLPzxoMBZUK+Wct0stTb5rHkV7HRam7dYO6uamcBv/1NJSlOkeNSNaw+ pAOnNQ+B+NeRHtoVYQADxTUSXJdHuv45G4jh3qzkFVKUsmfmeQ1WtROiP1cN3rIjYN6A NqzngUWMrP6gh1DY3ToRjdxa0uQTINmjmrhLRDkD6m/iPZFf4QdkQoGWz89UvR5F78zi 1etw== X-Received: by 10.50.142.97 with SMTP id rv1mr60876245igb.13.1407340563607; Wed, 06 Aug 2014 08:56:03 -0700 (PDT) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.118.107]) by mx.google.com with ESMTPSA id ga11sm9021634igd.8.2014.08.06.08.56.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 08:56:02 -0700 (PDT) Message-ID: <53E25009.2030502@gmail.com> Date: Wed, 06 Aug 2014 11:55:53 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , "saag@ietf.org" , "ietf@ietf.org" References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BFEFFB.80809@gmail.com> In-Reply-To: <53BFEFFB.80809@gmail.com> Content-Type: multipart/alternative; boundary="------------070207060807030402050600" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_7wrY-j-gp502AK2xq7lyckXGzA Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 15:56:08 -0000 This is a multi-part message in MIME format. --------------070207060807030402050600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear colleagues: I had another look at the (now updated) draft: draft-dukhovni-opportunistic-security-02. Some more comments: (a) The term "perfect forward secrecy" (Section 2) is not defined properly. Suggested changes: (i) change "that are derived" towards "that were previously derived"; (ii) remove "or distributed using". This also In fact, it may be best to just use the terminology definition of RFC 4949 (For a key agreement protocol, the property that compromises long-term keying material does not compromise session keys that were previously derived from the long-term material.) (b) The verbiage in the draft should make it more clear that opportunistic encryption will not jeopardize those entities that wish to only set-up secure and authentic channels, by policy. Essentially, there are three channel categories: (i) unsecured channel; (ii) channel providing confidentiality only; (iii) channel providing confidentiality and authenticity. While opportunistic security aims to enable a shift from (i) to (ii), it may also cause a shift from (iii) to (ii) -- see also the concerns I expressed July 11, 2014, 10:08am EDT [copied at end of this email]. -- There should be language in draft 02 that expresses this concern (which would be a security loss), e.g., with the security consideration section. -- The current language re "design for interoperability" leaves ambiguity as to whether one cares about channels where one would like to enforce, by security policy, channel category (iii). Unless I understand this sentence wrong, the phrase "if authentication is only possible for some peers, then it is acceptable to authenticate only those peers and not the rest" seems to suggest lowest-common denominator security policies (opening the door to downgrade attacks, denial of service attacks, etc.). Currently, the phrase "interoperability must be possible without a need for the administrators of communicating systems to coordinate security settings" suggests that a system where one authenticates entities via certificate verification of a CA root key acceptable to the receiving end of a communicated cert would be taboo (thereby, killing off a specific way of realizing (iii) using certs); similarly, this seems to preclude communication settings where either end may have a white list of raw public keys. A much more useful approach seems to be to curtail user/device privileges depending on whether one ends up with channel category (i), (ii), or (iii), where policies may explicitly include blocking communications if channel category (iii) is not achieved, but may also allow specific message types to pass through if one only has an unsecured channel (category (i)) at hand. -- What about the following change at end of the section on "interoperability" (first para of Section 3): replace by "Opportunistic security must not get in the way of the peers communicating if neither end is misconfigured and neither end precludes communicating with the other end by virtue of its own security policy". Note: Right now, the term "misconfigured" is not really defined, but the suggestion from the entire draft is that one should allow channel type (ii), no matter what. This requires a finer line: ultimately, security policies should determine this. From that point of view, the email response below is somewhat scary: [excerpt of email Viktor Dukhovni, Wed Aug 6, 2014, 9:41am EDT] Why are we making the fallback conditional on multiple peers? We are not. Rather the idea was that as deployed systems that speak a legacy protocol migrate from just cleartext to OS, once only a negligibl minority support only cleartext, the bar could be raised to "at least encrypt" leaving the negligible minority in the dust. In such situations it will still be possible to apply local policy overrides to communicate with the laggards, but otherwise, everyone will refuse to fail to encrypt. (c) With the "maximize security peer by peer" para (Section 3), the phrase "opportunistic security may at times refuse to operate with peers for which higher security is expected, but for some reason not achieved" is somewhat cryptic. If the intention is to capture that ultimately it is up to each peer to enforce its own security policy as to channel category (i), (ii),or (iii), {which I do hope} this could be made more clear. Right now, this para has highly ambiguous language such as "the conditions under which connections fail should generally be limited to operational error t one or the other peer or an active attack, so that well-maintained systems rarely encounter problems in normal use of opportunistic security", which - to me - spells trouble since suggesting sloppy security policy enforcement (or, does operational error include a security policy mismatch?). (d) It may be good to articulate that, e.g., a security handshake that by itself only provides for channel type (ii) may provide some additional information to another process that allows elevating this to channel type (iii). An example hereof would be TLS with server authentication, where one does not really verify the cert as part of TLS, but simply sets up an anonymous channel (e.g., using ephemeral Diffie-Hellman) as part of TLS, and has another process, e.g., at the higher layer, verifying authenticity info (e.g., by verifying the certificate chain). This seems to be in line of what some people (e.g., Nico Willems) have suggested re including some language re interface aspects (DANE, etc.). Best regards, Rene On 7/11/2014 10:08 AM, Rene Struik wrote: > Dear colleagues: > > One of my concerns with Optimistic Encryption is that it may have as > side effect that it may be tempting for implementers to move from > secure and authentic channel set-up to just encrypted (but > unauthenticated) channels, since it - how convenient - removes the > need for any admin... I can already see arguments about why one should > spend money on authentication support if the attack window is so > small, etc., akin to discussions I have seen rampant in industrial > control settings, where some people have argued that communicating > symmetric keys wirelessly over the air for bootstrapping is okay, > "since nobody would listen in anyway". I think this is a major risk. > > If this "substitution risk" would materialize, we might actually lower > the bar and set back the clock nearly 40 years, since realizing > encrypted, unauthenticated channels already proposed in the 1976 > paper on "New Directions in Cryptography". > > Shouldn't one at least add some more extensive verbiage about security > policy enforcement? After all, reason to do authentication would be to > have some evidence on the party one is communicating with and can then > arrive at more fine-grained conclusions as to authorization and scope > hereof, based on that evidence. > > The the day-to-day risk for security architectures may be increase of > admin cost if there would ever be a lifecycle event after initial > provisioning and where lack of authentication may really hurt. > > Rene > > On 7/8/2014 11:34 AM, Stephen Farrell wrote: >> IETF LC started as promised. >> >> Cheers, >> S. >> >> >> -------- Original Message -------- >> Subject: Last Call: >> (Opportunistic Security: some protection most of the time) to >> Informational RFC >> Date: Tue, 08 Jul 2014 08:09:40 -0700 >> From: The IESG >> Reply-To: ietf@ietf.org >> To: IETF-Announce >> >> >> The IESG has received a request from an individual submitter to consider >> the following document: >> - 'Opportunistic Security: some protection most of the time' >> as Informational RFC >> >> 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@ietf.org mailing lists by 2014-08-05. Exceptionally, comments >> may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> This memo defines the term "opportunistic security". In contrast to >> the established approach of delivering strong protection some of the >> time, opportunistic security strives to deliver at least some >> protection most of the time. The primary goal is therefore broad >> interoperability, with security policy tailored to the capabilities >> of peer systems. >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ballot/ >> >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> This document and a predecessor have been the subject of discussion >> on the saag mailing list. [1] >> >> [1] >> https://www.ietf.org/mail-archive/web/saag/current/maillist.html >> >> >> >> >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------070207060807030402050600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear colleagues:

I had another look at the (now updated) draft: draft-dukhovni-opportunistic-security-02.

Some more comments:

(a) The term "perfect forward secrecy" (Section 2) is not defined properly. Suggested changes: (i) change "that are derived" towards "that were previously derived"; (ii) remove "or distributed using". This also In fact, it may be best to just use the terminology definition of RFC 4949 (For a key agreement protocol, the property that compromises long-term keying material does not compromise session keys that were previously derived from the long-term material.)

(b) The verbiage in the draft should make it more clear that opportunistic encryption will not jeopardize those entities that wish to only set-up secure and authentic channels, by policy. Essentially, there are three channel categories: (i) unsecured channel; (ii) channel providing confidentiality only; (iii) channel providing confidentiality and authenticity. While opportunistic security aims to enable a shift from (i) to (ii), it may also cause a shift from (iii) to (ii) -- see also the concerns I expressed July 11, 2014, 10:08am EDT [copied at end of this email].
-- There should be language in draft 02 that expresses this concern (which would be a security loss), e.g., with the security consideration section.
-- The current language re "design for interoperability" leaves ambiguity as to whether one cares about channels where one would like to enforce, by security policy, channel category (iii). Unless I understand this sentence wrong, the phrase "if authentication is only possible for some peers, then it is acceptable to authenticate only those peers and not the rest" seems to suggest lowest-common denominator security policies (opening the door to downgrade attacks, denial of service attacks, etc.). Currently, the phrase "interoperability must be possible without a need for the administrators of communicating systems to coordinate security settings" suggests that a system where one authenticates entities via certificate verification of a CA root key acceptable to the receiving end of a communicated cert would be taboo (thereby, killing off a specific way of realizing (iii) using certs); similarly, this seems to preclude communication settings where either end may have a white list of raw public keys. A much more useful approach seems to be to curtail user/device privileges depending on whether one ends up with channel category (i), (ii), or (iii), where policies may explicitly include blocking communications if channel category (iii) is not achieved, but may also allow specific message types to pass through if one only has an unsecured channel (category (i)) at hand.
-- What about the following change at end of the section on "interoperability" (first para of Section 3): replace by "Opportunistic security must not get in the way of the peers communicating if neither end is misconfigured and neither end precludes communicating with the other end by virtue of its own security policy". Note: Right now, the term "misconfigured" is not really defined, but the suggestion from the entire draft is that one should allow channel type (ii), no matter what. This requires a finer line: ultimately, security policies should determine this. From that point of view, the email response below is somewhat scary:
[excerpt of email Viktor Dukhovni, Wed Aug 6, 2014, 9:41am EDT]
Why are we making the fallback conditional on multiple peers?

We are not.  Rather the idea was that as deployed systems that speak a legacy protocol migrate from just cleartext to OS, once only a negligibl minority support only cleartext, the bar could be raised to "at least encrypt" leaving the negligible minority in the dust.  In such situations it will still be possible to apply local policy overrides to communicate with the laggards, but otherwise, everyone will refuse to fail to encrypt.
(c) With the "maximize security peer by peer" para (Section 3), the phrase "opportunistic security may at times refuse to operate with peers for which higher security is expected, but for some reason not achieved" is somewhat cryptic. If the intention is to capture that ultimately it is up to each peer to enforce its own security policy as to channel category (i), (ii),or (iii), {which I do hope} this could be made more clear. Right now, this para has highly ambiguous language such as "the conditions under which connections fail should generally be limited to operational error t one or the other peer or an active attack, so that well-maintained systems rarely encounter problems in normal use of opportunistic security", which - to me - spells trouble since suggesting sloppy security policy enforcement (or, does operational error include a security policy mismatch?).

(d) It may be good to articulate that, e.g., a security handshake that by itself only provides for channel type (ii) may provide some additional information to another process that allows elevating this to channel type (iii). An example hereof would be TLS with server authentication, where one does not really verify the cert as part of TLS, but simply sets up an anonymous channel (e.g., using ephemeral Diffie-Hellman) as part of TLS, and has another process, e.g., at the higher layer, verifying authenticity info (e.g., by verifying the certificate chain). This seems to be in line of what some people (e.g., Nico Willems) have suggested re including some language re interface aspects (DANE, etc.).   
Best regards, Rene

On 7/11/2014 10:08 AM, Rene Struik wrote:
Dear colleagues:

One of my concerns with Optimistic Encryption is that it may have as side effect that it may be tempting for implementers to move from secure and authentic channel set-up to just encrypted (but unauthenticated) channels, since it - how convenient - removes the need for any admin... I can already see arguments about why one should spend money on authentication support if the attack window is so small, etc., akin to discussions I have seen rampant in industrial control settings, where some people have argued that communicating symmetric keys wirelessly over the air for bootstrapping is okay, "since nobody would listen in anyway". I think this is a major risk.

If this "substitution risk" would materialize, we might actually lower the bar  and set back the clock nearly 40 years, since realizing encrypted, unauthenticated  channels already proposed in the 1976 paper on "New Directions in Cryptography".

Shouldn't one at least add some more extensive verbiage about security policy enforcement? After all, reason to do authentication would be to have some evidence on the party one is communicating with and can then arrive at more fine-grained conclusions as to authorization and scope hereof, based on that evidence.

The the day-to-day risk for security architectures may be increase of admin cost if there would ever be a lifecycle event after initial provisioning and where lack of authentication may really hurt.

Rene

On 7/8/2014 11:34 AM, Stephen Farrell wrote:
IETF LC started as promised.

Cheers,
S.


-------- Original Message --------
Subject: Last Call: <draft-dukhovni-opportunistic-security-01.txt>
(Opportunistic Security: some protection most of the time) to
Informational RFC
Date: Tue, 08 Jul 2014 08:09:40 -0700
From: The IESG <iesg-secretary@ietf.org>
Reply-To: ietf@ietf.org
To: IETF-Announce <ietf-announce@ietf.org>


The IESG has received a request from an individual submitter to consider
the following document:
- 'Opportunistic Security: some protection most of the time'
   <draft-dukhovni-opportunistic-security-01.txt> as Informational RFC

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@ietf.org mailing lists by 2014-08-05. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


    This memo defines the term "opportunistic security".  In contrast to
    the established approach of delivering strong protection some of the
    time, opportunistic security strives to deliver at least some
    protection most of the time.  The primary goal is therefore broad
    interoperability, with security policy tailored to the capabilities
    of peer systems.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ballot/


No IPR declarations have been submitted directly on this I-D.

This document and a predecessor have been the subject of discussion
on the saag mailing list. [1]

     [1] https://www.ietf.org/mail-archive/web/saag/current/maillist.html






_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag 




-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------070207060807030402050600-- From nobody Wed Aug 6 09:36:52 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873FD1A0108; Wed, 6 Aug 2014 09:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7mzi_vt8TbI; Wed, 6 Aug 2014 09:36:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35EFC1A00BB; Wed, 6 Aug 2014 09:36:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6F45D2AB29E; Wed, 6 Aug 2014 16:36:47 +0000 (UTC) Date: Wed, 6 Aug 2014 16:36:47 +0000 From: Viktor Dukhovni To: saag@ietf.org, "ietf@ietf.org" Message-ID: <20140806163647.GY15044@mournblade.imrryr.org> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BFEFFB.80809@gmail.com> <53E25009.2030502@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53E25009.2030502@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/kh8vK5BVopz_Aym5yRWDRjC8F3I Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 16:36:51 -0000 On Wed, Aug 06, 2014 at 11:55:53AM -0400, Rene Struik wrote: > (b) The verbiage in the draft should make it more clear that opportunistic > encryption will not jeopardize those entities that wish to only set-up > secure and authentic channels, by policy. Where local or other policy (e.g. semantics of HTTPS URIs) requires both active and passive protection, opportunistic security is not in scope. However, it is worth quoting from the draft that the effect of the high bar set by current designs is that most traffic is not protected at all. Opportunistic security aims to provide some (in fact as much as possible) security (be it just channel protection) to the huddled masses. Ideally, often essentially as strong as the statically defined comprehensive protections in extant protocols, but now on a peer by peer basis, enabling "incremental adoption". [ Steve Kent: that's what I meant to say by "organic", sorry about the inadvertent associations with manure, the word "organic" does not appear in the draft, only in my email comments, the right word is "incremental". ] > Essentially, there are three > channel categories: (i) unsecured channel; (ii) channel providing > confidentiality only; (iii) channel providing confidentiality and > authenticity. Yes, ignoring some sub-categories, essentially three possible *outcomes*. However, there are also multiple possible prior policies that lead to one of the afore-mentioned outcomes: * Channel security off * Channel security fixed to only encrypt * Channel security fixed to encrypt and authenticate * Channel security adaptive to peer capabilities finding the *maximum* possible with a given peer. The last of these is essentially opportunistic security. In real applications, the prior policy might also be peer-dependent. So that for example one might default to OS for a generic peer, but set a high bar for some peers statically (potentially requiring some bilateral policy coordination with administrators of the peer system). > While opportunistic security aims to enable a shift from (i) > to (ii), or for some combinations of peers (i) to (iii). > it may also cause a shift from (iii) to (ii) OS does not trump local or protocol requirements. It aims to secure to the extent possible, the under-served population left out in the cold by a binary choice between (i) and (iii). If OS adoption leads to users abandoning protocols or configurations that require (iii) in favour of more adaptive approaches, then perhaps users did not want (iii) as much as security engineers and protocol designers thought they did. > -- There should be language in draft 02 that expresses this concern (which > would be a security loss), e.g., with the security consideration section. OS itself does not degrade security. That would only happen if users choose to disable prior policies that require active protection and replace these with OS. OS does not aim for users to do that, but if they do, it is not clear that OS is doing the user a disservice. > -- The current language re "design for interoperability" leaves ambiguity as > to whether one cares about channels where one would like to enforce, by > security policy, channel category (iii). The SMTP opportunistic DANE TLS draft mentions coexistence of that protocol along-side existing channel security policies. We can add some language that makes it clear that OS is not intended to displace cases where security assurance is required, rather it is intended to serve the under-served. > Currently, the phrase > "interoperability must be possible without a need for the administrators of > communicating systems to coordinate security settings" suggests that a > system where one authenticates entities via certificate verification of a CA > root key acceptable to the receiving end of a communicated cert would be > taboo Opportunistic security needs to allow "incremental" adoption, without O(N^2) manual coordination effort. For use-cases where use of public CAs requires no manual coordination, OS can use public CAs. In any case, OS does not exclude the use of non-OS policies where applicable. Just because something is not OS, does not mean that it is forbidden. It is simply not OS. > -- What about the following change at end of the section on > "interoperability" (first para of Section 3): replace by "Opportunistic > security must not get in the way of the peers communicating if neither end > is misconfigured and neither end precludes communicating with the other end > by virtue of its own security policy". On the substance, sure, but if we're going to have to explain this, I'd like to do it elsewhere, by stating that OS does not trump local or other policy that requires greater channel security for some or all peers. Such policy is not OS, but OS can coexist along-side other (traditional or new mechanisms or policies). > Note: Right now, the term > "misconfigured" is not really defined, but the suggestion from the entire > draft is that one should allow channel type (ii), no matter what. For peers only capable of (ii), when some OS protocol is the selected security mechanism. I wanted to define OS. It seems I am being asked to also define how it interacts/coexists with other designs. > > (c) With the "maximize security peer by peer" para (Section 3), the phrase > "opportunistic security may at times refuse to operate with peers for which > higher security is expected, but for some reason not achieved" is somewhat > cryptic. If the intention is to capture that ultimately it is up to each > peer to enforce its own security policy as to channel category (i), (ii),or > (iii), No, this is mostly about the purported capabilities of the peer, not (static) prior policy. We can handle static policy separately if that's required. -- Viktor. From nobody Wed Aug 6 10:36:07 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5731A0396; Wed, 6 Aug 2014 10:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiI9aoVVLLCm; Wed, 6 Aug 2014 10:36:03 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6811A035E; Wed, 6 Aug 2014 10:36:02 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B6D4F80048; Wed, 6 Aug 2014 13:36:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1407346561; bh=32OqoCcD8L9beJQtPU6CpwFSlNPbDupcKjBn7CzgdPk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=rywgCcBNpm9LiwAWYELGmfi5hidWtXQzSvhkv4dJIy/p7pCOwYS15Lvy9bsOrM441 Pz0w4fQeVbzq66PHur7hD6KRO6YKVLrydRrc3wImh8fjhUYb42iqY7bVtkGHvFR+dC oHnymjpSEWWu1Jd5DlYa5YdGodTDYdkcI38uqgng= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s76Ha1VW005523; Wed, 6 Aug 2014 13:36:01 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 6 Aug 2014 13:36:00 -0400 (EDT) From: Paul Wouters To: Stephen Kent In-Reply-To: <53E24CD9.2060309@bbn.com> Message-ID: References: <53BFDC9A.5060307@iang.org> <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Sex8qP5wl_gX6vYKdXdmoRVTZWY Cc: ietf@ietf.org, saag Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 17:36:05 -0000 On Wed, 6 Aug 2014, Stephen Kent wrote: > 4. The term "collection" is generally defined as passive wiretapping, so encryption > suffices, irrespective of using other security services. I think that the term or usage of the term will need to be updated in that case since we have been made aware of the efforts of massively storing encrypted traffic for later decryption (note the leaks regarding pptp and weak IKE PSK's in particular) Encryption is not "sufficient" to protect against "collection". It only raises the costs for the collector to decrypt it. Pervasive monitors in fact, _especially_ collect encrypted communications for later processing. > 12. Saying that an OS-capable peer may demand more than unauthenticated encryption does > conflict with the stated goal of not requiring coordination (between administrators). I think > this is an example of trying to make the term OS all encompassing. Well, the term "opportunistic security" surely feels more encompassing compared to "opportunistic encryption". If we are only talking about encryption, don't call it security. Paul From nobody Wed Aug 6 10:55:59 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAC91A014D; Wed, 6 Aug 2014 10:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXRnq-8CfJKq; Wed, 6 Aug 2014 10:55:52 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD5A1A03CF; Wed, 6 Aug 2014 10:55:50 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8E3112AB2B9; Wed, 6 Aug 2014 17:55:49 +0000 (UTC) Date: Wed, 6 Aug 2014 17:55:49 +0000 From: Viktor Dukhovni To: saag@ietf.org, ietf@ietf.org Message-ID: <20140806175549.GD15044@mournblade.imrryr.org> References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/yWZAadGgTUpZqWB54DKlsibGxaM Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 17:55:54 -0000 On Wed, Aug 06, 2014 at 01:36:00PM -0400, Paul Wouters wrote: > >12. Saying that an OS-capable peer may demand more than unauthenticated encryption does > >conflict with the stated goal of not requiring coordination (between administrators). I am not aware of any evidence for this conflict, and have implemented and deployed a protocol in which the conflict is absent, by constrast with the non-opportunistic Web PKI TLS (applied to SMTP) where coordination between administrators was required and made deployment taxing and limited. > >I think is an example of trying to make the term OS all encompassing. Not, "all encompassing", rather not artificially constrained to needlessly weak mechanisms. > Well, the term "opportunistic security" surely feels more encompassing > compared to "opportunistic encryption". If we are only talking about > encryption, don't call it security. Most of us are not talking about just (unathenticated) encryption. However, the draft is about communications (or channel) security, not security generally. So, if we're really in the mood for making the term more "precise", we could say "opportunistic channel-security" or "opportunistic communications-security", but I don't think this is helpful. To the question of whether "best effort key management" or similar is better, my main objection is that this composes poorly with actualy protocols that employ the design principles: - "Opportunistic DANE TLS" works - "Best effort DANE TLS" does not. The point being that "DANE TLS" is applied when possible, not to some unspecified extent. -- Viktor. From nobody Wed Aug 6 12:38:04 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852A51A0101; Wed, 6 Aug 2014 12:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUowJHCgYGur; Wed, 6 Aug 2014 12:37:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4349B1A010D; Wed, 6 Aug 2014 12:37:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 04371BE7C; Wed, 6 Aug 2014 20:37:58 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbBesrDBkn8w; Wed, 6 Aug 2014 20:37:56 +0100 (IST) Received: from [10.87.48.11] (unknown [86.45.51.147]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D2A6ABE7B; Wed, 6 Aug 2014 20:37:56 +0100 (IST) Message-ID: <53E28414.6070105@cs.tcd.ie> Date: Wed, 06 Aug 2014 20:37:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Rene Struik , "saag@ietf.org" , "ietf@ietf.org" References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53BC0F94.8020608@cs.tcd.ie> <53BFEFFB.80809@gmail.com> <53E25009.2030502@gmail.com> In-Reply-To: <53E25009.2030502@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/089u88bMy1kU5BWUGLokIQM3BNA Subject: Re: [saag] Fwd: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 19:38:01 -0000 Hi Rene, Just two things on this bit... On 06/08/14 16:55, Rene Struik wrote: > > (b) The verbiage in the draft should make it more clear that > opportunistic encryption will not jeopardize those entities that wish to > only set-up secure and authentic channels, by policy. Essentially, there > are three channel categories: (i) unsecured channel; (ii) channel > providing confidentiality only; (iii) channel providing confidentiality > and authenticity. While opportunistic security aims to enable a shift > from (i) to (ii), it may also cause a shift from (iii) to (ii) -- see > also the concerns I expressed July 11, 2014, 10:08am EDT [copied at end > of this email]. First, your (iii) is not a single thing, we very often see server-auth only for https for example, which is quite different to mutually authenticated channels, which themselves may be e.g. TLS mutual auth or some form of TLS server-auth+channel-binding+user-password. Also SSH's leap-of-faith/TOFU model doesn't match any your categories well I would assert. So, we're just not on safe ground in making any inferences about possible "shifts" from (iii) to (ii). That said, I do get the concern so if there's text that could/should be added saying that changing from an existing working endpoint authenticated channel setup to an OS setup could be a disimprovement, that could be reasonable as a security consideration. Cheers, S. From nobody Wed Aug 6 15:54:41 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697931B290F; Wed, 6 Aug 2014 15:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqU-rh7oVaaH; Wed, 6 Aug 2014 15:54:37 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02BD1B2903; Wed, 6 Aug 2014 15:54:37 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CC9E72AB29E; Wed, 6 Aug 2014 22:54:36 +0000 (UTC) Date: Wed, 6 Aug 2014 22:54:36 +0000 From: Viktor Dukhovni To: ietf@ietf.org, saag@ietf.org Message-ID: <20140806225436.GI15044@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/fLwEIPtrzqi5BBqfkai-nOK0bpY Subject: [saag] : DNSSEC PKI semantics and risks (was tangentially: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 22:54:39 -0000 On Wed, Aug 06, 2014 at 06:39:37PM -0400, John C Klensin wrote: > The other end is equally bad. DNSSEC protects the integrity of > data already stored in the DNS. But, if the proverbial Bad Guy > can compromise a domain name registrar and register a name that > is misleading or otherwise problematic, certificates tied to > that name may not be very useful, especially as assertions of > good and upright behavior associated with, e.g., mail traffic. > Whether DANE-type certificates that depend on DNSSEC and > registrar integrity are more of less trustworthy than PKI-type > certificates that depend on certificate chains, > low-assertion-quality certificates, and CA integrity is an > interesting question... but one that might easily be resolved by > a race to the bottom. If folks want to continue this nuanced tangential discussion, perhaps a separate thread on saag, or on Perry's cryptography list would be more appropriate. I'm having a hard enough time keeping track of all the on-topic LC mail. I am Redirecting replies to saag only, and changing the subject. With any luck I've also removed the "References:" header, thus severing the new thread from the original. [ For what it is worth, I for one, don't expect certificates to warrant trustworthy or upright counterparty behaviour. I only expect them to ensure channel integrity for my connection to whichever deviant fraudster I've chosen to connect to. :-) Please express any disagreement or agreement or disagreement with that sentiment in another thread. Thanks. ] -- Viktor. From nobody Wed Aug 6 16:42:13 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56B51A0273; Wed, 6 Aug 2014 16:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UagY67fmlLyO; Wed, 6 Aug 2014 16:42:10 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BE5141A026A; Wed, 6 Aug 2014 16:42:10 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 93FB0202038; Wed, 6 Aug 2014 16:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=AYsdk8ralzzW2v XxIP4XkRdw4j4=; b=se2XWHSIQBy38mmHgx5x1pAWGVpIVCo4td7I4YIZBf3PA0 4ub+JTSwGWgguKXSNi2LfcHz/V5nDZ83Qnc7r1cxkxTc68v21ETMPJ6lk/bM3TMY 4A8r45fOs2ADqtKzVKmxXsa154+om4C2nULcBTz1O4TpGolpkOJ0URFCfDNCQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPA id 4994B202018; Wed, 6 Aug 2014 16:42:10 -0700 (PDT) Date: Wed, 6 Aug 2014 18:42:09 -0500 From: Nico Williams To: saag@ietf.org Message-ID: <20140806234208.GH23449@localhost> References: <20140806225436.GI15044@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140806225436.GI15044@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_r4e_ZCoPJe7GN_ap804w4c6aFI Cc: ietf@ietf.org Subject: Re: [saag] : DNSSEC PKI semantics and risks (was tangentially: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 23:42:12 -0000 On Wed, Aug 06, 2014 at 10:54:36PM +0000, Viktor Dukhovni wrote: > On Wed, Aug 06, 2014 at 06:39:37PM -0400, John C Klensin wrote: > > [MITM attack by compromised DNS registrar text elided.] > > If folks want to continue this nuanced tangential discussion, > perhaps a separate thread on saag, or on Perry's cryptography list > would be more appropriate. I'm having a hard enough time keeping > track of all the on-topic LC mail. DNSSEC is a PKI, with all that that implies, yes. Mitigations for PKI's compromised-issuer MITM vulnerability: - Strong naming constraints Check! The most important mitigation is already there. DNSSEC has and necessarily had to have strong naming constraints from the get go. - CT CT for DNSSEC should fall squarely into trans WG's remit (if not now, then after a charter update to make it so). Trans WG already has been discussing CT for DNSSEC! - Pinning Pinning of services' public keys/intermediate issuer at the application layer is completely orthogonal to DNSSEC. If you're already pinning, then you are already mitigating this problem. - Things like Perspectives (which IIUC is not being pursued any longer). Nico -- From nobody Wed Aug 6 18:23:09 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DB11A03AA; Wed, 6 Aug 2014 18:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drdy9WiKutU5; Wed, 6 Aug 2014 18:23:04 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1631A03A7; Wed, 6 Aug 2014 18:23:04 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 16FB680048; Wed, 6 Aug 2014 21:23:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1407374583; bh=crGIvi/8Zg1oXTJTGiHYG2BVAMxR+v5poDtCCTWWFu8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=fTicOcVNBOeWXHcXFRubxZm/xrWQMkIP+62r5tRwTYG77DpkzNHoNhYS6pHhz8LNB cfpMcASpSIc/W7DRqQ5aMsJkI3KGj4wcYcLB4IKuMfnEaCPYIUCtZfiZriRE/e/rh+ ad/jPIyHh4BX9ve8tLWCcSKADJN7eBjB5lpnXJ6A= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s771N21M025450; Wed, 6 Aug 2014 21:23:02 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 6 Aug 2014 21:23:02 -0400 (EDT) From: Paul Wouters To: Nico Williams In-Reply-To: <20140805210434.GB23449@localhost> Message-ID: References: <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/6IfYZx_AHGnGnZKuOS7EFDv-AUU Cc: saag@ietf.org, ietf@ietf.org Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 01:23:06 -0000 On Tue, 5 Aug 2014, Nico Williams wrote: > To be more specific OS must not preclude things like DANE that can be > opportunistic and provide strong authentication. >> Do no forget that during the saag discussion that preceded this >> draft, this was one of the main differences between our views, and >> that I do not subscribe to the view that opportunistic security is >> a narrow response to PM or that it should be limited to promoting >> just unauthenticated encryption. > > More than that: why should OS stop there? Aren't these two comments of contradicting? First you say authenticated encryption is not opportunistic security, then you say that OS should be more then just unauthenticated encryption and should not stop there? Paul From nobody Wed Aug 6 18:34:04 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2B11A03ED; Wed, 6 Aug 2014 18:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTVyxD4cRSdE; Wed, 6 Aug 2014 18:33:55 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB611A03C5; Wed, 6 Aug 2014 18:33:55 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 26E4E2AB2B6; Thu, 7 Aug 2014 01:33:53 +0000 (UTC) Date: Thu, 7 Aug 2014 01:33:53 +0000 From: Viktor Dukhovni To: saag@ietf.org, ietf@ietf.org Message-ID: <20140807013352.GL15044@mournblade.imrryr.org> References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/fmD-I9mefnSJ7UoD5kFKBaF8xQU Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 01:33:58 -0000 On Wed, Aug 06, 2014 at 09:23:02PM -0400, Paul Wouters wrote: > >To be more specific OS must not preclude things like DANE that can be > >opportunistic and provide strong authentication. > > >>Do no forget that during the saag discussion that preceded this > >>draft, this was one of the main differences between our views, and > >>that I do not subscribe to the view that opportunistic security is > >>a narrow response to PM or that it should be limited to promoting > >>just unauthenticated encryption. > > > >More than that: why should OS stop there? > > Aren't these two comments of contradicting? First you say authenticated > encryption is not opportunistic security, then you say that OS should > be more then just unauthenticated encryption and should not stop there? No contradiction. Neither Nico, nor the draft state the authenticated encryption is mutually exclusive with opportunistic security. Both in fact say the opposite. However, an indiscriminate static policy that applies a fixed authenticated security policy to all peers regardless of capabilities (and fails when the peer does not measure up, even though there no reason to expect that the peer could be authenticated, other than said static policy) is not opportunistic. * Fixed high bar: not opportunistic security * Variable bar, set high for peers that securely publish requisite capabilities, and lower for peers that don't, possibly even allowing cleartext, or at least unauthenticated encryption: opportunistic security. The two approaches can coexist, when an organization has high value business relationships with select peers, and wants guaranteed protection for traffic with them, but to promote as secure as possible communication with the rest of the planet, is more liberal (opportunistic) in its default communications policy. -- Viktor. From nobody Wed Aug 6 18:49:12 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92241A036B; Wed, 6 Aug 2014 18:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrccKjsrY5MZ; Wed, 6 Aug 2014 18:49:09 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D6ED21A0428; Wed, 6 Aug 2014 18:49:08 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id A3E38438072; Wed, 6 Aug 2014 18:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=of3pVLsazZVaaZ 2OH3HfcRZ82Rs=; b=PzDUdW4VwKlrYMj6fH0JpdxJk/dkBOWELsVc3E248ACQ16 +YJR8PBkrX/AwYbe2EA3lY/xnxwYQqB3ZIshnHOnXLZrs8nQr13vqf1OmoTgmBmh EfJJmGs5LpagD8L2aCjB7Zf1qVnigW/zmSznRNfQIHta+IWbZ+TxxQkJIh42A= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPA id 50D4543806C; Wed, 6 Aug 2014 18:49:08 -0700 (PDT) Date: Wed, 6 Aug 2014 20:49:07 -0500 From: Nico Williams To: Paul Wouters Message-ID: <20140807014905.GI23449@localhost> References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HkpA9TuOwJemkGC2SA0b_dG3jd4 Cc: saag@ietf.org, ietf@ietf.org Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 01:49:11 -0000 On Wed, Aug 06, 2014 at 09:23:02PM -0400, Paul Wouters wrote: > On Tue, 5 Aug 2014, Nico Williams wrote: > >To be more specific OS must not preclude things like DANE that can be > >opportunistic and provide strong authentication. > > >>Do no forget that during the saag discussion that preceded this > >>draft, this was one of the main differences between our views, and > >>that I do not subscribe to the view that opportunistic security is > >>a narrow response to PM or that it should be limited to promoting > >>just unauthenticated encryption. > > > >More than that: why should OS stop there? > > Aren't these two comments of contradicting? First you say authenticated > encryption is not opportunistic security, then you say that OS should > be more then just unauthenticated encryption and should not stop there? Are we reading the same quotes? I don't understand your response. Where did I say that "authenticated encryption is not opportunistic security"? Remember, I was really responding to Stephen K., not Viktor. As for the second quote, I meant that OS shouldn't mean only "unauthenticated security", which with DANE in context makes sense: - if you can securely discover that a service can do strong authentication, do _that_ (Securely discover: there's a DNSSEC path from . to the service's RRSets' names, AND there are TLSA-like RRSets for it that bootstrap authentication from DNSSEC. Remember: DNSSEC provices secure NXDOMAIN results.) - otherwise attempt unauthenticated encryption (The service had no TLSA-like RRSets or one of the zones from . to it doesn't support DNSSEC.) The ability to securely bootstrap authentication via DNSSEC is "opportunistic": we do it when it (DNSSEC, TLSA RRs) is there, we don't when it isn't. Teh key here is that DNSSEC allows us to securely detect that this path isn't available. The ability to use unauthenticated encryption when we would otherwise do cleartext is also "opportunistic": we do it if we can negotiate it. Nico -- From nobody Thu Aug 7 03:56:35 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D2E1B2A60; Thu, 7 Aug 2014 03:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhQ3_WrU2QSZ; Thu, 7 Aug 2014 03:56:30 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B92B1B2A5D; Thu, 7 Aug 2014 03:56:30 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:48928) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1XFLMx-0004N2-sZ (Exim 4.82_3-c0e5623) (return-path ); Thu, 07 Aug 2014 11:56:27 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1XFLMx-0002wa-R7 (Exim 4.72) (return-path ); Thu, 07 Aug 2014 11:56:27 +0100 Date: Thu, 7 Aug 2014 11:56:27 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Nico Williams In-Reply-To: <20140806234208.GH23449@localhost> Message-ID: References: <20140806225436.GI15044@mournblade.imrryr.org> <20140806234208.GH23449@localhost> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/saag/-RPGJZrux7rqAVG4vWDmF0ulQDg Cc: saag@ietf.org, ietf@ietf.org Subject: Re: [saag] : DNSSEC PKI semantics and risks (was tangentially: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 10:56:32 -0000 Nico Williams wrote: > > Mitigations for PKI's compromised-issuer MITM vulnerability: > > - Strong naming constraints > > Check! The most important mitigation is already there. DNSSEC has > and necessarily had to have strong naming constraints from the get > go. Sort-of related to this is the concept of delegation-only zones. If you get a signature for www.example.dodgy from the .dodgy keys rather than the example.dodgy keys, you know something is not right. DNSSEC can sometimes spot this if the validator has previously cached the zone cut. The idea of enforcing delegation-only zones is somewhat contentious and it causes interoperability problems in practice - and AFAIK the existing delegation-only code only constrains resolution not validation. (Historical note: I believe early versions of DNSSEC did not have such strong coupling between the naming hierarchy and the signing hierarchy. See RFC 3008.) Tony. -- f.anthony.n.finch http://dotat.at/ Thames: Variable 3, becoming east 4 or 5. Slight, occasionally moderate later. Rain later. Good, occasionally poor later. From nobody Thu Aug 7 04:31:49 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1941B2A34 for ; Thu, 7 Aug 2014 04:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAIWM2MoezSO for ; Thu, 7 Aug 2014 04:31:03 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5059B1B292E for ; Thu, 7 Aug 2014 04:31:03 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 92E4D6D6F7; Thu, 7 Aug 2014 07:30:59 -0400 (EDT) Message-ID: <53E36371.90703@iang.org> Date: Thu, 07 Aug 2014 12:30:57 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <20140806042843.GS15044@mournblade.imrryr.org> <53E20159.4060709@iang.org> <20140806134150.GT15044@mournblade.imrryr.org> In-Reply-To: <20140806134150.GT15044@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/IddsyAtHw3jL0t4F35lyVfKJROo Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 11:31:07 -0000 On 6/08/2014 14:41 pm, Viktor Dukhovni wrote: > On Wed, Aug 06, 2014 at 11:20:09AM +0100, ianG wrote: > >> If a peer is only capable of cleartext, then it is acceptable >> to fall back to cleartext when encryption is not possible. If >> >> Why are we making the fallback conditional on multiple peers? > > We are not. Rather the idea was that as deployed systems that > speak a legacy protocol migrate from just cleartext to OS, once > only a negligibl minority support only cleartext, the bar could be > raised to "at least encrypt" leaving the negligible minority in the > dust. In such situations it will still be possible to apply local > policy overrides to communicate with the laggards, but otherwise, > everyone will refuse to fail to encrypt. OK, got it, that becomes clearer reading the full context, 'design philosophy'. iang From nobody Thu Aug 7 07:12:29 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F0A1B2B36 for ; Thu, 7 Aug 2014 07:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_75=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SivTuFaqpyj4 for ; Thu, 7 Aug 2014 07:12:25 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650001A0AFC for ; Thu, 7 Aug 2014 07:12:25 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 05C992AB0B4; Thu, 7 Aug 2014 14:12:23 +0000 (UTC) Date: Thu, 7 Aug 2014 14:12:22 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140807141222.GB14392@mournblade.imrryr.org> References: <20140806225436.GI15044@mournblade.imrryr.org> <20140806234208.GH23449@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/xPTPIPYd7-MYvEoDuGmlg1FjNqw Subject: Re: [saag] : DNSSEC PKI semantics and risks (was tangentially: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 14:12:27 -0000 On Thu, Aug 07, 2014 at 11:56:27AM +0100, Tony Finch wrote: > Nico Williams wrote: > > > > Mitigations for PKI's compromised-issuer MITM vulnerability: > > > > - Strong naming constraints > > > > Check! The most important mitigation is already there. DNSSEC has > > and necessarily had to have strong naming constraints from the get > > go. > > Sort-of related to this is the concept of delegation-only zones. If you > get a signature for www.example.dodgy from the .dodgy keys rather than the > example.dodgy keys, you know something is not right. DNSSEC can sometimes > spot this if the validator has previously cached the zone cut. The idea of > enforcing delegation-only zones is somewhat contentious and it causes > interoperability problems in practice - and AFAIK the existing > delegation-only code only constrains resolution not validation. > > (Historical note: I believe early versions of DNSSEC did not have such > strong coupling between the naming hierarchy and the signing hierarchy. > See RFC 3008.) Another option may be to encourage TLDs and any other zones that correspond to public domain registries (the same ones to which one might apply delegation-only) to implement RFC 5011 signed key rollover (that is in a manner compatible to what we expect from the root zone some day). That way a nameserver (that supports RFC 5011 for more than just the root zone) could seed trust anchors for some set of such zones and track key rollover independently of any root zone signatures. Thus further reducing the ability of an active attacker in possession of the root key to MiTM domains in any TLD. -- Viktor. From nobody Thu Aug 7 07:43:27 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A203F1B2B8B for ; Thu, 7 Aug 2014 07:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJsBt9VGg87w for ; Thu, 7 Aug 2014 07:43:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E66B1A02D5 for ; Thu, 7 Aug 2014 07:43:23 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55018 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XFOuV-0003Bj-RZ; Thu, 07 Aug 2014 10:43:19 -0400 Message-ID: <53E39082.5060904@bbn.com> Date: Thu, 07 Aug 2014 10:43:14 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Wouters References: <53BFDC9A.5060307@iang.org> <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/iRIGS0sduaHQeQEj7rMhn1jNG-o Cc: saag Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 14:43:25 -0000 Paul, > On Wed, 6 Aug 2014, Stephen Kent wrote: > >> 4. The term "collection" is generally defined as passive wiretapping, >> so encryption >> suffices, irrespective of using other security services. > > I think that the term or usage of the term will need to be updated in > that > case since we have been made aware of the efforts of massively storing > encrypted traffic for later decryption (note the leaks regarding pptp > and weak IKE PSK's in particular) > > Encryption is not "sufficient" to protect against "collection". It only > raises the costs for the collector to decrypt it. Pervasive monitors > in fact, _especially_ collect encrypted communications for later > processing. Sorry if my comment was too terse. Acquiring traffic for later cryptanalysis is consistent with the notion of "collection" as passive wiretapping. We seem to agree that having to decrypt traffic raises the cost for the wiretapper. RFC 7258 argues that widespread use of encryption is a good countermeasure for PM. So, yes, collection of traffic is not prevent by encryption of payloads, but encryption of payloads is perceived as a meaningful, significant countermeasure. > >> 12. Saying that an OS-capable peer may demand more than >> unauthenticated encryption does >> conflict with the stated goal of not requiring coordination (between >> administrators). I think >> this is an example of trying to make the term OS all encompassing. > > Well, the term "opportunistic security" surely feels more encompassing > compared to "opportunistic encryption". If we are only talking about > encryption, don't call it security. Not everyone is in agreement about the scope of OS, as these continuing discussions illustrate :-). Steve From nobody Thu Aug 7 08:04:41 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228611B27D0; Thu, 7 Aug 2014 08:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQr-gFqwPbGV; Thu, 7 Aug 2014 08:03:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A36061B2BFF; Thu, 7 Aug 2014 08:03:27 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 947CB2AB29E; Thu, 7 Aug 2014 15:03:26 +0000 (UTC) Date: Thu, 7 Aug 2014 15:03:26 +0000 From: Viktor Dukhovni To: saag@ietf.org, ietf@ietf.org Message-ID: <20140807150326.GF14392@mournblade.imrryr.org> References: <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53E39082.5060904@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/1QmoC8JVb1EiwBojDHtaYC_ussc Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:04:05 -0000 On Thu, Aug 07, 2014 at 10:43:14AM -0400, Stephen Kent wrote: > >Well, the term "opportunistic security" surely feels more encompassing > >compared to "opportunistic encryption". If we are only talking about > >encryption, don't call it security. > > Not everyone is in agreement about the scope of OS, as these continuing > discussions illustrate :-). Indeed: - Rene Struik is concerned that opportunistic security might lead to a reduction in protection against active attacks, - You seem to want to ensure that opportunistic security should avoid defending against active attacks, - And I am suggesting adaptive behaviour that protects against active attacks when the peer is known to support authentication (via whichever key management technique from DANE, TOFU, ... is applicable to the situation at hand). I can address Rene's concern, by adding some text to explain that OS coexists with existing mandatory security policies, and is intended to handle the cases in which mandatory policy does not apply. Protocol designs should however be aware that trying to apply mandatory policy too broadly can have negative consequences, and that OS may well be a better fit in many situations. As for a desire to cap the definition of OS at unauthenticated encryption, I'm afraid I've seen no compelling rationale for that. It runs counter to Rene's concerns, and counter to the opportunistic use of DANE authentication in Postfix, and would fail to encourage other designers of adaptive protocols to consider authenticated modes of operation. Note, the draft DOES NOT require that OS protocols be able to support authentication, it encourages protocol designers to consider the option. It is even likely that OS designs for near-term wide deployment will not be able to offer authentication, since DANE is not yet ready for prime-time (DNSSEC adoption barrier). And yet I see no reason to artificially cap the ceiling or preclude the use of DANE for opportunistic authentication before we even get the chance to try it. -- Viktor. From nobody Thu Aug 7 08:08:52 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EB81B2BD5 for ; Thu, 7 Aug 2014 08:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avrHVyUM_SCf for ; Thu, 7 Aug 2014 08:08:38 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BFAD1B2BA0 for ; Thu, 7 Aug 2014 08:08:38 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 99A786D7C7; Thu, 7 Aug 2014 11:08:34 -0400 (EDT) Message-ID: <53E39670.50707@iang.org> Date: Thu, 07 Aug 2014 16:08:32 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53BFDC9A.5060307@iang.org> <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> In-Reply-To: <53E24CD9.2060309@bbn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/izPChAKBBX3WCCxONzQ_zscddq4 Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:08:42 -0000 On 6/08/2014 16:42 pm, Stephen Kent wrote: > 3. I've rarely seen someone suggest that being more precise in terminology > is a bad thing. I think we owe it to readers of RFCs to be a clear as > possible. > Clarity in writing, and concision, yield good docs. ... Normally, this would be true. Precision in terminology would be a good thing. Unfortunately, we are not in the normal circumstance. We're in the byzantine environment where agencies expend significant resources to push the net in particular directions. These directions can be obvious, direct, or also subtle and confusing. In particular, the agencies know that it is rather easy to push a committee into a self-defeating cycle of perfection. This is not a matter of speculation, it's standard time-tested practice [0]. It requires a certain degree of balance to oppose "more precision in terminology" when it is universally a good thing, as "the perfect is the enemy of the good." I'm not saying that we are at that point, but instead, I'm seeking to cast light on why people here might be aggressively pushing forward an imperfect text. Pushing against equally aggressive wordsmiths. It's simply that a lot of us feel that for a couple of decades, the committee-perfection thing preferred in IETF has been used against us. To bad results. Enough is enough. It takes some deft handling to find the balance, the compromise. iang [0] http://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html From nobody Thu Aug 7 09:07:38 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177D51B2E13; Thu, 7 Aug 2014 09:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2yTKhlaxp80; Thu, 7 Aug 2014 09:07:36 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1D21B282D; Thu, 7 Aug 2014 09:07:36 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id CE7562F406D; Thu, 7 Aug 2014 09:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=ftDoXoAP4erBWj8Qyhqrvs65Qjc =; b=HWckgJlwPwBbwmcCzWMeoHBlanA5Gm0m5uw2Rv198uzgbxAOk0wmWsaoNal 77Sw8TCov+xjXbNj5InkRjer7U9UHj/M0WtVy2cdVDEAYEKQ9CUUDBVBIkYmjzko pcBdIcpGlQtqC/fzjmMjJ81SdmNtn/tlCqxZlVOLALi9piKI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPA id 7C5A92F4057; Thu, 7 Aug 2014 09:07:35 -0700 (PDT) Date: Thu, 7 Aug 2014 11:07:34 -0500 From: Nico Williams To: saag@ietf.org, ietf@ietf.org Message-ID: <20140807160733.GN23449@localhost> References: <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140807150326.GF14392@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/gfDucNyjT1KqiHNbgiuVDumTxic Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 16:07:37 -0000 On Thu, Aug 07, 2014 at 03:03:26PM +0000, Viktor Dukhovni wrote: > - You seem to want to ensure that opportunistic security should > avoid defending against active attacks, [Here "you" == Stephen K.] That's my take on Stephen's position. IIRC it derived from wanting no UI impact from OS. But DANE lets you securely discover that you can authenticate a service, authenticate it, and success/failure *is* the *only* UI needed in that case -- a UI that already exists. I.e., OS w/ DANE has no UI impact, and you can't fallback on unauthenticated encryption when the service can be authenticated. OS w/ DANE has no downgrade attacks. The only ways to make OS w/ DANE fail are: compromise a DNS registrar in the chain, compromise the service, compromise the crypto, or DoS. Heck, OS w/ TOFU/pinning has similar properties once the peer's keys are learned/pinned (and with all the security considerations of TOFU/pinning). DANE isn't the only option, but DNSSEC's secure NXDOMAIN functionality makes DANE >> TOFU/pinning. Therefore OS can provide more than unauthenticated encryption in some cases. Nico -- From nobody Thu Aug 7 09:14:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42571B2E32; Thu, 7 Aug 2014 09:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFNKe97SkCC3; Thu, 7 Aug 2014 09:14:15 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CF84B1B2E31; Thu, 7 Aug 2014 09:14:15 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id B19129406D; Thu, 7 Aug 2014 09:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=9wARyK2khSStr28p5OGgAoCNfbo =; b=AwEvD+YRaK44eJb3mfb+LIUj810xa5ZAqcGCllMxl0QRuLEUGlrQBkMXJfu C8KRcttri8CBOA8dA7nVxxnnptlrfiWELnf334MAj+rJOzuUP9dGUyJd3cemD7yK 6zjUcOv4DqEawvb2ceinaoid+GBqg1NoYF9FZWg/tQFcz4v0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id 69EC79405C; Thu, 7 Aug 2014 09:14:15 -0700 (PDT) Date: Thu, 7 Aug 2014 11:14:14 -0500 From: Nico Williams To: saag@ietf.org, ietf@ietf.org Message-ID: <20140807161413.GO23449@localhost> References: <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140807150326.GF14392@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/RFkqK7S7HQfPLmY-piJBOEGYSbA Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 16:14:17 -0000 On Thu, Aug 07, 2014 at 03:03:26PM +0000, Viktor Dukhovni wrote: > - Rene Struik is concerned that opportunistic security might > lead to a reduction in protection against active attacks, I too had this concern. For me the key is that looking forward to a DANE-like world we get secure discovery of services' ability to authenticate. By "secure discovery" I mean: no downgrade attacks. Rene's concern however is partly about people getting a false sense of security and not bothering with anything else once they have unauthenticated encryption everywhere. However, I think DANE is much more likely to gain momentum than people are to think they have security against active attacks without it. Nico -- From nobody Thu Aug 7 09:21:10 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11CA1B2853; Thu, 7 Aug 2014 09:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMqg_CyCHvST; Thu, 7 Aug 2014 09:21:04 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609AC1B284F; Thu, 7 Aug 2014 09:21:04 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6B3ED2AB2BB; Thu, 7 Aug 2014 16:21:03 +0000 (UTC) Date: Thu, 7 Aug 2014 16:21:03 +0000 From: Viktor Dukhovni To: saag@ietf.org, ietf@ietf.org Message-ID: <20140807162103.GI14392@mournblade.imrryr.org> References: <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> <20140807160733.GN23449@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140807160733.GN23449@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/l7gz3-NnlC6jIN1KurCvshxaNW8 Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 16:21:07 -0000 On Thu, Aug 07, 2014 at 11:07:34AM -0500, Nico Williams wrote: > IIRC it derived from wanting no UI impact from OS. I've seen no compelling rationale for that either. The less said about the UI the better, we aren't experts even about the UI's of specific applications, let alone about the UIs of a family of protocols sharing some common security features. The draft's "no misrepresentation" language is about as far as one might reasonably venture in that direction. For example, in Postfix logs (closes thing in an MTA's to a UI), DANE authenticated delivery is logged as authenticated delivery, in much the same manner as authetnicated delivery via a trust chain from a public CA, or a statically configured public key fingerprint. Representing opportunistically DANE authenticated transactions as secure may be the right choice for an MTA, but need not be the right choice for a web browser. The draft should I think be silent on UI issues. Therefore, I think a UI argument against admitting authenticated modes of operation in the umbrella term is not appropriate. -- Viktor. From nobody Thu Aug 7 09:26:04 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50BA1B2DDE; Thu, 7 Aug 2014 09:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqLllnm0bgw5; Thu, 7 Aug 2014 09:25:40 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 70EEB1B2837; Thu, 7 Aug 2014 09:25:28 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 4EEEF4012D694; Thu, 7 Aug 2014 09:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=Vvcq2GA10T2t29fPvLcY9jB ud3Q=; b=H+Vg9DQW8ZWaWBO0iI0sP6BiPqXW4ICxQbx0MhQnyTqKukqv5xWkLXO zj4vKfs/MOyfje6dMlWM3x9BQamYz+SWlwh2bzE+CMcyOOuv8xK/D9Wmyn3WHHtF o++Bhsa4eXne2A177iCAWtEI+U48JAc3iWe4X8pY74voTGHoqv2c= Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id C3A3B4012D68C; Thu, 7 Aug 2014 09:25:27 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so4341927wgh.3 for ; Thu, 07 Aug 2014 09:25:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.92.196 with SMTP id co4mr25999091wjb.4.1407428726385; Thu, 07 Aug 2014 09:25:26 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Thu, 7 Aug 2014 09:25:26 -0700 (PDT) In-Reply-To: <20140807162103.GI14392@mournblade.imrryr.org> References: <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> <20140807160733.GN23449@localhost> <20140807162103.GI14392@mournblade.imrryr.org> Date: Thu, 7 Aug 2014 11:25:26 -0500 Message-ID: From: Nico Williams To: "saag@ietf.org" , "ietf@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/jWoMd7aZmIr0S1gwnhCm0Y12EBk Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 16:25:44 -0000 On Thu, Aug 7, 2014 at 11:21 AM, Viktor Dukhovni wrote: > On Thu, Aug 07, 2014 at 11:07:34AM -0500, Nico Williams wrote: >> IIRC it derived from wanting no UI impact from OS. > > I've seen no compelling rationale for that either. > > [...] +1 From nobody Thu Aug 7 10:30:31 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4861A007D for ; Thu, 7 Aug 2014 10:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jEOUnwdktYj for ; Thu, 7 Aug 2014 10:30:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C751A0045 for ; Thu, 7 Aug 2014 10:29:47 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (25.160.96.17) by DM2PR0301MB0655.namprd03.prod.outlook.com (25.160.96.17) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 7 Aug 2014 17:29:46 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) with mapi id 15.00.0995.014; Thu, 7 Aug 2014 17:29:46 +0000 From: Christian Huitema To: Nico Williams , "saag@ietf.org" Thread-Topic: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC Thread-Index: AQHPqdBg4VRINi+M6UqtkIb2NkRJlZu2DEYAgAKwSoCAAVhZ1IAAhcMAgAAN6EuAACJ6AIAF6h0AgAF/FQCAACn2gIABaCmAgAAfxgCAAWIQAIAABaQAgAAR7ACAABRJEA== Date: Thu, 7 Aug 2014 17:29:44 +0000 Message-ID: <9d20fc06cddd4c34beb0716b8dc240d2@DM2PR0301MB0655.namprd03.prod.outlook.com> References: <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> <20140807160733.GN23449@localhost> In-Reply-To: <20140807160733.GN23449@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(51704005)(199002)(83322001)(85852003)(95666004)(76576001)(77982001)(50986999)(74502001)(76176999)(74316001)(86612001)(85306004)(106116001)(83072002)(54356999)(87936001)(76482001)(93886004)(106356001)(4396001)(31966008)(99286002)(105586002)(101416001)(46102001)(107046002)(77096002)(64706001)(20776003)(81542001)(92566001)(2656002)(21056001)(80022001)(86362001)(99396002)(81342001)(33646002)(107886001)(79102001)(2501001)(3826002)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR0301MB0655; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/saag/w5jwrMF4pn0QcNYCcSSyilVZG2Q Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 17:30:27 -0000 > Heck, OS w/ TOFU/pinning has similar properties once the peer's keys are = learned/pinned=20 > (and with all the security considerations of TOFU/pinning). DANE isn't t= he only option, but=20 > DNSSEC's secure NXDOMAIN functionality makes DANE >> TOFU/pinning. > > Therefore OS can provide more than unauthenticated encryption in some cas= es. Agreed. I like Viktor's description of a continuum, from basic OS to maxima= l security. For example, I can see a baseline of "zero knowledge" encryption, using som= e kind of DH exchange where each party contributes half a key. This is obvi= ously vulnerable to MITM. We can progress from there with optional authenti= cation using channel binding, which would detect the MITM. If one party kno= ws a public key for the other party, they can use that key to encrypt their= "half key" during the DH exchange, effectively making MITM much harder. Th= ese are just sketches, but they show that is very easy to conceive OS proto= cols that offer gradual improvements in the level security. -- Christian Huitema From nobody Thu Aug 7 10:57:55 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DAD1A01F9; Thu, 7 Aug 2014 10:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uszrvRYTSC1p; Thu, 7 Aug 2014 10:57:48 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 281401A01D6; Thu, 7 Aug 2014 10:57:47 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id gl10so3728572lab.26 for ; Thu, 07 Aug 2014 10:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8KIZdItAbSBBAfRXPtp4GVFfXybE9pOeWnThE4W1+wQ=; b=gUV/lSQuI7rcIwpzDyrNMLNRuEDo8uG6srApXtxZvRz2jDEsWk0p/uClqkATc9syEX BB2vP2Uzvub31zJ9cVdT6n1xqcX5ho93u+mbWrrXc48OEXC0jcZMRw+TwnLasabSldz7 kOQWR1HPCvGJsiqBWCY//rPG6sshOpVqP03djXbwzNh1Y4d6+B7J+zM7kgm1pcnyde3K 1tdaPfprnhjZAurWYqHZVlQqP5ZjDlMxY0Ej4NMPZCfZMQQoBZr9tC94LmP7SPGzxi2S +O/FmHNYWaCrYjcixTZTfs8fgWmPj3I/IoYdlAvY64nQJOj+66/RDkszXx1d4Cidhsar iH1Q== MIME-Version: 1.0 X-Received: by 10.152.116.50 with SMTP id jt18mr18000616lab.21.1407434266296; Thu, 07 Aug 2014 10:57:46 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Thu, 7 Aug 2014 10:57:46 -0700 (PDT) In-Reply-To: <20140806234208.GH23449@localhost> References: <20140806225436.GI15044@mournblade.imrryr.org> <20140806234208.GH23449@localhost> Date: Thu, 7 Aug 2014 13:57:46 -0400 X-Google-Sender-Auth: xw-n4FO8FQaubuipAgB1Y9QSXnI Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/TRucVLKd3HdcDRKFHL8c9YT392w Cc: "saag@ietf.org" , IETF Discussion Mailing List Subject: Re: [saag] : DNSSEC PKI semantics and risks (was tangentially: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 17:57:50 -0000 The reason TRANS does not currently appear to be relevant to the DNSSEC advocates is that they are simplifying the PKI problem to exclude consideration of the entire class of attacks that TRANS is designed to control. In the real world, excluding consideration of a problem does not make it go away. So TRANS is very useful and relevant to DNSSEC. From nobody Thu Aug 7 11:03:31 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00831A0322; Thu, 7 Aug 2014 11:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juptUlUp2JLn; Thu, 7 Aug 2014 11:03:13 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA641A0314; Thu, 7 Aug 2014 11:02:57 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CCF4380048; Thu, 7 Aug 2014 14:02:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1407434575; bh=WvwFFNotZ5DpxkuIE1qtIFmX9aliuiVR1zvKly53ZKY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=rYRpfjAecae3NLF5gP8JdKcxaiigJXnxiyH0a6zj4VDaec20Wazd0vxYzuG9eCkWE 0JBXDMfLLQkSPQa2hHh+FnNi0Q1EULBQZV+WuqgOaRoiXbjK8AJpjiaeRkk5/9spo7 IRPbw4FFfUQDa2CEOcVeQuZsctXa/8IYwGkv1Tkc= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s77I2sBB004244; Thu, 7 Aug 2014 14:02:54 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 7 Aug 2014 14:02:54 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20140806225436.GI15044@mournblade.imrryr.org> <20140806234208.GH23449@localhost> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/nLbqX906esM1-tYilJwu_bUWjlk Cc: "saag@ietf.org" , IETF Discussion Mailing List Subject: Re: [saag] : DNSSEC PKI semantics and risks (was tangentially: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 18:03:20 -0000 On Thu, 7 Aug 2014, Phillip Hallam-Baker wrote: > The reason TRANS does not currently appear to be relevant to the > DNSSEC advocates is that they are simplifying the PKI problem to > exclude consideration of the entire class of attacks that TRANS is > designed to control. We have had only very preliminairy TRANS DNSSEC discussion so far. I am not aware of anything being excluded at this point. Some concerns raised do relate to the sheer size of DNS and what to log and what not to log to keep the log servers alive. What do you believe has already been excluded from TRANS with respect to DNSSEC by DNSSEC advocates? Paul From nobody Thu Aug 7 11:07:46 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12DC1A0343 for ; Thu, 7 Aug 2014 11:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KtqEXOG4yUE for ; Thu, 7 Aug 2014 11:07:43 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636A71A033E for ; Thu, 7 Aug 2014 11:07:43 -0700 (PDT) Received: from [128.9.184.190] ([128.9.184.190]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s77I45Zs027721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Aug 2014 11:04:05 -0700 (PDT) Message-ID: <53E3BF99.1090809@isi.edu> Date: Thu, 07 Aug 2014 11:04:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christian Huitema , Nico Williams , "saag@ietf.org" References: <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> <20140807160733.GN23449@localhost> <9d20fc06cddd4c34beb0716b8dc240d2@DM2PR0301MB0655.namprd03.prod.outlook.com> In-Reply-To: <9d20fc06cddd4c34beb0716b8dc240d2@DM2PR0301MB0655.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/2VW-804RMlCd68B70Zd7vmSjwyc Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 18:07:45 -0000 On 8/7/2014 10:29 AM, Christian Huitema wrote: >> Heck, OS w/ TOFU/pinning has similar properties once the peer's keys are learned/pinned >> (and with all the security considerations of TOFU/pinning). DANE isn't the only option, but >> DNSSEC's secure NXDOMAIN functionality makes DANE >> TOFU/pinning. >> >> Therefore OS can provide more than unauthenticated encryption in some cases. > > Agreed. I like Viktor's description of a continuum, from basic OS to maximal security. I agree it's useful to describe it as a range, but it isn't as clearly a continuum or even a total order of discrete values. Different types of security may not be directly comparable in terms of strength and protection, e.g., what's "stronger": - small keys and authentication - large keys and encryption without authentication Joe From nobody Thu Aug 7 11:30:53 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B571A0392 for ; Thu, 7 Aug 2014 11:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUp0n_w7P207 for ; Thu, 7 Aug 2014 11:30:49 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65091A0380 for ; Thu, 7 Aug 2014 11:30:49 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s77IUlV5004385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2014 14:30:48 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s77IUlV5004385 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1407436248; bh=e7KA87uj24aVw3lGTgUrTF0Sfrw=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=BsD8h3de0WZKRWE7fiRrsYo9NrWwDHvlORw9PdN2csR/1kiyhFdHdwqzoSIfqRxj4 MFSNbnOeYRCZgKEzCKMlQC/bb4dGAwT7K6GY8eWJB3VFah2UGfIiwJ0SjRSgJDIF29 ECMlNGUkE7B16DhCIRBc9Q8MlzlBFsG5qPAv0DC0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s77IUlV5004385 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd03.lss.emc.com (RSA Interceptor); Thu, 7 Aug 2014 14:30:30 -0400 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s77IUTfR005328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Aug 2014 14:30:30 -0400 Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub22.corp.emc.com ([128.222.70.134]) with mapi; Thu, 7 Aug 2014 14:30:29 -0400 From: "Black, David" To: Joe Touch , "saag@ietf.org" Date: Thu, 7 Aug 2014 14:30:28 -0400 Thread-Topic: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC Thread-Index: Ac+yaoam/mtSg2I4QeyMLJOkCKIaMwAAloHQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077B9516B8@MX15A.corp.emc.com> References: <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> <20140807160733.GN23449@localhost> <9d20fc06cddd4c34beb0716b8dc240d2@DM2PR0301MB0655.namprd03.prod.outlook.com> <53E3BF99.1090809@isi.edu> In-Reply-To: <53E3BF99.1090809@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/saag/hhsE_es_Zn1mH9bndQu7BBW9zZQ Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 18:30:52 -0000 > I agree it's useful to describe it as a range, but it isn't as clearly a > continuum or even a total order of discrete values. >=20 > Different types of security may not be directly comparable in terms of > strength and protection, e.g., what's "stronger": >=20 > - small keys and authentication >=20 > - large keys and encryption without authentication I agree that scope of security functionality (e.g., authentication presence/absence) should be orthogonal to strength of functional components (e.g., encryption key sizes). I thought this draft primarily concerned scope of functionality, as "opportunistic" is a characterization of (potential) absence of functionality (e.g., authentication, again). A functional continuum or range seems like a fine concept, where "maximal" refers to breadth of functionality, and not the relative strengths of individual functional elements. Thanks, --David > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Thursday, August 07, 2014 2:04 PM > To: Christian Huitema; Nico Williams; saag@ietf.org > Subject: Re: [saag] Last Call: > (Opportunistic Security: some protection most of the time) to Information= al > RFC >=20 >=20 >=20 > On 8/7/2014 10:29 AM, Christian Huitema wrote: > >> Heck, OS w/ TOFU/pinning has similar properties once the peer's keys a= re learned/pinned > >> (and with all the security considerations of TOFU/pinning). DANE isn'= t the only option, but > >> DNSSEC's secure NXDOMAIN functionality makes DANE >> TOFU/pinning. > >> > >> Therefore OS can provide more than unauthenticated encryption in some = cases. > > > > Agreed. I like Viktor's description of a continuum, from basic OS to ma= ximal security. >=20 > I agree it's useful to describe it as a range, but it isn't as clearly a > continuum or even a total order of discrete values. >=20 > Different types of security may not be directly comparable in terms of > strength and protection, e.g., what's "stronger": >=20 > - small keys and authentication >=20 > - large keys and encryption without authentication >=20 > Joe >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Thu Aug 7 11:38:31 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4A21A041C for ; Thu, 7 Aug 2014 11:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-kHrckxzzqy for ; Thu, 7 Aug 2014 11:38:27 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C851A0451 for ; Thu, 7 Aug 2014 11:38:27 -0700 (PDT) Received: from [128.9.184.190] ([128.9.184.190]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s77IbxG2007686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Aug 2014 11:37:59 -0700 (PDT) Message-ID: <53E3C78B.5010507@isi.edu> Date: Thu, 07 Aug 2014 11:38:03 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Black, David" , "saag@ietf.org" References: <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> <20140807160733.GN23449@localhost> <9d20fc06cddd4c34beb0716b8dc240d2@DM2PR0301MB0655.namprd03.prod.outlook.com> <53E3BF99.1090809@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712077B9516B8@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077B9516B8@MX15A.corp.emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/D0r53zR_w-bBjXpr7IcXvYH6dFQ Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 18:38:29 -0000 On 8/7/2014 11:30 AM, Black, David wrote: >> I agree it's useful to describe it as a range, but it isn't as clearly a >> continuum or even a total order of discrete values. >> >> Different types of security may not be directly comparable in terms of >> strength and protection, e.g., what's "stronger": >> >> - small keys and authentication >> >> - large keys and encryption without authentication > > I agree that scope of security functionality (e.g., authentication > presence/absence) should be orthogonal to strength of functional > components (e.g., encryption key sizes). I thought this draft > primarily concerned scope of functionality, as "opportunistic" is a > characterization of (potential) absence of functionality (e.g., > authentication, again). > > A functional continuum or range seems like a fine concept, where > "maximal" refers to breadth of functionality, and not the relative > strengths of individual functional elements. Sure, but there are multiple dimensions: - integrity protection - encryption - authentication Is OS just about the single dimension of authentication? If so, it seems like there are very few points in the continuum: 1. no knowledge 2. no validation, but known persistent within a session e.g., unsigned DH 3. no validation, but known persistent across multiple sessions e.g., TOFU 4. validated (and presumably persistent as well) e.g., PKI or preshared secret Joe From nobody Thu Aug 7 11:57:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE1C1A04B8 for ; Thu, 7 Aug 2014 11:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-c0-aNw2Xgs for ; Thu, 7 Aug 2014 11:57:11 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 193431A04AE for ; Thu, 7 Aug 2014 11:57:11 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id E19F02007F10B; Thu, 7 Aug 2014 11:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=GELAeeCJIxR7Cy P140g1jRYoxok=; b=Cbm8Lp07O+cPDV2yy9fg+fpkhwS9tdTd4T54bfyg1w9x4P W79Lrl86XGQVyWxVwS0B+L6IUnt6583p3yPOxdfE6G36VJfhOY4wsRcDf9EtbCD2 j0BubE8OaawSKm4G30RZjIVutASa6CxSf4nNiLicc8M2HierwERUg1uxX+HGE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPA id 8A37A2007F102; Thu, 7 Aug 2014 11:57:10 -0700 (PDT) Date: Thu, 7 Aug 2014 13:57:09 -0500 From: Nico Williams To: Joe Touch Message-ID: <20140807185708.GQ23449@localhost> References: <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> <20140807160733.GN23449@localhost> <9d20fc06cddd4c34beb0716b8dc240d2@DM2PR0301MB0655.namprd03.prod.outlook.com> <53E3BF99.1090809@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53E3BF99.1090809@isi.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/DDGmd3dNUV7us15Fp9H0XpApF4Y Cc: "saag@ietf.org" Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 18:57:12 -0000 On Thu, Aug 07, 2014 at 11:04:09AM -0700, Joe Touch wrote: > I agree it's useful to describe it as a range, but it isn't as > clearly a continuum or even a total order of discrete values. > > Different types of security may not be directly comparable in terms > of strength and protection, e.g., what's "stronger": > > - small keys and authentication > > - large keys and encryption without authentication If you're proposing that we have some security ranking, I think that way lies quagmire, or it should be left to a future document. We need to make progress. Viktor's I-D is a great start. Let's get started. Nico -- From nobody Thu Aug 7 12:03:10 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C42A1A0503 for ; Thu, 7 Aug 2014 12:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysFVWpldWTI4 for ; Thu, 7 Aug 2014 12:03:08 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1B22F1A035D for ; Thu, 7 Aug 2014 12:03:08 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id CB6AD3B805B; Thu, 7 Aug 2014 12:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=pIVKdnE0JHAuF4 IncDVqlMas++A=; b=QinCSZX17ijO92Xovt0i4CCK2eu7nNH0StzYzHev+bJdaV Yz8i378AVCaU2CuF/q2s3C4mUpQpiJDknusPqJIKh65x1Bj4vYCAtJT5UvflseUf cd/g+YwT9RevfD3G36PIyy46YJiA53NfoQnYp2FHHb9iqg5xv9XaZQFoSSDyM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPA id 668CF3B8069; Thu, 7 Aug 2014 12:03:07 -0700 (PDT) Date: Thu, 7 Aug 2014 14:03:06 -0500 From: Nico Williams To: Joe Touch Message-ID: <20140807190305.GR23449@localhost> References: <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> <20140807160733.GN23449@localhost> <9d20fc06cddd4c34beb0716b8dc240d2@DM2PR0301MB0655.namprd03.prod.outlook.com> <53E3BF99.1090809@isi.edu> <8D3D17ACE214DC429325B2B98F3AE712077B9516B8@MX15A.corp.emc.com> <53E3C78B.5010507@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53E3C78B.5010507@isi.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Ae4KI3q-yZnVQIv26x7Bh28At0I Cc: "saag@ietf.org" Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 19:03:09 -0000 On Thu, Aug 07, 2014 at 11:38:03AM -0700, Joe Touch wrote: > On 8/7/2014 11:30 AM, Black, David wrote: > >I agree that scope of security functionality (e.g., authentication > >presence/absence) should be orthogonal to strength of functional > >components (e.g., encryption key sizes). I thought this draft > >primarily concerned scope of functionality, as "opportunistic" is a > >characterization of (potential) absence of functionality (e.g., > >authentication, again). > > > >A functional continuum or range seems like a fine concept, where > >"maximal" refers to breadth of functionality, and not the relative > >strengths of individual functional elements. > > Sure, but there are multiple dimensions: > > - integrity protection > - encryption > - authentication > > Is OS just about the single dimension of authentication? If so, it No. Read the draft and the list archives. OS is about doing anything we can do that is better than sending plaintext. I.e., assume at least unauthenticated key exchange + authenticated encryption (in the AEAD sense), and do not preclude authentication; if you can securely detect the ability to authenticate, then do not fallback to unauthenticated key exchange nor cleartext. That's it. > seems like there are very few points in the continuum: > > 1. no knowledge > 2. no validation, but known persistent within a session > e.g., unsigned DH > 3. no validation, but known persistent across multiple sessions > e.g., TOFU > 4. validated (and presumably persistent as well) > e.g., PKI or preshared secret Also: DANE. That's special because you can securely find out that you can do it, with no downgrade attack. That consideration is critical to understanding potential future evolution for application protocols. Pre-shared/configured keying is the only other scheme that has this property, and it doesn't scale. Nico -- From nobody Thu Aug 7 13:10:24 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E0C1B27FA for ; Thu, 7 Aug 2014 13:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfDzXVsCMcgY for ; Thu, 7 Aug 2014 13:10:10 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394541B2800 for ; Thu, 7 Aug 2014 13:10:02 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s77K8suQ002270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Aug 2014 13:08:54 -0700 (PDT) Message-ID: <53E3DCD6.2040803@isi.edu> Date: Thu, 07 Aug 2014 13:08:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Nico Williams References: <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> <20140807160733.GN23449@localhost> <9d20fc06cddd4c34beb0716b8dc240d2@DM2PR0301MB0655.namprd03.prod.outlook.com> <53E3BF99.1090809@isi.edu> <20140807185708.GQ23449@localhost> In-Reply-To: <20140807185708.GQ23449@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/0bu-FQfghNCurX_PxUeHJPlVZ5Q Cc: "saag@ietf.org" Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 20:10:12 -0000 On 8/7/2014 11:57 AM, Nico Williams wrote: > On Thu, Aug 07, 2014 at 11:04:09AM -0700, Joe Touch wrote: >> I agree it's useful to describe it as a range, but it isn't as >> clearly a continuum or even a total order of discrete values. >> >> Different types of security may not be directly comparable in terms >> of strength and protection, e.g., what's "stronger": >> >> - small keys and authentication >> >> - large keys and encryption without authentication > > If you're proposing that we have some security ranking, I think that way > lies quagmire, or it should be left to a future document. Actually I'm just warning that there is no such thing, IMO. > We need to > make progress. Viktor's I-D is a great start. Let's get started. No disagreement; the point was to mark this as a rathole to avoid it. Joe From nobody Thu Aug 7 13:20:53 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9355B1A0063; Thu, 7 Aug 2014 13:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWHXrtkOxOCQ; Thu, 7 Aug 2014 13:20:47 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6CA61A03E6; Thu, 7 Aug 2014 13:20:47 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 889C180048; Thu, 7 Aug 2014 16:20:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1407442846; bh=6yU/Lnb34wEScOZqjf7xbhREI4uPbjkDGIWTfdK5v7I=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ixOCZ7EC1Y9XtIjPCCsAPfH+zrYipAVuGa8ryfN/PneV0vVLCXiywu6L54nfe7K+5 oCYcO+cRruYZsJSD5aDm2A9lcDov+A3BtSrKXRKq3ETgPnXkdtV3z1dY+4u+hNQ5l0 gioicktUQn692BuMN5PLPzitkqVxB7sRIe3BwFYI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s77KKjld029839; Thu, 7 Aug 2014 16:20:46 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 7 Aug 2014 16:20:45 -0400 (EDT) From: Paul Wouters To: Nico Williams In-Reply-To: <20140807161413.GO23449@localhost> Message-ID: References: <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> <20140807161413.GO23449@localhost> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/LZb9ZdMwYA86_Zmr_muPngk4gxs Cc: saag@ietf.org, ietf@ietf.org Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 20:20:49 -0000 On Thu, 7 Aug 2014, Nico Williams wrote: > On Thu, Aug 07, 2014 at 03:03:26PM +0000, Viktor Dukhovni wrote: >> - Rene Struik is concerned that opportunistic security might >> lead to a reduction in protection against active attacks, > > I too had this concern. For me the key is that looking forward to a > DANE-like world we get secure discovery of services' ability to > authenticate. By "secure discovery" I mean: no downgrade attacks. > > Rene's concern however is partly about people getting a false sense of > security and not bothering with anything else once they have > unauthenticated encryption everywhere. That is why FreeS/WAN did not do anonymous IPsec back in 1997. Boy I wish we had come to a different conclusions at the time. Today, it's only become more obvious that we need to do this, and yes not bother the user with a GUI if it is unauthenticated. Paul From nobody Thu Aug 7 13:22:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B321B2893 for ; Thu, 7 Aug 2014 13:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fb6kO3v2UaBE for ; Thu, 7 Aug 2014 13:22:54 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABB11B2887 for ; Thu, 7 Aug 2014 13:22:53 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 149752007D810; Thu, 7 Aug 2014 13:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=TWhx7c2CVhLNVz fU5On/ZVaNT90=; b=nkhDr8i1r6eJo2G52dAFplNh4nIDG7xLIrpS9QJTHLlZRg o9WK45yOJhRJIUsBNlnXRgQPLyGjANn/h+xuEUwXHPPit8VKQjjT5M4v0v0ioLiQ KB3M0T0LiSpEoeDnVxz87dWFIPkM5xUt8i7yqv5zNXlutBoacbglF//XtVB/4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPA id B79662007D80D; Thu, 7 Aug 2014 13:22:52 -0700 (PDT) Date: Thu, 7 Aug 2014 15:22:52 -0500 From: Nico Williams To: Joe Touch Message-ID: <20140807202250.GS23449@localhost> References: <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> <20140807160733.GN23449@localhost> <9d20fc06cddd4c34beb0716b8dc240d2@DM2PR0301MB0655.namprd03.prod.outlook.com> <53E3BF99.1090809@isi.edu> <20140807185708.GQ23449@localhost> <53E3DCD6.2040803@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53E3DCD6.2040803@isi.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Dsl8GMMMufkhs8A7daLVxy5j2kI Cc: "saag@ietf.org" Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 20:22:55 -0000 On Thu, Aug 07, 2014 at 01:08:54PM -0700, Joe Touch wrote: > On 8/7/2014 11:57 AM, Nico Williams wrote: > >On Thu, Aug 07, 2014 at 11:04:09AM -0700, Joe Touch wrote: > >>I agree it's useful to describe it as a range, but it isn't as > >>clearly a continuum or even a total order of discrete values. > >> > >>Different types of security may not be directly comparable in terms > >>of strength and protection, e.g., what's "stronger": > >> > >> - small keys and authentication > >> > >> - large keys and encryption without authentication > > > >If you're proposing that we have some security ranking, I think that way > >lies quagmire, or it should be left to a future document. > > Actually I'm just warning that there is no such thing, IMO. Indeed, a standard, global ranking of apples to oranges (which rot at different rates too boot) is not feasible. We shouldn't even try. (Local rankings are called "configuraiton". That's OK of course.) From nobody Thu Aug 7 13:26:18 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685FF1A00D7; Thu, 7 Aug 2014 13:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfEfLcDSangJ; Thu, 7 Aug 2014 13:26:14 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 936C31B28D9; Thu, 7 Aug 2014 13:26:14 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 4A8F82007F110; Thu, 7 Aug 2014 13:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=PreFLY+2Rsr9N5 q8SBSfxmoenC4=; b=pqbhX8XIwuGqYF7b+zSRz9lHt/fHT6zfvme+0wxRtqTMVN YXGXPq3X+ULzwZoll1EIkwiv81OBejN7ZNxPLlFO3UcHgoRB+E+vxlrqfOphSvYi IzgLeFsHG2JtSaNpElsSkKchnfsHa4wiwLjNaaKKMJ/sKVpTBVCAv+rJfak8g= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPA id EEA392007F10B; Thu, 7 Aug 2014 13:26:13 -0700 (PDT) Date: Thu, 7 Aug 2014 15:26:13 -0500 From: Nico Williams To: Paul Wouters Message-ID: <20140807202612.GT23449@localhost> References: <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> <20140807161413.GO23449@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zm5N4Q2X5EqPa0ChKFPi7AoHsAI Cc: saag@ietf.org, ietf@ietf.org Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 20:26:15 -0000 On Thu, Aug 07, 2014 at 04:20:45PM -0400, Paul Wouters wrote: > >Rene's concern however is partly about people getting a false sense of > >security and not bothering with anything else once they have > >unauthenticated encryption everywhere. > > That is why FreeS/WAN did not do anonymous IPsec back in 1997. Boy I > wish we had come to a different conclusions at the time. Today, it's > only become more obvious that we need to do this, and yes not bother > the user with a GUI if it is unauthenticated. If the app/user would fallback to cleartext, then yes. (I also wish that Dan McDonald's IP_SEC_OPT socket option from back in 1996-ish -which much later inspired RFC5660- had gotten momentum then too. We wouldn't have to have TCP-layer crypto protocols now.) Nico -- From nobody Thu Aug 7 13:40:20 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D226E1A035A for ; Thu, 7 Aug 2014 13:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmFQwHy79AOw for ; Thu, 7 Aug 2014 13:40:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 456971A00E6 for ; Thu, 7 Aug 2014 13:40:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2EC2ABE98; Thu, 7 Aug 2014 21:40:16 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sc_cvEgOwl5Q; Thu, 7 Aug 2014 21:40:14 +0100 (IST) Received: from [10.87.48.11] (unknown [86.46.26.242]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AB5CDBE8A; Thu, 7 Aug 2014 21:40:14 +0100 (IST) Message-ID: <53E3E42E.2010503@cs.tcd.ie> Date: Thu, 07 Aug 2014 21:40:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Joe Touch , Christian Huitema , Nico Williams , "saag@ietf.org" References: <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> <20140807160733.GN23449@localhost> <9d20fc06cddd4c34beb0716b8dc240d2@DM2PR0301MB0655.namprd03.prod.outlook.com> <53E3BF99.1090809@isi.edu> In-Reply-To: <53E3BF99.1090809@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HmivIfBctnySIQ-LMWYSHPTgVy4 Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 20:40:19 -0000 In some offlist mail I described OS as a useful protocol design pattern. The receiver of that mail thought that might be useful. Other opinions on that welcome. S. On 07/08/14 19:04, Joe Touch wrote: > > > On 8/7/2014 10:29 AM, Christian Huitema wrote: >>> Heck, OS w/ TOFU/pinning has similar properties once the peer's keys >>> are learned/pinned >>> (and with all the security considerations of TOFU/pinning). DANE >>> isn't the only option, but >>> DNSSEC's secure NXDOMAIN functionality makes DANE >> TOFU/pinning. >>> >>> Therefore OS can provide more than unauthenticated encryption in some >>> cases. >> >> Agreed. I like Viktor's description of a continuum, from basic OS to >> maximal security. > > I agree it's useful to describe it as a range, but it isn't as clearly a > continuum or even a total order of discrete values. > > Different types of security may not be directly comparable in terms of > strength and protection, e.g., what's "stronger": > > - small keys and authentication > > - large keys and encryption without authentication > > Joe > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Thu Aug 7 14:39:33 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668061B281E for ; Thu, 7 Aug 2014 14:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty9XSe8lJ17C for ; Thu, 7 Aug 2014 14:39:30 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A26A1A0104 for ; Thu, 7 Aug 2014 14:39:30 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 82B7B2AABB3; Thu, 7 Aug 2014 21:39:27 +0000 (UTC) Date: Thu, 7 Aug 2014 21:39:27 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140807213927.GL14392@mournblade.imrryr.org> References: <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> <20140807160733.GN23449@localhost> <9d20fc06cddd4c34beb0716b8dc240d2@DM2PR0301MB0655.namprd03.prod.outlook.com> <53E3BF99.1090809@isi.edu> <53E3E42E.2010503@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53E3E42E.2010503@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/RQJs8_4zA_0MBJcqe6W35XFydRk Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 21:39:32 -0000 On Thu, Aug 07, 2014 at 09:40:14PM +0100, Stephen Farrell wrote: > In some offlist mail I described OS as a useful protocol > design pattern. > > The receiver of that mail thought that might be useful. > Other opinions on that welcome. I may borrow the term "protocol design pattern" for the next revision of the draft, if you don't mind. There are a few layers of granularity at which one can consider the range of security levels that OS can achieve. At the coarsest level, we have a reasonable ranking: 1. cleartext, which is weaker than: 2. passive attack protection via unauthenticated encryption, which is weaker than: 3. passive and active attack protection via authenticated encryption Then we can peek beneath the covers and look at the details of the security protocols used in 2 or 3 to find that an objective total ordering of these is difficult to impossible. This said, there is some merit to the view the at the level of opportunistic behaviour, which is mostly about mechanism selection (encrypt or not, authenticate or not), we are just talking about the 123 choice above, and not so much about the details of which cipher-suites are negotiated in 2, or whether authentication is mutual in 3, ... Finding a sensible cipher-suite is largely outside the scope of opportunistic behaviour, it is just mechanism-specific baggage. Now mutual authentication in TLS where the server optionally requests client certificates can be opportunistic, based on the presence of published TLSA RRs for the client's purported identity. This is even an item for consideration on the DANE WG's updated charter. However, this does not change the picture much, because basically the opportunistic behaviour in that case is by the accepting peer, and for the initiating peer the coarse levels are still 1, 2, 3. So the draft could, in principle describe the more detailed coarse view above as the context in which the OS design patter plays out. -- Viktor. From nobody Thu Aug 7 15:59:20 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026011B278F for ; Thu, 7 Aug 2014 15:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtFK5RKNWj2l for ; Thu, 7 Aug 2014 15:59:17 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720B81A02BB for ; Thu, 7 Aug 2014 15:59:17 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6621480048; Thu, 7 Aug 2014 18:59:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1407452356; bh=w/EBKzryBx2Iv1RzwQ35AyJdLEiO/e54n8sEDgTRHPE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=krZPmuible4v28yEefbfj9v96RuV9sR1Ym3ZKIu5Spoh9nootK+c1+Qe0NVlSq/mf ETmz8S8O5D9E+meBaA6/0qc0qNoDhFacQb8f4Sva5HyH7DNKrhq9DZaVLeHC8ACtAQ wJjQqpwnpm60RNFPdcQEhdTH+N6XyXlUBDyXgFEQ= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s77MxF1l019706; Thu, 7 Aug 2014 18:59:15 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 7 Aug 2014 18:59:15 -0400 (EDT) From: Paul Wouters To: Stephen Kent In-Reply-To: <53E39082.5060904@bbn.com> Message-ID: References: <53BFDC9A.5060307@iang.org> <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/saag/gedMNtNvo8lhIGSNPLR-3XZZ8XA Cc: saag Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 22:59:19 -0000 On Thu, 7 Aug 2014, Stephen Kent wrote: >> Well, the term "opportunistic security" surely feels more encompassing >> compared to "opportunistic encryption". If we are only talking about >> encryption, don't call it security. > > Not everyone is in agreement about the scope of OS, as these continuing > discussions illustrate :-). Agreed. But the point I was trying to convey is that the continued discussion in itself is a sign that the term (and thus the final outcome of this discussion/draft) will not be very useful. It will at best have the same ambiguities as OE outside the IETF space. I think we are still confused about whether we are defining a term for protocol engineers or for consumers. I don't think OS is useful as a term for protocol engineers, especially because the only part of "security" we seem to be talking about is encryption and authentication. Security isn't opportunistic, security should be mandatory. Encryption or authentication can be opportunistic. Paul From nobody Thu Aug 7 16:27:56 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1521B28F6 for ; Thu, 7 Aug 2014 16:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TbsVBOso6uP for ; Thu, 7 Aug 2014 16:27:49 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C7BC81B28D2 for ; Thu, 7 Aug 2014 16:27:49 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 9AFF13B805B; Thu, 7 Aug 2014 16:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=8EmNons+9gIb2q JfR8trW5wASWo=; b=uStH1Al82Nzdlu5VHv1NoOGLxdgA9Tu0eSNOHDbNNKyL1w 0DEpXMvL2duYz1oON6/QFCgFltWmAkYtk3fiAj4cukHCaIFIl9qJABi0aJ6o4TNG WAm2HKx7AMQlXnZ7JhzkDId3mNzDkp5LjXRpz7XDG/NoWPSLtEDNGN0BbEdEs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPA id 421B43B8059; Thu, 7 Aug 2014 16:27:49 -0700 (PDT) Date: Thu, 7 Aug 2014 18:27:48 -0500 From: Nico Williams To: Paul Wouters Message-ID: <20140807232746.GW23449@localhost> References: <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zEkgZCdZro-5-P7dMI1TPIYhbOU Cc: saag Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 23:27:54 -0000 On Thu, Aug 07, 2014 at 06:59:15PM -0400, Paul Wouters wrote: > On Thu, 7 Aug 2014, Stephen Kent wrote: > >Not everyone is in agreement about the scope of OS, as these > >continuing discussions illustrate :-). > > Agreed. But the point I was trying to convey is that the continued > discussion in itself is a sign that the term (and thus the final > outcome of this discussion/draft) will not be very useful. It will at > best have the same ambiguities as OE outside the IETF space. We may just have to see. I think there's a much better chance for OS than there was for OE for the following reasons: - The Time is Right; timing is everything. - OE was IPsec-specific; OS has general applicability. - OS was a term we spent a *lot* of time settling on; some of us (at least myself) asked non-initiates for feedback on a large variety of alternatives, and OS seemed to work best. - We're actually working _right now_ (i.e., in this LC and related threads) on establishing widespread consciousness of the term OS within the IETF community. Combined with the general applicability of OS this means the term should have a much better chance of widespread adoption than OE. We'll have to socialize the term outside the IETF when we're done with this draft, of course. In any case, we can't fail to try just because we had trouble getting OE adopted. > I think we are still confused about whether we are defining a term for > protocol engineers or for consumers. I don't think OS is useful as a "Yes." We're defining it for protocol engineers (that's the audience for RFCs), but we've picked the term "OS" so that it denotes roughly the right thing to users as well. First, no other adjective in the English language is as appropriate a descriptor as "opportunistic" is. We spent a fair bit of time on this on saag. Second, "security" is clearly easier for users to understand than "encryption" and many other terms. Third, because the design pattern is right (right? I think we've clearly got consensus on that by now) we're not pulling a fast one on users. We can expect influential social media and news media writers to pick up on this eventually, particularly as more application protocols adopt OS and then products ship. Remember, the time is right; if not now, probably never. Finally, for something of such broad applicability we could argue about linguistics forever and not reach consensus. Fortunately we're only after rough consensus, which I believe we have. > term for protocol engineers, especially because the only part of > "security" we seem to be talking about is encryption and > authentication. On the contrary, it's a great term: the pattern it refers to is relatively simple and it addresses a highly visible subset of problems in the security space, on top of which its applicability is broad. OS has a great chance of becoming a well-known short-hand for exactly what we're after. > Security isn't opportunistic, security should be mandatory. Encryption > or authentication can be opportunistic. I've two different answers to this: - With DNSSEC/DANE in mind: Sure, because the end state is that all services will use DANE or alike. But if you insist on never having less than "full" security, then see my second answer below. - Absolutely NOT, because we've tried insisting on security all the time and failed time and again, and we know that given the choice of "things I care about don't work" or "things don't work securely", users (and vendors) reliably choose the latter. OS is about getting us on an upgrade path to security being on all the time (see first answer). You yourself wrote earlier today that you wished IPsec had done this in 1997. So what's the problem? Why the self-contradiction? :) I suspect you're reacting not to the protocol design pattern but to the name. Perhaps like Rene, you're afraid that OS will cause users to accept less than what they should expect. This is a risk, but again, with DANE in mind, I think it will be a non-problem: because DNSSEC allows us to securely discover that we can authenticate, leaving the choice, really, to the services we use (and so to how much they value reputation). In any case, since we won't get to the end state in one day, we need a deployment strategy and a catchy term. I believe there's no better alternative to "OS", or that we won't find a better alternative without spending so much time and effort on that search that we'll miss our window of opportunity. Nico -- From nobody Fri Aug 8 02:59:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83451B29F3 for ; Fri, 8 Aug 2014 02:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Clk40T2z3MfS for ; Fri, 8 Aug 2014 02:59:54 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31391B29EF for ; Fri, 8 Aug 2014 02:59:53 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id C0AD86D768; Fri, 8 Aug 2014 05:59:49 -0400 (EDT) Message-ID: <53E49F94.7020009@iang.org> Date: Fri, 08 Aug 2014 10:59:48 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53BFDC9A.5060307@iang.org> <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/WMTrHXQ93bOBSzxR0gn9m8YsXxo Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 09:59:56 -0000 On 7/08/2014 23:59 pm, Paul Wouters wrote: > On Thu, 7 Aug 2014, Stephen Kent wrote: > >>> Well, the term "opportunistic security" surely feels more encompassing >>> compared to "opportunistic encryption". If we are only talking about >>> encryption, don't call it security. >> >> Not everyone is in agreement about the scope of OS, as these >> continuing discussions illustrate :-). > > Agreed. But the point I was trying to convey is that the continued > discussion in itself is a sign that the term (and thus the final outcome > of this discussion/draft) will not be very useful. It will at best have > the same ambiguities as OE outside the IETF space. > > I think we are still confused about whether we are defining a term for > protocol engineers or for consumers. I don't think OS is useful as a > term for protocol engineers, especially because the only part of > "security" we seem to be talking about is encryption and authentication. I can't recall when we first started talking about SSH as being "opportunistic" as against the "model/standards" approach of PKI. I think it's at least a decade. > Security isn't opportunistic, security should be mandatory. Developers from the "model" or "standards" security school thought so, but people in the emerging "risk" school think not. In the risk [0] approach, everything is optional, and every tool is a mitigation. Everyone makes choices, and everyone should make different choices. Every choice has its pluses and minuses. Where "mandatory" makes its mark is if one legal party is supplying to another legal party, and there is a claim made; if the claim turns out to be false, and the second party is damaged, there is a legal liability. In order to mitigate (!) the risk of legal liability, a product is sold with some standard attacked, that says "X is mandatory". As long the product meets the standard's mandatory marks, the liability is limited. (Or so the legal theory goes.) If you didn't have the liability or commercial arrangement such an approach might not be needed. iang [0] another term might be risk security, but I suspect that boat has departed. From nobody Fri Aug 8 05:04:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2754F1B2A75; Fri, 8 Aug 2014 05:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvImReEygCLZ; Fri, 8 Aug 2014 05:04:07 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 407D51B2A72; Fri, 8 Aug 2014 05:04:07 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id u10so1825766lbd.18 for ; Fri, 08 Aug 2014 05:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QJhpRhIiaJph2UfjpSWRa0EnvRqggmsHHrYw7kpJYK8=; b=0O0Ni5f780ynexpixida+25XQrRF2pKeC/mQNI4tOjzNbXxJ39fOGbOy+QBUBbtBTf bIuZPtTvfhsYgGshjJNMuvxsCpfcWTi946zKwlq1PkXBK4l/QEzdIUwUskcZEVfY9lDt BBdb7xZ3GhMiIiBX9pNx2TaD9NQ9DK3+15zoFKk/5ht7emglmqqpOHuDmkXkrKf+zlt7 HZbbuoBpvTf89vB23IbRvDoa8EWx7hTc3CDWgk0YlTCNQk6JECgestVLiH07RkMKTLFn 9MYfSGxcXUKZXiAhUQhVWAAccIq4+Hjb8cV/+dunTBBo4ei9LZrIo0jr8+avXkxsuC8p xOcA== MIME-Version: 1.0 X-Received: by 10.152.8.166 with SMTP id s6mr1503517laa.85.1407499445588; Fri, 08 Aug 2014 05:04:05 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Fri, 8 Aug 2014 05:04:05 -0700 (PDT) In-Reply-To: References: <20140806225436.GI15044@mournblade.imrryr.org> <20140806234208.GH23449@localhost> Date: Fri, 8 Aug 2014 08:04:05 -0400 X-Google-Sender-Auth: Kr4Ts8kbd4YPYdu6a8D1aGeUxRM Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rRDCYbjmOu9nxqdi2pAUp5nApxs Cc: "saag@ietf.org" , IETF Discussion Mailing List Subject: Re: [saag] : DNSSEC PKI semantics and risks (was tangentially: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 12:04:09 -0000 On Thu, Aug 7, 2014 at 2:02 PM, Paul Wouters wrote: > On Thu, 7 Aug 2014, Phillip Hallam-Baker wrote: > > > > >> The reason TRANS does not currently appear to be relevant to the >> DNSSEC advocates is that they are simplifying the PKI problem to >> exclude consideration of the entire class of attacks that TRANS is >> designed to control. > > > We have had only very preliminairy TRANS DNSSEC discussion so far. > > I am not aware of anything being excluded at this point. Some concerns > raised do relate to the sheer size of DNS and what to log and what not > to log to keep the log servers alive. > > What do you believe has already been excluded from TRANS with respect to > DNSSEC by DNSSEC advocates? That is not what I wrote. What I was saying is that the need for TRANS is not going to be understood by people who believe that the 500+ DNS registrars are all trustworthy and that the mechanisms that the now 300+, soon to be 1,000s of registries deploy to ensure that keys are only introduced by the authorized party will all work without any possibility of error or attack. TRANS is the way to deploy DNSSEC. CAs will be doing CT, the Google has told us we will. CAs have the infrastructure to walk people through deployment of cryptographic apparatus. From nobody Fri Aug 8 06:28:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899F31A026E for ; Fri, 8 Aug 2014 06:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWaAaELSwBed for ; Fri, 8 Aug 2014 06:28:13 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACC91A0169 for ; Fri, 8 Aug 2014 06:28:13 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:34988 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XFkDa-000GKY-5m for saag@ietf.org; Fri, 08 Aug 2014 09:28:26 -0400 Message-ID: <53E4D06B.5020809@bbn.com> Date: Fri, 08 Aug 2014 09:28:11 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53BFDC9A.5060307@iang.org> <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39670.50707@iang.org> In-Reply-To: <53E39670.50707@iang.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/86T1bGS7UfdKG_setyRvauN_X0c Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 13:28:15 -0000 Ian, > On 6/08/2014 16:42 pm, Stephen Kent wrote: > >> 3. I've rarely seen someone suggest that being more precise in terminology >> is a bad thing. I think we owe it to readers of RFCs to be a clear as >> possible. >> Clarity in writing, and concision, yield good docs. ... > > Normally, this would be true. Precision in terminology would be a good > thing. > > Unfortunately, we are not in the normal circumstance. We're in the > byzantine environment where agencies expend significant resources to > push the net in particular directions. These directions can be obvious, > direct, or also subtle and confusing. I have seen no evidence that any of the work on various forms of opportunistic security for a variety of protocols in the IETF has been delayed by the deliberations about this doc. Thus I believe there is no reason to rush ahead with text that could be more precise, clearer, etc. Steve From nobody Fri Aug 8 06:33:41 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CABE1B27AB for ; Fri, 8 Aug 2014 06:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_2WJFFA5IZg for ; Fri, 8 Aug 2014 06:33:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E001B2791 for ; Fri, 8 Aug 2014 06:33:38 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:52970 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XFkIb-000MoC-Nf for saag@ietf.org; Fri, 08 Aug 2014 09:33:37 -0400 Message-ID: <53E4D1B1.7090502@bbn.com> Date: Fri, 08 Aug 2014 09:33:37 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53BFDC9A.5060307@iang.org> <20140727192353.GT15044@mournblade.imrryr.org> <53D6C902.50200@iang.org> <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/dAX9EhSI0U65LQWVWpMYkDf-v9A Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 13:33:40 -0000 Paul, > ... > > Security isn't opportunistic, security should be mandatory. That's a new statement in this context. And, given the variety of security services we may be able to provide, I don't know how to interpret the statement. > Encryption > or authentication can be opportunistic. I think you mean that the use of these services, between peers, may be invoked opportunistically? Steve From nobody Sat Aug 9 01:18:59 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839BA1A041F for ; Sat, 9 Aug 2014 01:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOirKCpB-Ot6 for ; Sat, 9 Aug 2014 01:18:55 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2335E1A03EC for ; Sat, 9 Aug 2014 01:18:54 -0700 (PDT) Received: from tormenta.home (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 8887E6D582; Sat, 9 Aug 2014 04:18:52 -0400 (EDT) Message-ID: <53E5D96A.5060200@iang.org> Date: Sat, 09 Aug 2014 09:18:50 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> <20140807160733.GN23449@localhost> <9d20fc06cddd4c34beb0716b8dc240d2@DM2PR0301MB0655.namprd03.prod.outlook.com> <53E3BF99.1090809@isi.edu> <53E3E42E.2010503@cs.tcd.ie> <20140807213927.GL14392@mournblade.imrryr.org> In-Reply-To: <20140807213927.GL14392@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/8TEFWfq8LCWs2c3pOTgwrcg9Uxc Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 08:18:57 -0000 On 7/08/2014 22:39 pm, Viktor Dukhovni wrote: > On Thu, Aug 07, 2014 at 09:40:14PM +0100, Stephen Farrell wrote: > >> In some offlist mail I described OS as a useful protocol >> design pattern. ... > There are a few layers of granularity at which one can consider > the range of security levels that OS can achieve. At the coarsest > level, we have a reasonable ranking: > > 1. cleartext, which is weaker than: > > 2. passive attack protection via unauthenticated encryption, which is > weaker than: > > 3. passive and active attack protection via authenticated encryption > > Then we can peek beneath the covers and look at the details of the > security protocols used in 2 or 3 to find that an objective total > ordering of these is difficult to impossible. Right. Maybe that is the point to make? > This said, there is some merit to the view the at the level of > opportunistic behaviour, which is mostly about mechanism selection > (encrypt or not, authenticate or not), we are just talking about > the 123 choice above, The current state of the art would suggest that ordering 123, yes. But our knowledge and our facilities advance over time. > and not so much about the details of which > cipher-suites are negotiated in 2, or whether authentication is > mutual in 3, ... > > Finding a sensible cipher-suite is largely outside the scope of > opportunistic behaviour, it is just mechanism-specific baggage. Well, no. Correct my understanding, but as I understand it: [TCPInc] will not change its charter with MUST-include-algorithm-agility until they receive specific advice from drafts such as this OS one or the stalled one on algorithm agility. As of the moment, [TCPinc] are in the unfortunate position of having to explain to their users that they might or might not be passively secured with confidentiality, but if they are, they can be assured that they are using one of several 'sensible' cipher-suites, and if they aren't, it might be because 'sensible' searches for suites failed to agree. > Now mutual authentication in TLS where the server optionally requests > client certificates can be opportunistic, based on the presence of > published TLSA RRs for the client's purported identity. This is > even an item for consideration on the DANE WG's updated charter. Engaging in mutual authentication is something where our knowledge and capabilities might indeed advance, once OS is accepted as a good design philosophy. It has often been suggested that the password mess can be mitigated by (eg) use of client certs. Yet, the only way this notion will advance is opportunistically; the standards/model approach fails to deploy client certs in sufficient numbers and therefore rules them outside the security model, optional-not-opportunistic, 2nd class citizen. (The trick here might be to leave 'purported identity' outside the discussion.) > However, this does not change the picture much, because basically > the opportunistic behaviour in that case is by the accepting peer, > and for the initiating peer the coarse levels are still 1, 2, 3. I don't think we know that. If hypothetically in TLS there was always a possibility for the client to deliver a cert, without being asked, then we might get 3 and 2 in parallel. > So the draft could, in principle describe the more detailed coarse > view above as the context in which the OS design patter plays out. I agree that the 1,2,3 description above is helpful as long as it is indicative of current understanding, and is not suggested as advice or best practice. Or, e.g., as you point above, the 1,2,3 is a stylistic high level view, but likely in the event, a designer will find that the objective total ordering fails. On the question of advice on algorithm agility or mutual agility, maybe they should be debated for their importance, but that doesn't mean the OS draft should include them. iang From nobody Sat Aug 9 08:03:54 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDE21B28F1; Wed, 6 Aug 2014 15:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSRd1otVVwDe; Wed, 6 Aug 2014 15:39:47 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC831B28CE; Wed, 6 Aug 2014 15:39:47 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XF9ry-000KtE-NT; Wed, 06 Aug 2014 18:39:42 -0400 Date: Wed, 06 Aug 2014 18:39:37 -0400 From: John C Klensin To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , Dave Crocker Message-ID: <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> In-Reply-To: <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FlZGusMpgadiuiWYTavzIwmyKhk X-Mailman-Approved-At: Sat, 09 Aug 2014 08:03:47 -0700 Cc: saag@ietf.org, ietf@ietf.org Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 22:39:51 -0000 --On Wednesday, August 06, 2014 07:15 +0200 Patrik = F=C3=A4ltstr=C3=B6m wrote: >=20 > On 6 aug 2014, at 04:26, Dave Crocker = wrote: >=20 >> Use DANE without DNSSec, and calling it opportunistic >> probably makes sense. Using it with DNSSec and it doesn't. >=20 > The devil is in the details. I think we disagree on the > meaning of the word "opportunistic", and the evaluation of > whether you are lucky enough. >=20 > Personally, I think that as fragile the current CA system is, > I think DANE without DNSSEC is more stable and better than the > current CA system. And better than self-signed-certs that one > "just accept" (which happens quite a lot). Conversely (and without agreeing or disagreeing with either of you), the discussion suggests noting, again, the very limited nature of what DNSSEC actually protects. It is ultimately an integrity test within the DNS hierarchy. If the resolver associated with the user's application is not DNSSEC-validating and within that user's trust boundary, then relying on DNSSEC for protection is only as good as the intermediate trust situation, e.g., whether the client user trusts the testing and validity assertions of her ISPs forwarding DNS system. There is reason to not do that. First, it may have changed but at least up to some years ago, those ISP "DNS servers" were much more often compromised than, e.g., authoritative servers for root or TLD domains. Second, some ISPs have discovered that that they have economic or political incentives to alter DNS queries or responses. Enough have done so under various circumstances to discourage uncritical trust. The other end is equally bad. DNSSEC protects the integrity of data already stored in the DNS. But, if the proverbial Bad Guy can compromise a domain name registrar and register a name that is misleading or otherwise problematic, certificates tied to that name may not be very useful, especially as assertions of good and upright behavior associated with, e.g., mail traffic. Whether DANE-type certificates that depend on DNSSEC and registrar integrity are more of less trustworthy than PKI-type certificates that depend on certificate chains, low-assertion-quality certificates, and CA integrity is an interesting question... but one that might easily be resolved by a race to the bottom. john From nobody Sat Aug 9 08:03:55 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FC31B28FA; Tue, 5 Aug 2014 22:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.252 X-Spam-Level: X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pui4uElAAGRq; Tue, 5 Aug 2014 22:15:55 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C0F1B288A; Tue, 5 Aug 2014 22:15:54 -0700 (PDT) Received: from [192.168.1.69] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id F1D0A208FC; Wed, 6 Aug 2014 07:15:51 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_B7B79904-79C7-4E9A-9BF4-AA328C366B5B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <53E19242.5030208@dcrocker.net> Date: Wed, 6 Aug 2014 07:15:50 +0200 Message-Id: <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> To: Dave Crocker X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/jr0zfFs6XLWEKTGMV1uCEiOzDo8 X-Mailman-Approved-At: Sat, 09 Aug 2014 08:03:49 -0700 Cc: saag@ietf.org, ietf@ietf.org Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 05:15:56 -0000 --Apple-Mail=_B7B79904-79C7-4E9A-9BF4-AA328C366B5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 6 aug 2014, at 04:26, Dave Crocker wrote: > Use DANE without DNSSec, and calling it opportunistic probably makes > sense. Using it with DNSSec and it doesn't. The devil is in the details. I think we disagree on the meaning of the = word "opportunistic", and the evaluation of whether you are lucky = enough. Personally, I think that as fragile the current CA system is, I think = DANE without DNSSEC is more stable and better than the current CA = system. And better than self-signed-certs that one "just accept" (which = happens quite a lot). Patrik --Apple-Mail=_B7B79904-79C7-4E9A-9BF4-AA328C366B5B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFT4boGrMabGguI180RApwlAJ4mxpFtT7AQslTgaPTSJ7jjsWE7AACeOSIH heu2sHeBHx2wgfCB3H4cV5s= =XY/I -----END PGP SIGNATURE----- --Apple-Mail=_B7B79904-79C7-4E9A-9BF4-AA328C366B5B-- From nobody Sat Aug 9 08:03:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698331A02FE; Wed, 6 Aug 2014 18:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyi_JdgjBy7s; Wed, 6 Aug 2014 18:03:45 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4F201A01DD; Wed, 6 Aug 2014 18:03:45 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id BA3333493CD; Thu, 7 Aug 2014 01:03:43 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7D9CD160067; Thu, 7 Aug 2014 01:14:01 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 24008160045; Thu, 7 Aug 2014 01:14:01 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 196911BA0239; Thu, 7 Aug 2014 11:03:39 +1000 (EST) To: John C Klensin From: Mark Andrews References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> In-reply-to: Your message of "Wed, 06 Aug 2014 18:39:37 -0400." <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> Date: Thu, 07 Aug 2014 11:03:39 +1000 Message-Id: <20140807010339.196911BA0239@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/saag/J2eRTro4Y_-kmZhj8vserXCnIYw X-Mailman-Approved-At: Sat, 09 Aug 2014 08:03:48 -0700 Cc: saag@ietf.org, ietf@ietf.org, Dave Crocker , =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 01:03:48 -0000 In message <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com>, John C Klensin writes : > > > --On Wednesday, August 06, 2014 07:15 +0200 Patrik Fältström > wrote: > > > > > On 6 aug 2014, at 04:26, Dave Crocker wrote: > > > >> Use DANE without DNSSec, and calling it opportunistic > >> probably makes sense. Using it with DNSSec and it doesn't. > > > > The devil is in the details. I think we disagree on the > > meaning of the word "opportunistic", and the evaluation of > > whether you are lucky enough. > > > > Personally, I think that as fragile the current CA system is, > > I think DANE without DNSSEC is more stable and better than the > > current CA system. And better than self-signed-certs that one > > "just accept" (which happens quite a lot). > > Conversely (and without agreeing or disagreeing with either of > you), the discussion suggests noting, again, the very limited > nature of what DNSSEC actually protects. DNSSEC is designed to protect the data from when it is entered to when it is retrieved by the application. It is the applications fault if it is not validating answers it receives. DNSSEC works with stub resolvers. The application just has to request the DNSSEC records be returned. There are a number of validating stub resolver libraries. Libdns has been able to perform in this role for 15 years now. named calls libdns to do its validation. Validating in the recursive server is a *necessary* step in getting a working DNSSEC path to the application but it was *never* intended to be the last place that validation was performed. It provides protection against attacks on the traffic between the recursive server and the authoratative server. It doesn't protect between the recursive server and the application. If, and only if, you have a trusted path between the recursive resolver and the stub resolver, and you know the validation policy of the resolver and agree with it can you trust the AD bit. Unless you are running a validating recursive server on the same machine as the application you will most probably not meet the required level to trust AD. If you use a ISP's nameserver you should not trust AD. I believe but have not verified that most DANE implementations actually validate answers in the application. This is where we expected the ultimate validation to be done when we started developing DNSSEC. In application includes within a library the application calls. > It is ultimately an > integrity test within the DNS hierarchy. If the resolver > associated with the user's application is not DNSSEC-validating > and within that user's trust boundary, then relying on DNSSEC > for protection is only as good as the intermediate trust > situation, e.g., whether the client user trusts the testing and > validity assertions of her ISPs forwarding DNS system. There > is reason to not do that. First, it may have changed but at > least up to some years ago, those ISP "DNS servers" were much > more often compromised than, e.g., authoritative servers for > root or TLD domains. Second, some ISPs have discovered that > that they have economic or political incentives to alter DNS > queries or responses. Enough have done so under various > circumstances to discourage uncritical trust. > > The other end is equally bad. DNSSEC protects the integrity of > data already stored in the DNS. But, if the proverbial Bad Guy > can compromise a domain name registrar and register a name that > is misleading or otherwise problematic, certificates tied to > that name may not be very useful, especially as assertions of > good and upright behavior associated with, e.g., mail traffic. > Whether DANE-type certificates that depend on DNSSEC and > registrar integrity are more of less trustworthy than PKI-type > certificates that depend on certificate chains, > low-assertion-quality certificates, and CA integrity is an > interesting question... but one that might easily be resolved by > a race to the bottom. While there is a threat with registries and registrars I believe you are overstating the threat. Being able to register a new name is NOT a threat. What is a threat is compromising registrant and registrar accounts, unauthorised transfers, a registry publishing unauthorised delegetion data, and the private keys of the registry being leaked / used in unintended ways. Note apart from private keys these are threats that registries and registrars have to deal with in plain DNS and should already be taking steps to address. > john > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sat Aug 9 09:27:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CE71A0639; Sat, 9 Aug 2014 09:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeqygiQJL83j; Sat, 9 Aug 2014 09:27:32 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 616BB1A0584; Sat, 9 Aug 2014 09:27:32 -0700 (PDT) Received: from [10.251.200.130] ([69.162.16.14]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s79GRRF8007208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 9 Aug 2014 09:27:31 -0700 Message-ID: <53E64B66.4000203@dcrocker.net> Date: Sat, 09 Aug 2014 09:25:10 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John C Klensin References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> In-Reply-To: <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 09 Aug 2014 09:27:31 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/aK5GBU1aQuPMzLkTDCuJyyLxkI4 Cc: saag@ietf.org, ietf@ietf.org Subject: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 16:27:35 -0000 On 8/6/2014 3:39 PM, John C Klensin wrote: > the discussion suggests noting, again, the very limited > nature of what DNSSEC actually protects. It is ultimately an > integrity test within the DNS hierarchy. This is such a fundamental point and of such broad community relevance, it's important we have clarity about it. I have always understood DNSSec to provide /authentication for DNS data/, specifically that the data were put there are under the authority of the domain name owner. The signing hierarchy (up to the root, when full DNSSec signing is used) certifies the authenticity of the domain owner's signature. Data integrity is an important side-effect of crypto signing methodology. However I'm not used to seeing it classed as the primary purpose of DNSSec, with no mention of authentication. It would be helpful for DNSSec experts to provide clear, simple, definitive statements on this. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Aug 9 10:03:59 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D8D1A0039; Sat, 9 Aug 2014 10:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJUwuxehkzKK; Sat, 9 Aug 2014 10:03:48 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDBA1A0035; Sat, 9 Aug 2014 10:03:48 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 69A09813B2; Sat, 9 Aug 2014 13:03:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1407603827; bh=WMMp8BARO7gvgziIMqjwhqsP3U1oKvWwURhdV+mxUtY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=j4XUFRzTM4RpbJBxCYp9Zr1TaJxFPpon7/PoR2RwevyHMIFLtlRtqKqhKN8EXrNDk p1vNi93SBMx4+dJCNRGt7Vk0fDwsSzqs9lbaWAW51odmsI9a5uoEsCruE5lDj8bGqF GDQH52/3T5NZyGOI2mGpyjROhrQ/e/IVFGea3soI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s79H3kw0029752; Sat, 9 Aug 2014 13:03:46 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sat, 9 Aug 2014 13:03:46 -0400 (EDT) From: Paul Wouters To: Dave Crocker In-Reply-To: <53E64B66.4000203@dcrocker.net> Message-ID: References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/saag/TrqFv7pqRJVpXeT7MhiJU80mFbE Cc: saag@ietf.org, ietf@ietf.org Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 17:03:50 -0000 On Sat, 9 Aug 2014, Dave Crocker wrote: > Data integrity is an important side-effect of crypto signing > methodology. However I'm not used to seeing it classed as the primary > purpose of DNSSec, with no mention of authentication. In the mid ninetees when dnssec was worked on, there were two camps. The DNS people who wanted to only secure DNS and explicitely did NOT want the DNS to become a PKI. And those that mainly wanted secure DNS to make a new PKI (eg Gilmore and the FreeS/WAN people). This fight continued throughout, and is the reason KEY/SIG/NXT changed to DNSKEY/RRSIG/NSEC. The change dictated those records were for DNS only and not for use by applications as PKI. So the PKI people had to silently go along with the DNS people to write and deploy DNSSEC, so that they could add their RRTYPE's for a PKI later even if the DNS people hated the idea. That is why you don't see it listed anywhere in any document as a purpose of DNSSEC. Paul From nobody Sat Aug 9 14:34:38 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725051A0197; Sat, 9 Aug 2014 14:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPPEMHc5XLYj; Sat, 9 Aug 2014 14:34:32 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2A61A0193; Sat, 9 Aug 2014 14:34:32 -0700 (PDT) Received: by mail-oi0-f43.google.com with SMTP id u20so4613225oif.30 for ; Sat, 09 Aug 2014 14:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yQKK9PQKyriXxUL4/ORaS9J3TXRVfdMfOeoYx+PmNB4=; b=qLRDJ5L9Sj3610rcZHuc/O/m2af98xibX+9Bf7F9XOxOzzw09BFjfHjEm6e9w/g5zd 3h2UHhvISiR1NqefBXMRnsy216mI0VCfnCfvupCBIxvSUSsM4SJ158lhCbzPLt7L8vJH EBOJIMnDweYWsKsTe7ChTgp0sGex2DaAjG2BZoSRIVJdfFZPAd2V3Ii3H3/N3CMeeRZ0 LC67YfffQ0InsIVLlQOhYfjGNZC+jvYEKjN48RzbcO1On/CYheiLaiojWzKyO/qOgtTT Jrrdzqhe/k/0cYnfltOnkF36NvMKSDIw8h9vEbEHs6ZcATDu7eR6cmFTz/cmomZiJbuT TlWQ== X-Received: by 10.182.236.225 with SMTP id ux1mr38331185obc.57.1407620071429; Sat, 09 Aug 2014 14:34:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.20.148 with HTTP; Sat, 9 Aug 2014 14:34:10 -0700 (PDT) In-Reply-To: References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> From: Donald Eastlake Date: Sat, 9 Aug 2014 17:34:10 -0400 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ikwLZxd4R_k4oGXELOsentyLYOE Cc: Dave Crocker , "saag@ietf.org" , IETF Discussion Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 21:34:33 -0000 Just to point out that DNSSEC authenticates data even in the case of null data; that is, it provide authenticated denial of the existence of data. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Sat, Aug 9, 2014 at 1:03 PM, Paul Wouters wrote: > On Sat, 9 Aug 2014, Dave Crocker wrote: > >> Data integrity is an important side-effect of crypto signing >> methodology. However I'm not used to seeing it classed as the primary >> purpose of DNSSec, with no mention of authentication. > > > In the mid ninetees when dnssec was worked on, there were two camps. The > DNS people who wanted to only secure DNS and explicitely did NOT > want the DNS to become a PKI. And those that mainly wanted secure > DNS to make a new PKI (eg Gilmore and the FreeS/WAN people). This > fight continued throughout, and is the reason KEY/SIG/NXT changed to > DNSKEY/RRSIG/NSEC. The change dictated those records were for DNS only > and not for use by applications as PKI. > > So the PKI people had to silently go along with the DNS people to > write and deploy DNSSEC, so that they could add their RRTYPE's for a > PKI later even if the DNS people hated the idea. That is why you don't > see it listed anywhere in any document as a purpose of DNSSEC. > > Paul > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Sat Aug 9 14:43:23 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02121A019A for ; Sat, 9 Aug 2014 14:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJ_hXQql8AK5 for ; Sat, 9 Aug 2014 14:43:20 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5ED1A0193 for ; Sat, 9 Aug 2014 14:43:19 -0700 (PDT) X-AuditID: 1209190d-f79c06d000002f07-c2-53e695f6a93b Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 86.3D.12039.6F596E35; Sat, 9 Aug 2014 17:43:18 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s79LhHjn013169 for ; Sat, 9 Aug 2014 17:43:18 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s79LhF2V020381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 9 Aug 2014 17:43:17 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s79LhE1V004373; Sat, 9 Aug 2014 17:43:14 -0400 (EDT) Date: Sat, 9 Aug 2014 17:43:14 -0400 (EDT) From: Benjamin Kaduk To: saag@ietf.org In-Reply-To: <53E5D96A.5060200@iang.org> Message-ID: References: <53E0FB86.7000803@bbn.com> <20140805181313.GE15044@mournblade.imrryr.org> <53E24CD9.2060309@bbn.com> <53E39082.5060904@bbn.com> <20140807150326.GF14392@mournblade.imrryr.org> <20140807160733.GN23449@localhost> <9d20fc06cddd4c34beb0716b8dc240d2@DM2PR0301MB0655.namprd03.prod.outlook.com> <53E3BF99.1090809@isi.edu> <53E3E42E.2010503@cs.tcd.ie> <20140807213927.GL14392@mournblade.imrryr.org> <53E5D96A.5060200@iang.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRmVeSWpSXmKPExsUixG6nrvtt6rNgg/8ztSym9HcyOTB6LFny kymAMYrLJiU1J7MstUjfLoErY+2ZCWwFDXwVDbufsDcwLuXuYuTkkBAwkZiwfzU7hC0mceHe ejYQW0hgNpPEoQmuXYxcQPYRRol1Z64xQzhXmSQm/3nCBFFVLzHx62ygbg4OFgEtiSnXeEDC bAIqEjPfbAQbJCIgKPGgbxILSK+wwEJGiRlPHzCCJDgFNCQer3wBNodXwFGi81cD1ILHzBLP m/eCnSQqoCOxev8UFogiQYmTM5+A2cxAy5ZP38YygVFgFpLULCSpBYxMqxhlU3KrdHMTM3OK U5N1i5MT8/JSi3SN9HIzS/RSU0o3MYLCj1OSdwfju4NKhxgFOBiVeHgbJjwLFmJNLCuuzD3E KMnBpCTKO7MXKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE94Q6UI43JbGyKrUoHyYlzcGiJM77 1toqWEggPbEkNTs1tSC1CCYrw8GhJMG7ZwpQo2BRanpqRVpmTglCmomDE2Q4D9Dw+SA1vMUF ibnFmekQ+VOMilLivGqTgRICIImM0jy4Xlh6eMUoDvSKMO8WkHYeYGqB634FNJgJaLCs6mOQ wSWJCCmpBsbTS/1tOOJr/KTimIPz7xhM7UotaTw02WvvOeY1qQdV25t+PdWtvfXpxt0Tb+ou He/fN+nNjCV/2v5Jyu794u1RLKE506LQSXCjo+u0dBfB2fuy1/s+urTtoXCHMRv3qxDm08U6 h9i4a+7zzXjItCNri0Ptvg7VpUkrP1Xd+tw/Xa3oZOVcrnVKLMUZiYZazEXFiQCpUecR6gIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/saag/uqNXETL-0g2y0sd8Zp8zRCAfnqQ Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 21:43:21 -0000 On Sat, 9 Aug 2014, ianG wrote: > On 7/08/2014 22:39 pm, Viktor Dukhovni wrote: > > > Now mutual authentication in TLS where the server optionally requests > > client certificates can be opportunistic, based on the presence of > > published TLSA RRs for the client's purported identity. This is > > even an item for consideration on the DANE WG's updated charter. > > > Engaging in mutual authentication is something where our knowledge and > capabilities might indeed advance, once OS is accepted as a good design > philosophy. It has often been suggested that the password mess can be > mitigated by (eg) use of client certs. Yet, the only way this notion > will advance is opportunistically; the standards/model approach fails > to deploy client certs in sufficient numbers and therefore rules them > outside the security model, optional-not-opportunistic, 2nd class citizen. > > (The trick here might be to leave 'purported identity' outside the > discussion.) > > > > However, this does not change the picture much, because basically > > the opportunistic behaviour in that case is by the accepting peer, > > and for the initiating peer the coarse levels are still 1, 2, 3. > > > I don't think we know that. If hypothetically in TLS there was always a > possibility for the client to deliver a cert, without being asked, then > we might get 3 and 2 in parallel. It seems that mutual-authentication everywhere, particularly if clients (sometimes) speak first, might make it eaiser to track the connections of a particular user. Leaving "purported identity" outside the discussion may leave room for a client to present a unique/throwaway identity when it does not care about being associated with some existing database of identities. -Ben From nobody Sun Aug 10 07:36:45 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B0B1A0737; Sun, 10 Aug 2014 07:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.568 X-Spam-Level: X-Spam-Status: No, score=-0.568 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkRLxNpVgIf6; Sun, 10 Aug 2014 07:36:41 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B3C1A0732; Sun, 10 Aug 2014 07:36:41 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XGUEc-00053X-Bu; Sun, 10 Aug 2014 10:36:34 -0400 Date: Sun, 10 Aug 2014 10:36:29 -0400 From: John C Klensin To: Steve Crocker Message-ID: <5B9A4046A1CB9ECDF6B77ACC@JcK-HP8200.jck.com> In-Reply-To: References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/saag/TwLBigQ01oFmCBHudu-lk4iX3VY Cc: ietf@ietf.org, David Crocker , saag@ietf.org Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 14:36:43 -0000 --On Saturday, August 09, 2014 12:31 -0400 Steve Crocker wrote: > The authenticity and integrity go hand in hand. The party > looking up a domain name wants to know if the answer is > correct. "Correct" in this context means that it was > provided by the party that is authorized to provide it, i.e. > the domain owner, and that the information hasn't been > modified along the path to the user. That's integrity and > authenticity combined. Steve, while I clearly agree with the above, I was trying to get at the point that there are other elements that people might reasonably consider part of authenticity. One is whether the apparent domain is what it appears to be. Another is whether the apparent domain owner is who it appears or claims to be. That, in turn, is closely connected to the question of whether there is enough information available to even determine what ownership assertion is being made, i.e., whether the user-accessible part of the registry database contains information about the domain owner or merely some proxy or "hidden registration" information that points to an entity that conceals identities for hundreds or thousands of such domains. >From those perspectives, a registrar or registry who might collude with a criminal registrant to create deliberately deceptive names and associated registration data (or whose procedures allow similar results without explicit collusion) is fully as much part of the threat model as a CA that issues certificates without any attempt to verify the identity of the entity being certified or who colludes in deliberately hiding or distorting the information. Now "we" all know that has nothing to do with DNSSEC. It provides assurance that what is in an authoritative zone and what reaches the systems closest to the user that actually validates the signatures and records are the same. But I'm concerned that it gets oversold to the point that users and others in the name-using environment hear what we say about "DNS Security" as "if DNSSEC validates the record, then one has assurances of the accuracy and integrity of the registrant and registrant- DNS entry relationship" with "accuracy" and "integrity" used in their street sense, not the much more narrow and technical DNS and DNSSEC ones. Where that loops back to things like DANE is that DANE, at least apparently, is making assertions about the identity of an individual or other entity, not [merely] about validation of the relationship of DNS records as installed/created in comparison to those received. As with DNSSEC itself, that isn't a problem if DANE is used carefully and with an understanding of what assertions are being made and can be trusted. It could be a significant problem if people over-promise (or over-believe) and the use of DANE for critical functions becomes widespread enough to become a tempting target for attacks of technical and/or social or economic character (just as we have seen on CAs). There is one sense in which trust models based on DNSSEC that seem to imply certification of non-DNS entities (like registrants) are more dangerous than ones based on CA chains. In the latter case, there are good, and obvious, analogies to many people's everyday experience. If one finds someone who claims to be a notary but who operates out of the back of a taxicab, exhibits no credentials or authorization, who is willing to certify a document with no more identification of the signer than the ability to pay a few dollars in cash, and trusts him to certify signatures on an important document, it is pretty generally understood what that certification is worth. We aren't quite there with CAs, but most people are able to at least understand applicability of the analogy. On the other hand, when we build a system on top of the DNS and DNSSEC, relying on elaborate rituals like the signing of the root and layers of processes that are, for the typical user of the Internet, indistinguishable from magic, and fail to be clear that, e.g., no actual certification of registrant identity or integrity is involved, people may trust the magic rather than trusting DNSSEC as it is. That, in turn, could lead to some really nasty surprises --and loss of confidence in us and the institutions we ask people to trust-- when the bad effects of that misunderstanding manifest themselves in a damaging and public attack. best, john From nobody Sun Aug 10 08:00:13 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432BC1A0747 for ; Sun, 10 Aug 2014 08:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqpFMsYuvfjg for ; Sun, 10 Aug 2014 08:00:08 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771391A0741 for ; Sun, 10 Aug 2014 08:00:07 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3D8792AB0B4; Sun, 10 Aug 2014 15:00:06 +0000 (UTC) Date: Sun, 10 Aug 2014 15:00:06 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140810150005.GH14392@mournblade.imrryr.org> References: <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> <5B9A4046A1CB9ECDF6B77ACC@JcK-HP8200.jck.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B9A4046A1CB9ECDF6B77ACC@JcK-HP8200.jck.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/mdK8GE8Oxyfd235PnG8raeEVeeY Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 15:00:10 -0000 On Sun, Aug 10, 2014 at 10:36:29AM -0400, John C Klensin wrote: > Security" as "if DNSSEC validates the record, then one has > assurances of the accuracy and integrity of the registrant and > registrant- DNS entry relationship" with "accuracy" and > "integrity" used in their street sense, not the much more narrow > and technical DNS and DNSSEC ones. No certification authority assures a user of the business ethics of a company. A CA may in some cases refuse to issue certificates that are misleading with respect to a company's identity, but they make no assurance that the user will not be defrauded. I, personally, find all attempts to conflate *identity* certificates with *trustworthiness* to be irresponsible hype. Neither DANE or public CAs have any business selling "trustworthiness". If users want that, then they'll need to vote with their dollars for tools that (somehow, statistically at best) provide information about the trustworthiness of a particular domain. This is a separate problem from identifying that domain. The trustworthiness tools can ONLY succeed if there is no financial relationship between the rated domain and the rating "agency". The users would have to collectively pay the rating agency tax. Otherwise, the system is a sham. Both DANE (through the registrant to registrar relationship) and public CAs are paid for the domain owner, and thus trustworthiness cannot be asserted by either. -- Viktor. From nobody Sun Aug 10 13:24:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A1B1A0115; Sun, 10 Aug 2014 13:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2ZrbSaGDJBG; Sun, 10 Aug 2014 13:24:14 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352EB1A000E; Sun, 10 Aug 2014 13:24:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 7F419DFEE; Sun, 10 Aug 2014 16:24:12 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LzIGvFK8TAa; Sun, 10 Aug 2014 16:24:11 -0400 (EDT) Received: from [192.168.3.137] (71-80-163-186.static.lsan.ca.charter.com [71.80.163.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id E6D6FDFED; Sun, 10 Aug 2014 16:24:09 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_41F17E1B-ADE1-44E2-971A-4A71FF3E1328" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Henry B Hotz In-Reply-To: <5B9A4046A1CB9ECDF6B77ACC@JcK-HP8200.jck.com> Date: Sun, 10 Aug 2014 13:24:07 -0700 Message-Id: <8C7D573E-7C30-44A2-9820-B9B470B3426E@oxy.edu> References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> <5B9A4046A1CB9ECDF6B77ACC@JcK-HP8200.jck.com> To: John C Klensin X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/UEbv3n5M1B-LCDVsra7CTB7_um0 Cc: Steve Crocker , ietf@ietf.org, saag@ietf.org, David Crocker Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 20:24:16 -0000 --Apple-Mail=_41F17E1B-ADE1-44E2-971A-4A71FF3E1328 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 10, 2014, at 7:36 AM, John C Klensin wrote: > There is one sense in which trust models based on DNSSEC that > seem to imply certification of non-DNS entities (like > registrants) are more dangerous than ones based on CA chains. > In the latter case, there are good, and obvious, analogies to > many people's everyday experience. If one finds someone who > claims to be a notary but who operates out of the back of a > taxicab, exhibits no credentials or authorization, who is > willing to certify a document with no more identification of the > signer than the ability to pay a few dollars in cash, and > trusts him to certify signatures on an important document, it is > pretty generally understood what that certification is worth. > We aren't quite there with CAs, but most people are able to at > least understand applicability of the analogy. On the other > hand, when we build a system on top of the DNS and DNSSEC, > relying on elaborate rituals like the signing of the root and > layers of processes that are, for the typical user of the > Internet, indistinguishable from magic, and fail to be clear > that, e.g., no actual certification of registrant identity or > integrity is involved, people may trust the magic rather than > trusting DNSSEC as it is. =20 There is one sense in which trust models based on DNSSEC are less = dangerous than CA chains. The keys are issued by the same people who are = responsible for directing traffic (via DNS) to a named entity, not by = some other people at a different business in another country. My = favorite example of this is the US Federal Bridge CA, which is not on = the standard browser trust lists. At the same time a number of hostile = (to the US) foreign governments *are* on those lists. Where I think we agree is that having simple, clear, and accurate = descriptions of what a technology does is critical so no one gets a = really nasty surprise. Personal email. hbhotz@oxy.edu --Apple-Mail=_41F17E1B-ADE1-44E2-971A-4A71FF3E1328 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii john-ietf@jck.com> = wrote:
seem to imply certification of non-DNS = entities (like
registrants) are more dangerous than = ones based on CA chains.
In the latter case, there are = good, and obvious, analogies to
many people's everyday = experience.  If one finds someone who
claims to be a notary but who = operates out of the back of a
taxicab, exhibits no = credentials or authorization, who is
willing to certify a document = with no more identification of the
signer than the ability to = pay a few dollars in cash,  and
trusts him to certify = signatures on an important document, it is
pretty generally understood = what that certification is worth.
We aren't quite there with = CAs, but most people are able to at
least understand = applicability of the analogy.  On the other
layers of processes that are, for the = typical user of the
Internet, indistinguishable = from magic, and fail to be clear
that, e.g., no actual = certification of registrant identity or
integrity is involved, people = may trust the magic rather than
trusting DNSSEC as it is. =  

There is = one sense in which trust models based on DNSSEC are less dangerous than = CA chains. The keys are issued by the same people who are responsible = for directing traffic (via DNS) to a named entity, not by some other = people at a different business in another country. My favorite example = of this is the US Federal Bridge CA, which is not on the standard = browser trust lists. At the same time a number of hostile (to the US) = foreign governments *are* on those lists.

Where = I think we agree is that having simple, clear, and accurate descriptions = of what a technology does is critical so no one gets a really nasty = surprise.

Personal = email.  hbhotz@oxy.edu



= --Apple-Mail=_41F17E1B-ADE1-44E2-971A-4A71FF3E1328-- From nobody Sun Aug 10 13:30:14 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D2E1A011E for ; Sun, 10 Aug 2014 13:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9M92Ab2-Pch for ; Sun, 10 Aug 2014 13:30:12 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9CAF1A000E for ; Sun, 10 Aug 2014 13:30:11 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F38C72AAC74; Sun, 10 Aug 2014 20:30:10 +0000 (UTC) Date: Sun, 10 Aug 2014 20:30:10 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140810203010.GL14392@mournblade.imrryr.org> References: <5B9A4046A1CB9ECDF6B77ACC@JcK-HP8200.jck.com> <20140810173503.86832.qmail@joyce.lan> <20140810181807.GA84281@mx1.yitter.info> <53E7C9A9.9090006@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53E7C9A9.9090006@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/MxpBXCOm8jd_QXFOCgEVURhaqNE Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 20:30:13 -0000 On Mon, Aug 11, 2014 at 07:36:09AM +1200, Brian E Carpenter wrote: > What people are pointing out is that this is no better, and no worse, > than the seal on a snake oil bottle proving that the snake oil > has not been tampered with since it left the factory. > > Unfortunately, the average user can easily confuse that with an > assurance that the snake oil will cure your illness. There isn't > much we can do to change that. Sure we can, we can stop promoting marketing hype. An honest statement I am happy to stand by is: DNSSEC and DANE help ensure that your connection to the scumbag you connected to who's trying to cheat you out of your money is not tampered with by another scumbag trying to cheat you out of your money. DKIM and DMARC do not prevent 419 scams and phishing. Certification authorities don't stop fraudulent business practices, ... Promising them any of those things is the problem. Failing to deliver what ought not have been promised is not the problem. -- Viktor. From nobody Sun Aug 10 19:59:23 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351091A028B; Sun, 10 Aug 2014 19:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ny6jSjD3Iia; Sun, 10 Aug 2014 19:59:15 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D4B1A028E; Sun, 10 Aug 2014 19:59:15 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 7BD0C1FCBC7; Mon, 11 Aug 2014 02:59:11 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5F833160064; Mon, 11 Aug 2014 03:09:46 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id F21C216005B; Mon, 11 Aug 2014 03:09:45 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 233591CAFBD6; Mon, 11 Aug 2014 12:59:06 +1000 (EST) To: John C Klensin From: Mark Andrews References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> <5B9A4046A1CB9ECDF6B77ACC@JcK-HP8200.jck.com> In-reply-to: Your message of "Sun, 10 Aug 2014 10:36:29 -0400." <5B9A4046A1CB9ECDF6B77ACC@JcK-HP8200.jck.com> Date: Mon, 11 Aug 2014 12:59:06 +1000 Message-Id: <20140811025906.233591CAFBD6@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/saag/TIQ8D9xsY0kft1yMauDvNoKR3BQ Cc: Steve Crocker , ietf@ietf.org, saag@ietf.org, David Crocker Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 02:59:17 -0000 In message <5B9A4046A1CB9ECDF6B77ACC@JcK-HP8200.jck.com>, John C Klensin writes : > > > The authenticity and integrity go hand in hand. The party > > looking up a domain name wants to know if the answer is > > correct. "Correct" in this context means that it was > > provided by the party that is authorized to provide it, i.e. > > the domain owner, and that the information hasn't been > > modified along the path to the user. That's integrity and > > authenticity combined. > > Steve, while I clearly agree with the above, I was trying to get > at the point that there are other elements that people might > reasonably consider part of authenticity. One is whether the > apparent domain is what it appears to be. Another is whether > the apparent domain owner is who it appears or claims to be. > That, in turn, is closely connected to the question of whether > there is enough information available to even determine what > ownership assertion is being made, i.e., whether the > user-accessible part of the registry database contains > information about the domain owner or merely some proxy or > "hidden registration" information that points to an entity that > conceals identities for hundreds or thousands of such domains. DANE isn't trying to be more than "DV". DNSSEC doesn't try to do more than "the answer matches what was entered in the zone for both positive and negative result". Both of those are actually very powerful. They don't however protect against someone registering microsoft.example.com and publishing a CERT for that name. For SMTP DV and assurance that the MX records or lack there of are not tamperered with is exactly what you want. You really don't care who the hoster is, just that you are talking to the authorised hoster. A similar thing for SUBMISSION. You really don't care about who is hosting the server for a domain as long as you can securely go from the domain to the submission server. For email you can get that user@domain sent the message. You don't get the linkage that "This Person" sent the message. Now for HTTP there are times when you care about whether a EV certificate is presented or not. At other times you only care that it matches the domain you are connecting to or not. > From those perspectives, a registrar or registry who might > collude with a criminal registrant to create deliberately > deceptive names and associated registration data (or whose > procedures allow similar results without explicit collusion) is > fully as much part of the threat model as a CA that issues > certificates without any attempt to verify the identity of the > entity being certified or who colludes in deliberately hiding or > distorting the information. > > Now "we" all know that has nothing to do with DNSSEC. It > provides assurance that what is in an authoritative zone and > what reaches the systems closest to the user that actually > validates the signatures and records are the same. But I'm > concerned that it gets oversold to the point that users and > others in the name-using environment hear what we say about "DNS > Security" as "if DNSSEC validates the record, then one has > assurances of the accuracy and integrity of the registrant and > registrant- DNS entry relationship" with "accuracy" and > "integrity" used in their street sense, not the much more narrow > and technical DNS and DNSSEC ones. > > Where that loops back to things like DANE is that DANE, at least > apparently, is making assertions about the identity of an > individual or other entity, not [merely] about validation of the > relationship of DNS records as installed/created in comparison > to those received. As with DNSSEC itself, that isn't a problem > if DANE is used carefully and with an understanding of what > assertions are being made and can be trusted. It could be a > significant problem if people over-promise (or over-believe) and > the use of DANE for critical functions becomes widespread enough > to become a tempting target for attacks of technical and/or > social or economic character (just as we have seen on CAs). DANE is only promising "DV" level certs. It can however disprove a invalid "EV" cert. If a "EV" cert is referenced in a TLSA record the difference between DV and EV comes from the CA not DNSSEC. > There is one sense in which trust models based on DNSSEC that > seem to imply certification of non-DNS entities (like > registrants) are more dangerous than ones based on CA chains. > In the latter case, there are good, and obvious, analogies to > many people's everyday experience. If one finds someone who > claims to be a notary but who operates out of the back of a > taxicab, exhibits no credentials or authorization, who is > willing to certify a document with no more identification of the > signer than the ability to pay a few dollars in cash, and > trusts him to certify signatures on an important document, it is > pretty generally understood what that certification is worth. > We aren't quite there with CAs, but most people are able to at > least understand applicability of the analogy. On the other > hand, when we build a system on top of the DNS and DNSSEC, > relying on elaborate rituals like the signing of the root and > layers of processes that are, for the typical user of the > Internet, indistinguishable from magic, and fail to be clear > that, e.g., no actual certification of registrant identity or > integrity is involved, people may trust the magic rather than > trusting DNSSEC as it is. DNSSEC and DANE certify that the domain name holder added the linkage from the domain -> cert. CA's try to go from the CERT -> domain but they are not part of the delegation process for domains so one can never be sure. Basically CERT's have been oversold for decades. > That, in turn, could lead to some really nasty surprises --and > loss of confidence in us and the institutions we ask people to > trust-- when the bad effects of that misunderstanding manifest > themselves in a damaging and public attack. > > best, > john > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Aug 10 23:16:32 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86731A0316; Sun, 10 Aug 2014 23:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niv2UF0idV9F; Sun, 10 Aug 2014 23:16:27 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6669E1A0314; Sun, 10 Aug 2014 23:16:27 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 35D4C674057; Sun, 10 Aug 2014 23:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=IKNXdE+ipFW5UK 66kpsfFi7zgWI=; b=l4s0vocKG5rRS44c/wxIbiH0ZNuzNSQn3OoAqjgjsJrM+c XuHjfTTtnTRZEjqrKoRSAs8OEnh/nR0/T2jOxtolcSyjPCS2OfaQYhqg51dV2NaX 7J6mtzHL9vjG/ePD9j0ZSioKkux9v6mjwG/tZFbcAWvVem+MDf3tAR2XDm0Wc= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id B7F54674070; Sun, 10 Aug 2014 23:16:26 -0700 (PDT) Date: Mon, 11 Aug 2014 01:16:26 -0500 From: Nico Williams To: John C Klensin Message-ID: <20140811061623.GA21783@localhost> References: <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> <5B9A4046A1CB9ECDF6B77ACC@JcK-HP8200.jck.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B9A4046A1CB9ECDF6B77ACC@JcK-HP8200.jck.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/tPpP5pB6BN7S9UnHQispHu8-Pbw Cc: Steve Crocker , ietf@ietf.org, saag@ietf.org, David Crocker Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 06:16:28 -0000 On Sun, Aug 10, 2014 at 10:36:29AM -0400, John C Klensin wrote: > [...] DNSSEC is most decidedly a PKI, with roughly the same security and naming semantics as PKIX, differing only in the details. DNSSEC is also decidedly superior to the Web PKI, mainly because DNSSEC has strong naming constraints, while the Web PKI has none to speak of, and because DNSSEC truly has a single root (for now) and is truly hierarchical, while the neither is true of the Web PKI. As far as naming goes, both PKI and DNSSEC have equivalent semantics for what PKIX calls dNSName. There are names that PKIX supports or could that DNSSEC can't easily, but that's of little interest here. DNSSEC has nothing like CPS, but CPS is a fiction, and if it weren't it could easily be added to DNSSEC anyways. DNSSEC does have problems: - The same "CAs can MITM" problem as PKIX. DNSSEC is much better than the Web PKI for this because there's many fewer CAs (registrars) that can MITM any given domain in DNSSEC than in the Web PKI. - DNSSEC does not provide confidentiality of protection for lookups and answers (while PKIX has no real directory service to speak of). - DNSSEC currently uses relatively small RSA keys, and large keys make for amplification attack problems. This can be fixed by sprinkling some DJB crypto technology, namely EdDSA. By all means talk about the above problems if you like, but don't spread FUD about DNSSEC. DNSSEC is absolutely not worse than the Web PKI (unless you think the small RSA keys are a bigger problem than all the problems the Web PKI has, and if you do, I've a bridge to sell you). Nico -- From nobody Sun Aug 10 23:20:41 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C87D1A031C; Sun, 10 Aug 2014 23:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaSaIi6dbmSH; Sun, 10 Aug 2014 23:20:35 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id ECF111A031B; Sun, 10 Aug 2014 23:20:34 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id CE339B8058; Sun, 10 Aug 2014 23:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=FS2Uf/eQ5sEsPb GgtIthg0WqHq8=; b=I9XJz3db2Dda/D0TDiKxVEANI9feTfcaS8pO/ybno0r9De 5ArzmLX5MoqhZRMb6DX9IY8/pMyVwelajdogRr+u4UMGD8CGmQ0QiuDLmoldPPCc b6Odp/dnBq8y7t1k/11XdHswhpvdBwhZtOxc2tfs6ZNmPnUejUPj91CWAzeBA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPA id 608C5B8057; Sun, 10 Aug 2014 23:20:34 -0700 (PDT) Date: Mon, 11 Aug 2014 01:20:33 -0500 From: Nico Williams To: John C Klensin Message-ID: <20140811062032.GB21783@localhost> References: <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> <5B9A4046A1CB9ECDF6B77ACC@JcK-HP8200.jck.com> <20140811061623.GA21783@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140811061623.GA21783@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ft0Ou8kP-X9wfYTYWk91NC9JNu0 Cc: David Crocker , ietf@ietf.org, saag@ietf.org Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 06:20:36 -0000 On Mon, Aug 11, 2014 at 01:16:26AM -0500, Nico Williams wrote: > - DNSSEC does not provide confidentiality of protection for lookups and > answers (while PKIX has no real directory service to speak of). Arg, protection of confidentiality. DNSSEC does provide integrity proection. Which is to say: authentication of data and its origin (assuming honest and secure registrars, just like one has to assume honest and secure CAs in the PKIX model). Nico -- From nobody Sun Aug 10 23:56:21 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EA41A0337 for ; Sun, 10 Aug 2014 23:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK5rzcYR8YT6 for ; Sun, 10 Aug 2014 23:56:18 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45BC1A0334 for ; Sun, 10 Aug 2014 23:56:18 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1XGjWh-0001vA-Fe; Mon, 11 Aug 2014 06:56:16 +0000 Date: Mon, 11 Aug 2014 14:56:13 +0800 Message-ID: From: Randy Bush To: Nico Williams In-Reply-To: <20140811062032.GB21783@localhost> References: <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> <5B9A4046A1CB9ECDF6B77ACC@JcK-HP8200.jck.com> <20140811061623.GA21783@localhost> <20140811062032.GB21783@localhost> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/saag/vFaoj4ZoWiLG2tRXVIjbpkbv3-4 Cc: saag@ietf.org Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 06:56:19 -0000 [ most cc:s removed ] > DNSSEC does provide integrity proection. Which is to say: > authentication of data and its origin (assuming honest and secure > registrars, just like one has to assume honest and secure CAs in the > PKIX model). dnssec does not provide authentication of origin and does not need to do so. it provides object authentication irrespective of who threw the object at you. there could be 42 monkeys in the middle and it will make no difference as you can verify that they threw authentic bananas. randy From nobody Mon Aug 11 08:01:18 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616171A0655; Sat, 9 Aug 2014 09:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exwN_igEKVug; Sat, 9 Aug 2014 09:31:10 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id BDDC01A064B; Sat, 9 Aug 2014 09:31:10 -0700 (PDT) Received: from dummy.name; Sat, 09 Aug 2014 16:31:10 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Steve Crocker In-Reply-To: <53E64B66.4000203@dcrocker.net> Date: Sat, 9 Aug 2014 12:31:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> To: David Crocker X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/2hYFnOY2BYrayNZvqlZR9OLyDnA X-Mailman-Approved-At: Mon, 11 Aug 2014 08:01:16 -0700 Cc: John C Klensin , "Stephen D. Crocker" , saag@ietf.org, ietf@ietf.org Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 16:31:12 -0000 The authenticity and integrity go hand in hand. The party looking up a = domain name wants to know if the answer is correct. =93Correct=94 in = this context means that it was provided by the party that is authorized = to provide it, i.e. the domain owner, and that the information hasn=92t = been modified along the path to the user. That=92s integrity and = authenticity combined. Steve On Aug 9, 2014, at 12:25 PM, Dave Crocker wrote: > On 8/6/2014 3:39 PM, John C Klensin wrote: >> the discussion suggests noting, again, the very limited >> nature of what DNSSEC actually protects. It is ultimately an >> integrity test within the DNS hierarchy.=20 >=20 >=20 > This is such a fundamental point and of such broad community = relevance, > it's important we have clarity about it. >=20 > I have always understood DNSSec to provide /authentication > for DNS data/, specifically that the data were put there > are under the authority of the domain name owner. >=20 > The signing hierarchy (up to the root, when full DNSSec signing is = used) > certifies the authenticity of the domain owner's signature. >=20 > Data integrity is an important side-effect of crypto signing > methodology. However I'm not used to seeing it classed as the primary > purpose of DNSSec, with no mention of authentication. >=20 > It would be helpful for DNSSec experts to provide clear, simple, > definitive statements on this. >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Mon Aug 11 08:01:20 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759F21A0347; Sat, 9 Aug 2014 15:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecQF8pS6wWlP; Sat, 9 Aug 2014 15:21:41 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607C61A01E5; Sat, 9 Aug 2014 15:21:41 -0700 (PDT) Received: from [192.168.0.3] (cpe-23-241-118-60.socal.res.rr.com [23.241.118.60]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s79MKp2Z012829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 9 Aug 2014 15:21:08 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=windows-1252 From: manning In-Reply-To: Date: Sat, 9 Aug 2014 15:20:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6D6BB793-E7FF-4F4B-ABFF-60B8BCFF6ADD@karoshi.com> References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> To: Donald Eastlake X-Mailer: Apple Mail (2.1878.2) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@karoshi.com Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Jt-2uk8Xi3BeldONE3dqWRuiSI8 X-Mailman-Approved-At: Mon, 11 Aug 2014 08:01:15 -0700 Cc: Paul Wouters , "saag@ietf.org" , IETF Discussion Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 22:21:44 -0000 all of this is true=85 ONLY to the extent that you have, in your = possession and properly configured (AT YOUR OWN NODE) a verified Trust Anchor - AND if the chain of custody terminates at one = of the Trust Anchors you have configured. Almost the same model as the CA keys stored in your browser=85 =20 A presumptive is that folks will care for and actively manage their = Trust Anchors. Just like folks care for and actively manage their Browser Certificates. As usual, YMMV and your vendor may or may not agree with your trust = profile or allow you to set it. /bill On 9August2014Saturday, at 14:34, Donald Eastlake = wrote: > Just to point out that DNSSEC authenticates data even in the case of > null data; that is, it provide authenticated denial of the existence > of data. >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com >=20 >=20 > On Sat, Aug 9, 2014 at 1:03 PM, Paul Wouters wrote: >> On Sat, 9 Aug 2014, Dave Crocker wrote: >>=20 >>> Data integrity is an important side-effect of crypto signing >>> methodology. However I'm not used to seeing it classed as the = primary >>> purpose of DNSSec, with no mention of authentication. >>=20 >>=20 >> In the mid ninetees when dnssec was worked on, there were two camps. = The >> DNS people who wanted to only secure DNS and explicitely did NOT >> want the DNS to become a PKI. And those that mainly wanted secure >> DNS to make a new PKI (eg Gilmore and the FreeS/WAN people). This >> fight continued throughout, and is the reason KEY/SIG/NXT changed to >> DNSKEY/RRSIG/NSEC. The change dictated those records were for DNS = only >> and not for use by applications as PKI. >>=20 >> So the PKI people had to silently go along with the DNS people to >> write and deploy DNSSEC, so that they could add their RRTYPE's for a >> PKI later even if the DNS people hated the idea. That is why you = don't >> see it listed anywhere in any document as a purpose of DNSSEC. >>=20 >> Paul >>=20 >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 From nobody Mon Aug 11 08:01:22 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869E01A03BE; Mon, 11 Aug 2014 03:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iI3BmUNbMfu6; Mon, 11 Aug 2014 03:09:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B4F1A03CF; Mon, 11 Aug 2014 03:08:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLC49296; Mon, 11 Aug 2014 10:08:58 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0158.001; Mon, 11 Aug 2014 11:08:54 +0100 From: Hosnieh Rafiee To: "saag@ietf.org" , "ipv6@ietf.org" Thread-Topic: New Version Notification for draft-rafiee-rfc3972-bis-00.txt Thread-Index: AQHPtUu1hZVwp9zHy0mEie4X4EglR5vLLOLA Date: Mon, 11 Aug 2014 10:08:54 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A25B4C@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Qsx8BrzFKc1jVrgX2DRtX8grupg X-Mailman-Approved-At: Mon, 11 Aug 2014 08:01:15 -0700 Subject: [saag] FW: New Version Notification for draft-rafiee-rfc3972-bis-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 10:09:04 -0000 Rm9sa3MsDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IHRoYXQgYWRkcmVzc2VzIHNv bWUgcHJvYmxlbXMgd2l0aCBDR0Egc3BlY2lmaWNhdGlvbi4gDQpUaGlzIGlzIHRoZSBzb2x1dGlv bnMgdG8gYXR0YWNrcyBleHBsYWluZWQgaW4gdGhlIGZvbGxvd2luZyBkcmFmdCBhbmQgYWxzbyB0 aGUgZGlzY3Vzc2lvbiBhYm91dCB2YXJpYWJsZSBsZW5ndGggcHJlZml4IGFuZCB0aGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbiBmb3IgQ0dBLg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtcmFmaWVlLTZtYW4tY2dhLWF0dGFjay0wMg0KDQpXZSdsbCBiZSBnbGFkIHRvIHJlY2VpdmUg eW91ciBjb21tZW50cy4NCg0KQmVzdCwNCkhvc25pZWgNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEF1Z3VzdCAxMSwgMjAxNCAxMjowNSBQTQ0K VG86IEhvc25pZWggUmFmaWVlOyBaaGFuZ2RhY2hlbmcgKERhY2hlbmcpOyBIb3NuaWVoIFJhZmll ZTsgWmhhbmdkYWNoZW5nIChEYWNoZW5nKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1yYWZpZWUtcmZjMzk3Mi1iaXMtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LXJhZmllZS1yZmMzOTcyLWJpcy0wMC50eHQgaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBIb3NuaWVoIFJhZmllZSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG IHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1yYWZpZWUtcmZjMzk3Mi1iaXMNClJldmlzaW9u OgkwMA0KVGl0bGU6CQlDR0EgU2VjdXJpdHkgSW1wcm92ZW1lbnQNCkRvY3VtZW50IGRhdGU6CTIw MTQtMDgtMTENCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTYNClVSTDog ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yYWZp ZWUtcmZjMzk3Mi1iaXMtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtcmFmaWVlLXJmYzM5NzItYmlzLw0KSHRtbGl6ZWQ6ICAgICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJhZmllZS1yZmMzOTcyLWJpcy0wMA0K DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBhZGRyZXNzZXMgdGhlIHNlY3VyaXR5IHBy b2JsZW1zIGV4aXN0aW5nIGluIHRoZSBjdXJyZW50DQogICBDR0Egc3BlY2lmaWNhdGlvbi4gSXQg YWxzbyBleHBsYWluIHRoZSBjaGFuZ2VzIHRoYXQgaXMgbmVlZGVkIHRvIHRha2UNCiAgIGludG8g Y29uc2lkZXJhdGlvbiB3aGVuIHRoZSBwcmVmaXggbGVuZ3RoIG5lZWRzIHRvIGJlIHZhcmlhYmxl Lg0KDQoNCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Mon Aug 11 08:04:00 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DD31A0451 for ; Mon, 11 Aug 2014 08:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqJlW1HvcuUp for ; Mon, 11 Aug 2014 08:03:54 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8687F1A03DF for ; Mon, 11 Aug 2014 08:03:54 -0700 (PDT) Received: from tormenta.lan (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 4411D6D775; Mon, 11 Aug 2014 11:03:50 -0400 (EDT) Message-ID: <53E8AB19.1010303@iang.org> Date: Mon, 11 Aug 2014 12:38:01 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> <5B9A4046A1CB9ECDF6B77ACC@JcK-HP8200.jck.com> In-Reply-To: <5B9A4046A1CB9ECDF6B77ACC@JcK-HP8200.jck.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/w36W1j0SJ7-IfjtZYA65yHDjq9w Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 15:03:56 -0000 On 10/08/2014 15:36 pm, John C Klensin wrote: > That, in turn, could lead to some really nasty surprises --and > loss of confidence in us and the institutions we ask people to > trust-- when the bad effects of that misunderstanding manifest > themselves in a damaging and public attack. The only way people figure out the limits of a new technology is by nasty surprises. We've had our nasty surprises with the CA industry -- it's basically worthless for any user's needs to place trust in it -- and the sooner we get on with discovering how surprising or otherwise DANE et al is the better for all concerned. iang From nobody Mon Aug 11 12:09:11 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9A61A0061 for ; Mon, 11 Aug 2014 12:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuzV6BQHTwNX for ; Mon, 11 Aug 2014 12:09:09 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8E31A005E for ; Mon, 11 Aug 2014 12:09:09 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 258E1202038; Mon, 11 Aug 2014 12:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=liSht2Bftk5UBd +sbSWmGQSriss=; b=DCpRiB2nUFy0FQ2sElLL5BZtThgmBCJNIOb4Z5Z0zuispe BkDr10RtKH2fkgTTdissil899kpWvBHL15eZaR3vLD1iwU2ZnNdW01TgsVd0TbB5 HGtHXNyMaDlVCaWROeluRm7ipKgFnM7tNSVk79pEEgh+QYwZRpKyQUYOj6Hbs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPA id 9AD51202044; Mon, 11 Aug 2014 12:09:08 -0700 (PDT) Date: Mon, 11 Aug 2014 14:09:07 -0500 From: Nico Williams To: Randy Bush Message-ID: <20140811190905.GF21783@localhost> References: <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> <5B9A4046A1CB9ECDF6B77ACC@JcK-HP8200.jck.com> <20140811061623.GA21783@localhost> <20140811062032.GB21783@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/2ASXrLlvAvR3qMxkpVrDTqUhk5Q Cc: saag@ietf.org Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 19:09:10 -0000 On Mon, Aug 11, 2014 at 02:56:13PM +0800, Randy Bush wrote: > [ most cc:s removed ] > > DNSSEC does provide integrity proection. Which is to say: > > authentication of data and its origin (assuming honest and secure > > registrars, just like one has to assume honest and secure CAs in the > > PKIX model). > > dnssec does not provide authentication of origin and does not need to do > so. it provides object authentication irrespective of who threw the > object at you. there could be 42 monkeys in the middle and it will make > no difference as you can verify that they threw authentic bananas. Did you think I meant "server" by "origin"? IMO my text was clear that I meant "registrar" (or: the entity signing the RRSet anyways). At any rate, all we need is to authenticate the "bananas" as you put it. I.e., DNSSEC is good enough for the purposes of things like DANE. And DANE is good enough for a lot of application protocols. As for other (actual) objections, if it truly mattered we'd add something like CPS to DNSSEC. Nico -- From nobody Tue Aug 12 05:10:29 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836341A0818 for ; Tue, 12 Aug 2014 05:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6yZmU6PrIBy for ; Tue, 12 Aug 2014 05:10:27 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A23A1A07D1 for ; Tue, 12 Aug 2014 05:10:27 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 02E796D6C0; Tue, 12 Aug 2014 08:10:23 -0400 (EDT) Message-ID: <53EA042E.70801@iang.org> Date: Tue, 12 Aug 2014 13:10:22 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rr_OGzOnWxEaCqRDlH2guRM6ABY Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 12:10:28 -0000 On 9/08/2014 17:31 pm, Steve Crocker wrote: > The authenticity and integrity go hand in hand. The party looking up a domain name wants to know if the answer is correct. “Correct” in this context means that it was provided by the party that is authorized to provide it, i.e. the domain owner, and that the information hasn’t been modified along the path to the user. That’s integrity and authenticity combined. Yes, we want it all, "correct". But the problem with each of these concepts is that they are uncertain at their core. E.g., "authorised to provide it" is based on a human process that can be tricked. "information hasn't been modified on path" is likewise something that is easy to fiddle at the endpoints. The better way to treat this is to couple a reasonable approach to authenticity with a reasonable approach to integrity, where the "reasonable" level in each is balanced to the weaknesses of the other. No point in coupling a supertanker anchor chain to a bikelock... Now, the problem in the large is that we don't know really how to build this balance so successfully. Hence: >> It would be helpful for DNSSec experts to provide clear, simple, >> definitive statements on this. Opportunistic Security recognises that the balance can be hard; it says don't couple them rigidly, do the best you can independently, and let's see what works. iang From nobody Fri Aug 15 10:36:04 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8391A00FE for ; Fri, 15 Aug 2014 10:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUqs1p7-yIOw for ; Fri, 15 Aug 2014 10:36:01 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F36991A00ED for ; Fri, 15 Aug 2014 10:36:00 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6D21A2AB256; Fri, 15 Aug 2014 17:36:00 +0000 (UTC) Date: Fri, 15 Aug 2014 17:36:00 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140815173600.GS5476@mournblade.imrryr.org> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53EE2D2A.5020000@dcrocker.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Rb2a8q2qTRDLoTPSxIg9MPmSsng Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 17:36:03 -0000 On Fri, Aug 15, 2014 at 08:54:18AM -0700, Dave Crocker wrote: > > Designing and deploying a key management for the whole Internet is > > for now an unsolved problem. Oops the word "system" got lost after "key management"... Will have to add that back when I next get a chance. > > The opportunistic security design pattern involves stepping up from a > > baseline security policy compatible with all relevant peers to the > > most secure policy compatible with the capabilities of a given peer. > Actually, it involves stepping /down/. The draft is providing a *definition*. Definitions should be taken at face value. This is not an empirical statement whose truth one can debate, it is a definition. > > A related goal is broader adoption of protection against active > > attacks, by enabling incremental deployment of authenticated > > encryption. > > Although this sounds entirely reasonable, there is no explanation > provided to make it credible. (n fact it is not at all clear to me that > is /us/ credible...) How will use of an opportunistic pattern lea to > broader adoption? By enabling deployment that is incremental and yet on by default. With "all or nothing" security there is no way to allow the network effect to help reach near-universal adoption. > > Both opportunistically > > employed encryption and opportunistically employed authentication > > need to avoid deployment roadblocks and need to be designed with care > > to "just work". > > I have no idea what the last sentence means. It means mechanisms that consistently work out of the box, no need to tune explicitly for each peer or prompt the user when they predictably fail a significant fraction of the time. > > Opportunistic security does not start with an over-estimate of peer > > capabilities only to settle for lesser protection when a peer fails > > to deliver. Rather, opportunistic security sets a minimum protection > > level expected of all peers, which is raised for peers that are > > capable of more. > > This paragraph is not very helpful. The issue here has nothing to do > with estimation. (Can a design pattern make an estimation?) An estimate is what one has, when one has not ye performed the measurement. Perhaps a better word could be crafted here, suggestions? I still think the original text is sufficient. The first sentence is what you're consistently not taking at face value, the point needs to be made. > If authentication is required, we have classic authenticated encryption, > not opportunistic . Again no, you're still reading what you would have said, rather than what the draft actually says. The draft actually defines a way to do "opportunistically employ" authentication. And this is important, and is the main point of departure from Steve Kent's earlier draft. "Required of all peers" is not opportunistic. Required when advertised By a given peer > The 'opportunistic' construct is all about permitting lesser protection. > If it isn't permitted, we are not in an opportunistic scenario. Again, that's not the *definition* in this draft. You might have defined it that way, but this draft does not. > The term needs to be quite disciplined about what is excluded and what > is included. As soon as the term is too broad, it is meaningless. No, not meanigless, just not the meaning some would have come up with. > > Enforcement of authentication is not incompatible with opportunistic > > security. If an OS-enabled peer (A) makes available authenticated > > key material, e.g., via DANE, to peer (B), then B should make use of > > this material to authenticate A, if B is OS-enabled and supports > > DANE. > > This is worded a bit differently than in the preview draft I saw, but I > still have no idea what that sentence means. The language that follows > is about preference, not enforcement. > > Ultimately I can't tell what the motivation for this sentence is. You're still not reading the definitions as stated. > > If authentication is only possible for some peers, then it is > > acceptable to authenticate only those peers and not the rest. > > It is only sometimes acceptable. It is essential that the text here > highlight that such a fallback needs to be the result of careful > analysis and choice and not a casual default. There is no fallback from a suitably advertised capability to be authenticated (e.g. via DANE). Similarly the TACK draft is a type of opportunistically enabled authentication that is more of the TOFU style. > > > > Employ PFS: Opportunistic Security should employ Perfect Forward > > Secrecy (PFS) to protect previously recorded encrypted > > communication from decryption even after a compromise of long-term > > keys. > > I'm told that PFS isn't really possible for asyncrhonous, object-based > encryption, such as for email. PFS works for hop-by-hop SMTP, but yes, not likely for end-to-end S/MIME or PGP. This could be qualified with "when possible" or some such. > > No misrepresentation of security: > > > > Unauthenticated encrypted communication must not be misrepresented as > > communication over a secure channel. > > Oh boy. That sentence is far too compact and not obviouly correct. In > fact it is arguably wrong. That's the -02 draft text you're responding to. > > In summary, the opportunistic security design pattern encompasses > > protocol designs that remove barriers to the widespread use of > > encryption on the Internet. The actual protection provided by > > opportunistic security depends on the advertised capabilities of the > > communicating peers. Opportunistic security aims to encrypt all > > network traffic, while allowing fallback to cleartext with peers that > > do not appear to be encryption capable. > > Ran out of time. Haven't reviewed the remainder... So is this. > > > 5. Example: Opportunistic TLS in SMTP > > > > Many Message Transfer Agents (MTAs, [RFC5598]) support the STARTTLS > > ([RFC3207]) ESMTP extension. MTAs acting as SMTP clients are > > generally willing to send email without TLS (and therefore without > > Software does not have a 'will'. I think what is meant here is 'able'. Except that we're describing tolerated lower-bounds, not abilities. > > Therefore, MTAs that implement opportunistic TLS either employ > > unauthenticated encryption or deliver over a cleartext channel. > > deliver -> transmit Sure. > > Recent reports from a number of large providers suggest that the > > majority of SMTP email transmission on the Internet is now encrypted, > > and the trend is toward increasing adoption. > > This anecdotal comment isn't needed, isn't substantiated, and is going > to be distracting when this document is read 20 years from now. I > suggest removing it. The example is an anectote, a protocol case-study if you like, not a specification. It is I think useful to highlight a success of OS in this space. > > > Not only is the STARTTLS advertisement vulnerable to active attacks, > > but also at present some MTAs that advertise STARTTLS exhibit various > > interoperability problems in their implementations. As a result, it > > Again, the ephemeral frame of refernce won't be helpful. > > So: > > but also an MTA that advertises STARTTLS can produce various > interoperability problems in its implementation. As a result, it might > choose to fall back to cleartext... Except that the wisdom of the cleartext retry is rooted in the operational status-quo. When the interoperability issues with clunky old MTAs fade away, the engineering trade-off will be different. > > 6. Security Considerations > > > > Though opportunistic security potentially supports transmission in > > cleartext, unauthenticated encryption, or other cryptographic > > protection levels short of the strongest potentially applicable, the > > effective security for peers is not reduced. If a cryptographic > > capability is neither required by policy nor supported by the peer, > > nothing is lost by going without. Opportunistic security is strictly > > stronger than the alternative of providing no security services when > > maximal security is not applicable. > > I'll repeat that counting "cleartext" as part of an opportunistic > pattern is a strategic error. In simple terms, it is saying that no > security is part of security. Yes, in order to make security usable, we tolerate no security as a baseline where required. > The issue is not that cleartext is bad or that permitting it might not > be ok. It's that it needs to be outside of the scope of an > opportunistic pattern. Disagree. Otherwise we get into "fallback" and all that, but OS is about attempting to get more than minimum (possibly none) security. Not about settling for less. As defined! Not empirical fact to debate. You could argue for a different definition, but it should be clear that you'd prefer a different formulation, not that the current one is "wrong". > > Opportunistic security coexists with and is preempted by any > > applicable non-opportunistic security policy. However, such non- > > This first sentence makes no real sense to me or worse is confusing. It > does not "coexist". If it is preempted, it is at best subordinated. Well, coexists and is subordinate to. But that is clearly evident from the text... -- Viktor. From nobody Fri Aug 15 12:11:36 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422431A02F9; Fri, 15 Aug 2014 12:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-itZFBYEetW; Fri, 15 Aug 2014 12:11:32 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A761A030E; Fri, 15 Aug 2014 12:11:30 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8DEAC2AB29E; Fri, 15 Aug 2014 19:11:29 +0000 (UTC) Date: Fri, 15 Aug 2014 19:11:29 +0000 From: Viktor Dukhovni To: ietf@ietf.org Message-ID: <20140815191129.GV5476@mournblade.imrryr.org> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/3cI8kYaop_uPp4S5vWihQ4gMv3A Cc: saag@ietf.org Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ietf@ietf.org, saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 19:11:33 -0000 On Fri, Aug 15, 2014 at 03:01:59PM -0400, Paul Wouters wrote: > Background Encryption ? > Preemptive Encryption ? > Preventive Encryption ? > Preventative Encryption ? > Countermeassure Encryption ? > Remedial Encryption ? This boat has sailed: TLS -> TLE: Transport Layer Encryption? IPsec -> IPenc: IP encryption? SSH -> ESH: Encrypted SHell? HTTPS -> HTTPE: HTTP over TLE? ... Let's talk about the substance of the draft. -- Viktor. From nobody Fri Aug 15 13:29:24 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EECD1A0481; Fri, 15 Aug 2014 13:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DzFckHnKov3; Fri, 15 Aug 2014 13:29:14 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0811A0476; Fri, 15 Aug 2014 13:29:13 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1973280048; Fri, 15 Aug 2014 16:29:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1408134553; bh=F/Jc+sltNVJj5U59z48c2ZE/uK1DRSdG9LooXs3rEi8=; h=Date:From:To:Subject:In-Reply-To:References; b=Bh2XkQwxfgV3RKtShJtRMhYBkZJQbw/Xk6MBj6dgOTBEQPIp71emiPv5g+7n4MNxW pIH/7K4NeByQUYkSlTRR0qTltScz8X05sHYs8UOlSB3jrwevVKaH3lObkjEfgYUZPp Hn0oiDW5TnfKxmTzKbuiZ0BGHi4FAeuo+/HfQjcY= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s7FKTChm024066; Fri, 15 Aug 2014 16:29:12 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 15 Aug 2014 16:29:12 -0400 (EDT) From: Paul Wouters To: ietf@ietf.org, saag@ietf.org In-Reply-To: <20140815191129.GV5476@mournblade.imrryr.org> Message-ID: References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/e3E9QBE1tDgZNR8LSXqCZ6uG1nE Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 20:29:19 -0000 On Fri, 15 Aug 2014, Viktor Dukhovni wrote: > On Fri, Aug 15, 2014 at 03:01:59PM -0400, Paul Wouters wrote: > >> Background Encryption ? >> Preemptive Encryption ? >> Preventive Encryption ? >> Preventative Encryption ? >> Countermeassure Encryption ? >> Remedial Encryption ? > > This boat has sailed: > > TLS -> TLE: Transport Layer Encryption? > IPsec -> IPenc: IP encryption? > SSH -> ESH: Encrypted SHell? > HTTPS -> HTTPE: HTTP over TLE? > ... All these four protocols require AUTHENTICATION plus ENCRYPTION. Thus there have a legitimate reason to call it security and not just encryption. > Let's talk about the substance of the draft. This draft proposes encryption in the possible absence of authentication. While I can call it privacy or encryption, I have a very hard time calling it security. On top of that, we all know we would have called ie opportunistic encryption if that term had not been picked already. We know the term is a workaround. Some just feel it is a bad workaround. For its implied (misleading) meaning and for its terrible acronym of "OS". RFC 4949 states: $ security 1a. (I) A system condition that results from the establishment and maintenance of measures to protect the system. 1b. (I) A system condition in which system resources are free from unauthorized access and from unauthorized or accidental change, destruction, or loss. (Compare: safety.) 2. (I) Measures taken to protect a system. Tutorial: Parker [Park] suggests that providing a condition of system security may involve the following six basic functions, which overlap to some extent: - "Deterrence": Reducing an intelligent threat by discouraging action, such as by fear or doubt. (See: attack, threat action.) - "Avoidance": Reducing a risk by either reducing the value of the potential loss or reducing the probability that the loss will occur. (See: risk analysis. Compare: "risk avoidance" under "risk".) - "Prevention": Impeding or thwarting a potential security violation by deploying a countermeasure. - "Detection": Determining that a security violation is impending, is in progress, or has recently occurred, and thus make it possible to reduce the potential loss. (See: intrusion detection.) - "Recovery": Restoring a normal state of system operation by compensating for a security violation, possibly by eliminating or repairing its effects. (See: contingency plan, main entry for "recovery".) - "Correction": Changing a security architecture to eliminate or reduce the risk of reoccurrence of a security violation or threat consequence, such as by eliminating a vulnerability. The draft covers none of these listed items - it should not be called "XXX security" Paul From nobody Fri Aug 15 13:35:19 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BCF1A048D; Fri, 15 Aug 2014 13:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFvuQuBGlQgm; Fri, 15 Aug 2014 13:35:16 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6271A0487; Fri, 15 Aug 2014 13:35:15 -0700 (PDT) X-AuditID: 12074424-f79146d00000067c-70-53ee6f02494f Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 2C.12.01660.20F6EE35; Fri, 15 Aug 2014 16:35:14 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s7FKZC9q016371; Fri, 15 Aug 2014 16:35:13 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7FKZ9sB006664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Aug 2014 16:35:11 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7FKZ9jX007656; Fri, 15 Aug 2014 16:35:09 -0400 (EDT) Date: Fri, 15 Aug 2014 16:35:09 -0400 (EDT) From: Benjamin Kaduk To: Paul Wouters In-Reply-To: Message-ID: References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsUixG6nosuU/y7YYPdqWYtnG+ezWLy/dYnJ Ykp/J5MDs8eSJT+ZPL7PYwpgiuKySUnNySxLLdK3S+DKmHx/LWPBMt6K75vYGhi3cnUxcnJI CJhIHF15nwnCFpO4cG89WxcjF4eQwGwmiS2b/0A5GxklOq/uZodwDjFJfJh4jgnCaWCU+PLr O1g/i4C2xP5Jj8BsNgEViZlvNrKB2CICihKTzjxiAbGZBRQkVr98CmYLCwRKHP3cCmZzCjhK TFi8BayeF8huP/WKGWLBJ0aJA09/s4MkRAV0JFbvn8ICUSQocXLmE6ihWhLLp29jmcAoOAtJ ahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW65nq5mSV6qSmlmxjBQeuisoOx+ZDSIUYB DkYlHt4MyXfBQqyJZcWVuYcYJTmYlER5/dKBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4V7kB 5XhTEiurUovyYVLSHCxK4rxvra2ChQTSE0tSs1NTC1KLYLIyHBxKErxHcoEaBYtS01Mr0jJz ShDSTBycIMN5gIYvAanhLS5IzC3OTIfIn2JUlBLnnQySEABJZJTmwfXCksorRnGgV4R5f4FU 8QATElz3K6DBTECDaza/BRlckoiQkmpgPLzCsXpR+vSv1k2Zll+feM6dKJCZUilSlvjYvShN cLWO8/dp8X/0Vt765Mp28JftGcUviwU2xxhuXGnX8OVw1KMft29aHeHOmPVlx8t77NwJXeuV 7Ta3TlfQ55q54n/ir7MGUk/mZL9gl3qiYM3jrd57eG7yQ0YZh7V2H3J5V5RvS/5Qp1VaocRS nJFoqMVcVJwIAKY1HtwFAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/saag/WLT2-LdrHq-m5cGpQM5K28wMqE8 Cc: ietf@ietf.org, saag@ietf.org Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 20:35:17 -0000 On Fri, 15 Aug 2014, Paul Wouters wrote: > On Fri, 15 Aug 2014, Viktor Dukhovni wrote: > > > On Fri, Aug 15, 2014 at 03:01:59PM -0400, Paul Wouters wrote: > > > > > Background Encryption ? > > > Preemptive Encryption ? > > > Preventive Encryption ? > > > Preventative Encryption ? > > > Countermeassure Encryption ? > > > Remedial Encryption ? > > > > This boat has sailed: > > > > TLS -> TLE: Transport Layer Encryption? > > IPsec -> IPenc: IP encryption? > > SSH -> ESH: Encrypted SHell? > > HTTPS -> HTTPE: HTTP over TLE? > > ... > > All these four protocols require AUTHENTICATION plus ENCRYPTION. Thus > there have a legitimate reason to call it security and not just > encryption. > > > Let's talk about the substance of the draft. > > This draft proposes encryption in the possible absence of > authentication. While I can call it privacy or encryption, That is not an accurate summary of the proposals made by the draft. The draft proposes to use what tools are available to do the best you can. If the peer you're talking to has configured DANE records that you can retrieve via DNSSEC, then you can authenticate that particular connection, securely. A protocol that performs such a lookup and authenticates that connection is an opportunisticly secure protocol, because it does not require that all connections have that lookup succeed -- the authentication is performed opportunisticaly, when it is possible. That is not to say that the draft is perfect; I have not finished a detailed read of the -03, and there are certainly things that could be improved. Failing to do more than cover encryption is not one of them. -Ben From nobody Fri Aug 15 13:48:19 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A681A0653; Fri, 15 Aug 2014 13:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRvn3gdj7C-k; Fri, 15 Aug 2014 13:48:16 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0941A064E; Fri, 15 Aug 2014 13:48:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 149862AB29E; Fri, 15 Aug 2014 20:48:14 +0000 (UTC) Date: Fri, 15 Aug 2014 20:48:14 +0000 From: Viktor Dukhovni To: ietf@ietf.org, saag@ietf.org Message-ID: <20140815204814.GX5476@mournblade.imrryr.org> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/IdkXBBDvOYG40OZN_KmtmSU0zyc Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 20:48:17 -0000 On Fri, Aug 15, 2014 at 04:29:12PM -0400, Paul Wouters wrote: > >Let's talk about the substance of the draft. > > This draft proposes encryption in the possible absence of > authentication. No, this draft proposes encryption in the presence of peer encryption support, and authentication in the presence of peer authentication support as determined via suitable peer signalling mechanisms. > While I can call it privacy or encryption, > I have a very hard time calling it security. Opportunistic DANE TLS for SMTP is security, but is only comprehensive when the SMTP server publishes DNSSEC validated and MX RRs and associated TLSA RRs for the MX hosts. It is an example of OS. Opportunistic (non-DANE) TLS (as in the draft's example section) for SMTP is also security. It is security against passive attacks, that is, for a different threat model. Both are OS, but the draft promotes designs that can do both comprehensive (passive and active) and partial (passive-only) channel security. > On top of that, > we all know we would have called ie opportunistic encryption > if that term had not been picked already. I would have objected regardless. Opportunistic security is a better match than OE for the content of the draft. I would not have objected to Opportunistic Cryptosecurity, but it is not a compelling improvement. -- Viktor. From nobody Fri Aug 15 14:07:00 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437201A0682; Fri, 15 Aug 2014 14:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrZevbmDW9AT; Fri, 15 Aug 2014 14:06:47 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28EF01A052E; Fri, 15 Aug 2014 14:06:47 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AF0F780048; Fri, 15 Aug 2014 17:06:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1408136805; bh=ck/p9/bqIABrAlyzgyXbFqBUZRUTxT0/Q888yl8vp0g=; h=Date:From:To:Subject:In-Reply-To:References; b=B2XAgEg3XU17a1Tpem8t7aPy0RGxReDlyRISSDgxSIzWqBerFu8UDEi9z6a79fO+l fc5hQ7LSXk3P537AmRytHMj6JU2aHUXyy/PSSl/RVJpl0f2+4Xq+mr6vwS7P7SIK5i BYgpcOXGcVhcsQFrs/NbwnRoG7Qr7l1roi/a9QY8= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s7FL6jFg025292; Fri, 15 Aug 2014 17:06:45 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 15 Aug 2014 17:06:45 -0400 (EDT) From: Paul Wouters To: saag@ietf.org, ietf@ietf.org In-Reply-To: <20140815204814.GX5476@mournblade.imrryr.org> Message-ID: References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <20140815204814.GX5476@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/34cMIIewYBapsLb2YBvrE6Ez_f8 Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 21:06:49 -0000 On Fri, 15 Aug 2014, Viktor Dukhovni wrote: >> This draft proposes encryption in the possible absence of >> authentication. > > No, this draft proposes encryption in the presence of peer encryption > support, and authentication in the presence of peer authentication > support as determined via suitable peer signalling mechanisms. We already have drafts/RFCs for using advertised authenticated encryption, such as webpki and DANE. This draft adds an opportune component to strongly recommend unauthenticated encryption over cleartext in ABSENCE of support of other drafts/RFCs for authenticated encryption. >> While I can call it privacy or encryption, >> I have a very hard time calling it security. > > Opportunistic DANE TLS for SMTP is security Some disagree about the use of the term opportunistic in this case. If an SMTP client supports DANE, and is contacting an SMTP server supporting DANE, there is nothing opportunistic about it. It MUST use encryption and MUST NOT fall back to cleartext. > It is security against passive attacks, > that is, for a different threat model. I don't disagree. But it is still only encryption. > I would have objected regardless. Opportunistic security is a > better match than OE for the content of the draft. I would not > have objected to Opportunistic Cryptosecurity, but it is not a > compelling improvement. While not compelling, it is an improvement :P Paul From nobody Fri Aug 15 14:15:03 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A191A065F; Fri, 15 Aug 2014 14:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pt4yMDX481iJ; Fri, 15 Aug 2014 14:14:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2573C1A06AB; Fri, 15 Aug 2014 14:14:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7099C2AB29E; Fri, 15 Aug 2014 21:14:57 +0000 (UTC) Date: Fri, 15 Aug 2014 21:14:57 +0000 From: Viktor Dukhovni To: ietf@ietf.org, saag@ietf.org Message-ID: <20140815211457.GY5476@mournblade.imrryr.org> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53EE6CFF.3060406@bbiw.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/6E2jvOPSiRC_h5q-GOl0qmWal5o Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ietf@ietf.org, saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 21:15:00 -0000 On Fri, Aug 15, 2014 at 01:26:39PM -0700, Dave Crocker wrote: > > While you seem to be saying opportunism is "In absence of > > mandated authenticated encryption, try to use unauthenticated > > encryption". > > My definition: > > Opportunism is the flexibility to use less-stringent protection, > when stronger protection is not possible. This is a definition of something else. That something is not the subject of the draft. > > > What Viktor is saying is that the parapraph in question makes sense > > using his interpretation of the definition, and does not make sense > > with your interpretation of the definition. > > > > Clearly we have work to do to ensure there is only one interpreation of > > the definition. > > Yup. Insisting that the draft should be defining something else is not progress towards helping more readers arrive at a convergent interpretation of the subject matter. This sub-thread will become more productive, once the subject of the definition or exposition (as imperfect as that might be) is accepted as a starting point, and what we're discussing is how to improve the clarity. The subject is introducing the OS design pattern. The OS design pattern as introduced, is to set a least common denominator baseline (crypto)security policy (that might well be cleartext) and from there do better whenever possible for each peer. For some unathenticated encryption is the best one can do. For other peers authentication can be signalled and enforced. The somewhat clumsy phrase "opportunistically employed" attempts to capture this, without running into terminology trouble by talking directly about "opportunistic encryption" or "opportunistic authentication", at least the first of which is a booby trap due to conflicting usage. If someone can help improve the text that uses that construct, that would be great. Constructive comments will help to clarify the exposition of the idea that can be casually summarized as: "spring forward" not "fall back". Another key pillar of the draft, is that OS designs need to not create obstacles to communication. In any OS design, whatever security mechanisms are enabled based on peer signalling need to be much more operationally reliable than present state of the art. If an OS design cannot be enabled by default, and constantly pops up dialogues for users to approve exceptions, then that design is a failure. -- Viktor. From nobody Fri Aug 15 14:20:09 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F10C1A06C6; Fri, 15 Aug 2014 14:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60rP0NPke6qJ; Fri, 15 Aug 2014 14:19:51 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F7631A066D; Fri, 15 Aug 2014 14:19:51 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E29B12AB29E; Fri, 15 Aug 2014 21:19:50 +0000 (UTC) Date: Fri, 15 Aug 2014 21:19:50 +0000 From: Viktor Dukhovni To: ietf@ietf.org, saag@ietf.org Message-ID: <20140815211950.GZ5476@mournblade.imrryr.org> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <20140815204814.GX5476@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Hg52iRMrwmlDU7u475EwfJGW7B0 Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 21:19:58 -0000 On Fri, Aug 15, 2014 at 05:06:45PM -0400, Paul Wouters wrote: > >Opportunistic DANE TLS for SMTP is security > > Some disagree about the use of the term opportunistic in this case. > If an SMTP client supports DANE, and is contacting an SMTP server > supporting DANE, there is nothing opportunistic about it. It MUST use > encryption and MUST NOT fall back to cleartext. This myopically focuses on a single interaction of the protocol. When an SMTP client supports DANE, it applies DANE security when TLSA RRs are present, and not when they absent. The use of DANE is opportunistic. Thus the clumsy phrase "opportunistically employed" in the current draft. If anyone can suggest better language, please send a patch for the XML: git clone https://github.com/vdukhovni/saag.git -- Viktor. From nobody Fri Aug 15 14:36:11 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039C91A0717; Fri, 15 Aug 2014 14:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vN4SdAOstHM; Fri, 15 Aug 2014 14:36:05 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88191A071B; Fri, 15 Aug 2014 14:36:04 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:33104 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XIPAJ-000I1I-Du; Fri, 15 Aug 2014 17:36:03 -0400 Message-ID: <53EE7D42.2030900@bbn.com> Date: Fri, 15 Aug 2014 17:36:02 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ietf@ietf.org, saag References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> In-Reply-To: <53EDF437.6070108@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FaAnt8n33st5qxOkrfvwzCficxc Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 21:36:08 -0000 Stephen, Viktor did provide me woth a copy of -03, and solicited comments. I am sorry to say that almost none of my comments seem to have been incorporated into the text, expect splitting the reference section as required by RFC conventions. I repeat my comments below. I have not bothered to remove ones that may have been addressed, since Viktor didn't even bother to reply to me to discuss the comments. I also note something I didn't mention in my review. The Terminology section redefines "authenticated encryption" and defines "unauthenticated encryption" so that the terms means what Viktor wants. This introduces needless conflict with a widely accepted term (the former). If Viktor used the phrases "authenticated, encrypted communication" and "unauthenticated, encrypted communication" there would be no need for this contradictory terminology. Steve ------- I like the new subtitle ☺. Someone told me that there was a suggestion to use the phrase “opportunistic crypto-security†instead of “opportunistic securityâ€. I think that would be a good change, as it more precisely defines what we’re trying to accomplish, and it avoids acronym collision with the more traditional use of OS. Abstract I’m not fond of the phrase “protocol design patternâ€. I don’t recall ever hearing that phrase before. If you substituted “guidelines†or “principle†for pattern that would be more in keeping with existing terminology. “OS protocols tailor the minimum acceptable channel security to the capabilities of the peer systems.†I don’t see the word “acceptable†as appropriate here. “Achievable†makes sense, but what is or is not acceptable seems to be a different matter. “As a result, at least some cryptographic protection is provided most of the time.†We hope this will be true, but it’s not at all certain, so this statement is not supportable. Introduction Overall comment: the introduction seems rambling. It does not progress in a simple, clear fashion to make the argument you want. I’d re-write it as follows: - motivate the development of the OS/OC guidelines by citing RFC 7258. - note that there are many IETF standards for security, but they do not appear to be as widely used as we would like, as observed in 7258. - say that we believe the reason that these protocols are not so widely used is because they usually require that at least one-way, if not two-way authentication (provide a forward reference to definitions in the terminology section), and that authentication is based on key maagement. - Note that the mechanisms we have developed for authenticated key management (Web PKI, TOFU, etc.) all have some limitations, and these limitations prevent them from being used ubiquitously. The most recently developed mechanisms for authenticated key management are immature (cite DANE). While we wait for mechanisms such as DANE to become widely available, we want to encourage wider use of encryption for confidentiality. - This observation suggests that if we want to remove barriers to widespread use of encryption, we need to make it easy to provide confidentiality (via encryption) w/o authentication. Note that while some IETF protocols offer this capability (e.g., TLS and BTNS) it is not commonly employed. - Now, provide a concise definition of OS (or OC). Say, for example: “OS/OC is a set of protocol design guidelines that encourage widespread use of encryption. OS/OC is not a protocol. Protocols that comply with OS/OC guidelines may offer additional crypto-security services, e.g., integrity and authentication, if these services are supported by both (all) parties to a communication.†- Note that the primary focus is OS/OC is countering passive wiretapping, as that is the primary concern cited in 7258. Nonetheless, active attacks are of concern as well, and thus OS/OC guidelines encourage use of mechanisms that counter such attacks. Nonetheless, a fundamental precept of OS/OC is that encryption should be enabled even if (crypto-based) authentication is not possible. Also note that OS/OC guidelines require that a failure to encrypt not prevent communication. This is necessary so as to allow for incremental deployment in a backward compatible fashion and encourage use of OS/OC. Thus plaintext communication is an acceptable fallback when peers are not able to encrypt, e.g., because not both (all) are employing OS/OC protocols. - A protocol that adheres to OS/OC guidelines may be used in conjunction with a local security policy. That policy may override the default OS communication criteria. Specifically, local policy may require communication to be authenticated, in some or all cases. Such local policy is not viewed as contradictory to OS guuidelines. - Finally, observe that OS/OC protocols are not viewed as a substitute for existing security protocols, that typically offer authentication as well as confidentiality. When such protocols can be employed, they are preferred to OS/OC protocols. - Provide a overview of the rest of the document, noting that Section 3 describes the OS/OC design guidelines. Comments on section 1 text details: I think the first sentence is still a poor start. When NIST began the crypto module evaluation program they discovered that almost all of the algorithm implementations submitted for review had security flaws. So, encryption is not so easy, although I agree that (authenticated) key management is harder. The phrase “fully trusted†is vague. “Web PKI public CAs are not always sufficient to authenticate the peer system.†What does this mean? “And with so many certification authorities the communicating parties don't always agree on a mutually trusted CA.†I don’t think this is a common problem, because the major browsers seem to have adopted most of the same set of trust anchors. “Historically, Internet security protocols have prioritized comprehensive cryptographic protection against both passive and active attacks over enabling systems with varied security requirements to communicate with each other.†This sentence is too long and complex. “…while communications traffic is sometimes strongly protected, …†“The fact that most traffic is unencrypted …†-> “The fact that most traffic is not encrypted …†“Using the opportunistic security design makes passive attacks more difficult for all these actors.†-> “Using opportunistic security design principles makes passive attacks more difficult for all these actors.†“In order to make encryption more ubiquitous, …†-> “In order to make encryption ubiquitous, …†BTW, 7258 intentionally avoids using the term ubiquitous; do you really want to use it here? “… authentication should not be required where it cannot be expected.†What does this mean? The penultimate paragraph in the introduction is redundant and wordy. Here is how I would write it: If peers support a protocol designed to meet the OS guidelines, they will establish encrypted communication when authenticated communication cannot be achieved. Nonetheless, peers are encouraged to establish authenticated, encrypted communication when possible. If one peer is OS-enabled, and the other is not, then communication will be in cleartext. “The opportunistic security design pattern features a range of cryptographic protection levels, …“ As others have noted, this wording suggests an ordering of the protection afforded by OS. There seems to be agreement that, given the range of security service options, there is only a partial ordering. “Even with opportunistic security, protection against active attacks is still employed where unconditionally required by local policy or else determined to be applicable with a given peer.†I assume that what you are trying to say in the first two-thirds of his sentence is that local policy may require additional security services, and those trump the interoperability goal of OS. That’s an important notion, one that needs to be stated more clearly. The last phrase (underlined above) is mysterious. What are you trying to communicate there? Are you trying to distinguish between a local policy that requires all communication to be authenticated vs. only select peers? The text is not at all clear on this. Referring to active attacks, vs. requiring authentication, only makes the sentences here less clear. Section 2. Add definitions (or citations) for one-way and two-way authentication. The definition of unauthenticated encryption refers to “key agreement†but that is unduly restrictive, i.e., key management mechanisms other than key agreement can deliver keys that are not bound to a “reference identity.†Section 3 As I noted above, “pattern†is an odd term. I suggest “guidelines†or “principles†or “philosophy†instead. This section needs to have a clear distinction between what appears in it vs. in Section 4. Right now that distinction is not at all clear. The phrase “advertised capabilities†seems appropriate for data that might be acquired out-of-band, e.g., via the DNS. When the capabilities are discovered via in-band communication, the term “negotiation†seems more appropriate. “This includes the specific mechanisms, whether to require their use, how to handle errors and what to do when mechanisms are disabled.†I’d say “specific security mechanisms†here. Also, is it really common to communicate how to handle errors via the mechanisms to which you refer? What are examples? I’m not aware of such a capability in TLS or IPsec, for example. “When the advertised capabilities of peers match reality, an opportunistic security design avoids causing communications issues that would otherwise prevent the deployment of protocol security.†What does the phrase “match reality†mean here? The underlined phrase in the sentence above is very confusing. Try to simply it. “The determination of which security mechanisms to use can vary from case to case when the OS design pattern is used with different protocols. The protection provided by the OS pattern will depend on the protocol making use of the pattern. In many cases, OS will result in negotiating channels with one of the following security properties:†There are so many qualifiers in these sentences that it makes it appear that the “OS pattern†is indefinable. I don’t think you need to be so vague. “Opportunistic security does not start with an overly optimistic view of peer capabilities only to be "disappointed" and settle for less when the peer fails to live up to expectations. Rather, the opportunistic security design pattern starts with a pessimistic view of the baseline capabilities of all peers, and is "pleasantly surprised" to learn that some peers can be expected to do more. Opportunistic security aims to do better than might be expected, rather than worse than might be hoped.†This text is needlessly anthropomorphic for a section that purports to be explaining a “pattern.†“Enforcement of authentication in an opportunistic protocol is not a contradiction. …†I suggest replacing the paragraph with: “A peer that requires authentication may be compatible with the OS design guidelines. For example, authentication may be required by local policy. If an OS-enabled peer (A) makes available authenticated key material, e.g., via DANE, to peer (B), then B should make use of this material to authenticate A, if B is OS-enabled. “Unless preempted by local or other policy, an opportunistic security protocol first determines the capabilities of a peer.†The escape clause at the beginning, especially the “other policy†phrase, makes this statement almost useless. “This might include whether that peer supports authenticated encryption, unauthenticated encryption or perhaps only cleartext.†You’ve been advised that this the underlined phrase is not one you should be using. How about: “Typical peer capabilities are support for authenticated, encrypted communication, encryption w/o authentication, or only cleartext communication.†“The appropriate communications security policy is then employed for each peer.†-> “After each peer has determined the capabilities of the other, a compatible set of security services can be employed.†“An OS protocol may apply more stringent security settings with the underlying cryptographic mechanisms when authenticated encryption is required than when only unauthenticated encryption is employed.†What does “more stringent security setting†mean? dTthere is no total order for security capabilities, and the phrase “security settings†has not been defined. “Authentication failure can be a reason to abort a connection to a peer that is expected to be authenticated. However, such a failure must not then lead to communication in cleartext when encryption is an option.†This guidance is confusing. Does it mean that when peer A determines that peer B is capable of authentication (e.g., via DANE), but authentication fails, that peer A MUST/SHOULD attempt encrypted communication, rather that rejecting communication? This is one of several possible interpretations of the two sentences above. You need to re-word the sentences to provide clear guidance here. “Cleartext support is for backwards compatibility with already deployed systems. Cleartext transmission should be avoided in new OS protocol designs.†The first sentence is clear. The second sentence is vague, since, for backward compatibility, cleartext fallback is required. The third sentence provides clarification, making the second sentence redundant. Re-word. Section 4 As noted in my comment at the beginig of Section 3, there is no clear distinction between the design “pattern†and design “principles,†other than formatting. “Coexist with explicit policy†This principle is generally well stated, but one comment is confusing: “… opportunistic security might be enabled only for specified peers, …†If one does not authenticate a peer, how does one know that the peer is one for which OS is to be used? I would expect that a security policy would identify peers for which authentication is required, and if a peer is not authenticated, then OS might apply. “Prioritize enabling communication†The description of this principle says “If a non-negligible number of potential peers are only capable of cleartext, then it is acceptable to fall back to cleartext when encryption is not possible.†This is still wrong. If ANY potential peer is capable of only cleartext, then it is acceptable to fall back to cleartext when communicating with that peer! “Maximize security peer by peer†This principle overlaps with the first one. I presume that the phrase “… may, when applicable, refuse to communicate with peers for which higher security is expected …†is just an example of a local security policy mandating more than OS. If this is correct, this principle adds nothing, if this is not correct, you need to do a better job of explaining what is intended here. “Encrypt by default†This principle begins by saying “An opportunistic security protocol at least encrypts communications.†The second sentence then recants this statement, noting the need to fallback to cleartext for backwards compatibility, and to accommodate “local policy.†Don’t make a string statement, and then have to qualify it this way. I suggest removing the first two sentences and making this principle all about PFS. “No misrepresentation of security†is an interesting, new principle. Unfortunately, the phrase “communication over a secure channel†has not been defined, so the intent is unclear. Presumably you are alluding to communication over an authenticated, encrypted channel, but maybe an authenticated, cleartext channel would qualify. There is also an ambiguity about to whom/what the misrepresentation is directed. Is this a UI issue, an API issue, or what? Section 5 “Thus opportunistic TLS based on STARTTLS support …†Is there an RFC that characterizes this behavior as “opportunistic TLS?†if not, then it seems inappropriate to apply this term to an existing mechanism. “Self-signed certificates are common on receiving MTAs, …†Do some MTAs only receive messages, and not send them? Or do you mean that it is common for an MTA that is the target of a message transfer to offer a self-signed certificate when STARTTLS is employed? “Therefore, MTAs that implement opportunistic TLS …†Again, it appears that you are applying the term “opportunistic TLS†when there is no precedent for doing so, i.e., no RFC that characterizes this behavior in this fashion. “Not only is the STARTTLS advertisement is vulnerable to active attacks, …†-> “Not only is the STARTTLS advertisement vulnerable to active attacks, …†Section 6 “Though opportunistic security potentially supports transmission in cleartext, unauthenticated encryption, or other cryptographic protection levels short of the strongest potentially applicable, the effective security for peers is always increased and never reduced.†This sentence is way too long, and it again seems to imply a total ordering on security service offerings. “ … when maximal security is not applicable.†The phrase “maximal security†is not appropriate. “Opportunistic security does not require reducing security policy to the lowest common denominator.†I disagree. OS is precisely an LCD mechanism, when considered on a pairwise peer basis. What I think you intend to say is that OS is not the LCD of all possible communicating peers. “a-priori†-> “a priori†Additionally, the term “a priori†is not used anywhere else in this document, so why use it now? Do you mean “local security policy?†Security policies tend to be “a priori†i.e., they exist before an event that requires their application, so his term seems silly here. “However, such a-priori policy can be counter-productive when it expects more than most peers can in fact deliver.†The IETF is not in a position to make this value judgment, e.g., for an enterprise. Also, I suspect you really mean that it’s a bad idea to mandate authenticated encrypted communication, or cleartext. Even that is not an obvious mistake; an enterprise might decide that it prefers cleartext traffic that it can inspect with a firewall and an IDS over encrypted communication that is unauthenticated and not subject to inspection. From nobody Fri Aug 15 14:37:53 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01601A0728; Fri, 15 Aug 2014 14:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UumregYn74Qm; Fri, 15 Aug 2014 14:37:50 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F82F1A0717; Fri, 15 Aug 2014 14:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1616; q=dns/txt; s=iport; t=1408138672; x=1409348272; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=0CrIqTYvgP+3zSIxJX9eLP0lVcFYPguWXkFmFGF3MNc=; b=gan6DHlJz6i03QOfgyZNL4evLAa+BGHAcKLZnIRincAVGsGyZgzPi2Fb EyaQKEa7bSEgQ+355VToIuPyYUG79gHfrStJGtIHOw+gERDHOf67m/WDg vkkSuxw9V/8e0s+j642gZ/EmzhK9tyBQPYJBG2Fu3L3wXJrsJxADggP6p g=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEANN87lOtJssW/2dsb2JhbABZhzPSbwGBKXeEBAEBBCNVEQshFgsCAgkDAgECAUUHDAgBAYg+rluVGhePU4J5gVMBBJMggUqHU4cnjVeDXjuCfgEBAQ X-IronPort-AV: E=Sophos;i="5.01,873,1400025600"; d="asc'?scan'208";a="139023500" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 15 Aug 2014 21:37:49 +0000 Received: from [10.61.196.246] ([10.61.196.246]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7FLblC9009276; Fri, 15 Aug 2014 21:37:47 GMT Message-ID: <53EE7DAA.1070104@cisco.com> Date: Fri, 15 Aug 2014 23:37:46 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ietf@ietf.org, saag@ietf.org References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> In-Reply-To: <20140815211457.GY5476@mournblade.imrryr.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rtk8XRGIH1jJNs4Lp9FUxNsrouoMe2rqx" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/XNy1MTj2nWJorHu-hPL85_aAJMY Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 21:37:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rtk8XRGIH1jJNs4Lp9FUxNsrouoMe2rqx Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Victor, Having read through the latest draft, I have a few comments. The principles stated in the draft seem like really good ones. I personally care more about those principles and less about the definition. But I agree with Dave on his point about the definition.=20 If we could focus on the core principles and perhaps note that the term is imperfect (and we just don't have a better one), then perhaps we have a way forward. I actually like your term "opportunistically employed", but I do agree that it is possible to wordsmith the explanatory text to be a little less... cryptic. Fundamentally I think that's the key to the whole draft= =2E Eliot --rtk8XRGIH1jJNs4Lp9FUxNsrouoMe2rqx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJT7n2qAAoJEIe2a0bZ0nozcusH/2eKd7Y2luEkxdUBTBtB672W DCZ/23m85AqiiylAa5FH3oQ4XefkN1909EdXJlVPfqexe8avyvhzMbxOM99eDHLu JIIf6l4+d2MjmMtDc642gHP7+Gj6dx/pa0a4wXWxc6m3F0gh370bhKBq0la5TRmL uspGFhPxe+ppMRu5w7bIZvK2GvT6CJHRvR5GfA0XVD/nDnS6iYEo7qlqosdNmqCc Y8Q3cuWdAI47u9yKKq+biQ9pJ0Lr8O38N1A7vqEaqV9pJknqfZCdqOuUFiuBzitj zYSVNbjOhkjJ5dFVpUfke7zYXZ4xC5nTtcM56lWkKq897oNLBTUySCpm6YtstOE= =1ph6 -----END PGP SIGNATURE----- --rtk8XRGIH1jJNs4Lp9FUxNsrouoMe2rqx-- From nobody Fri Aug 15 14:51:36 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA721A0700 for ; Fri, 15 Aug 2014 14:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izhf4yMKxPXi for ; Fri, 15 Aug 2014 14:51:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF831A06FF for ; Fri, 15 Aug 2014 14:51:34 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1XIPPH-0001W5-Qk; Fri, 15 Aug 2014 21:51:32 +0000 Date: Sat, 16 Aug 2014 06:51:30 +0900 Message-ID: From: Randy Bush To: Viktor Dukhovni In-Reply-To: <20140815211950.GZ5476@mournblade.imrryr.org> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <20140815204814.GX5476@mournblade.imrryr.org> <20140815211950.GZ5476@mournblade.imrryr.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/saag/A0apzHaTpwwK6bPeDR3FgaqMLY8 Cc: saag Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 21:51:35 -0000 > Thus the clumsy phrase "opportunistically employed" in the current > draft. If anyone can suggest better language, please send a patch > for the XML: as i said (privately) to pete, the problem is that "opportunity" does not convey "as well as can be done in the circumstances." it means "something that works." i can not think of an american english word that conveys what you want. gambatte, which can mean "do your best," comes closer but is a verb. randy From nobody Fri Aug 15 15:17:40 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7D61A072F for ; Fri, 15 Aug 2014 15:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50cMrvE_NxoJ for ; Fri, 15 Aug 2014 15:17:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E97E91A0457 for ; Fri, 15 Aug 2014 15:17:36 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1XIPoR-0001fM-GI; Fri, 15 Aug 2014 22:17:32 +0000 Date: Sat, 16 Aug 2014 07:17:30 +0900 Message-ID: From: Randy Bush To: Bill Manning In-Reply-To: <6D6BB793-E7FF-4F4B-ABFF-60B8BCFF6ADD@karoshi.com> References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> <6D6BB793-E7FF-4F4B-ABFF-60B8BCFF6ADD@karoshi.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/saag/EsUj287Ps--fIF8SsynwV5brmDs Cc: saag Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 22:17:38 -0000 > A presumptive is that folks will care for and actively manage their > Trust Anchors. Just like folks care for and actively manage their > Browser Certificates. a bit easier to curate one TA than 300+ randy From nobody Fri Aug 15 15:18:34 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606541A075D; Fri, 15 Aug 2014 15:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbl_J253dBBm; Fri, 15 Aug 2014 15:18:15 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4CD41A075B; Fri, 15 Aug 2014 15:18:13 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C573C2AB29E; Fri, 15 Aug 2014 22:18:06 +0000 (UTC) Date: Fri, 15 Aug 2014 22:18:06 +0000 From: Viktor Dukhovni To: saag@ietf.org, ietf@ietf.org Message-ID: <20140815221806.GA5476@mournblade.imrryr.org> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53EE7D42.2030900@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rhBqEhCerFEeJjftMjCFh8JVssE Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 22:18:25 -0000 On Fri, Aug 15, 2014 at 05:36:02PM -0400, Stephen Kent wrote: > Viktor did provide me woth a copy of -03, and solicited comments. > > I am sorry to say that almost none of my comments seem to have been > incorporated into the text, expect splitting the reference section > as required by RFC conventions. I must say I at least tried: commit 07e1bd3bd599266b07a162ae56b2e36fa3d4eead Author: Viktor Dukhovni Date: Wed Aug 13 21:44:35 2014 -0400 Steve Kent feedback. draft-dukhovni-opportunistic-security | 398 ++++++++++++++++++--------------- 1 file changed, 216 insertions(+), 182 deletions(-) sorry if it is not what you had hoped, a lot more of the comments were addressed than might appear at first glance. Not necessarily by adopting the suggested changes as-is, but the comments were useful, were taken seriously, and not simply ignored. > I repeat my comments below. I have not bothered to remove ones that may > have been addressed, since Viktor didn't even bother to reply to me to > discuss the comments. I've been integrating comments from multiple people burning the candle at both ends for a whole week. Cycles for individual back/forth correspondence were not available. My response was -03. If you're just resending the comments for stale versions of the work in progress, I can't really make use of those I'm afraid. They've already been processed and taken seriously. > I also note something I didn't mention in my review. The Terminology > section redefines "authenticated encryption" and defines "unauthenticated > encryption" so that the terms means what Viktor wants. This introduces > needless conflict with a widely accepted term (the former). If Viktor used > the phrases "authenticated, encrypted communication" and "unauthenticated, > encrypted communication" there would be no need for this contradictory > terminology. This is a reasonable new suggestion, I'll see whether this introduces any problems in the context in which these are used. It may well reduce the need for the "this is not AEAD" diclaimers. -- Viktor. From nobody Fri Aug 15 15:52:36 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FDA1A0081 for ; Fri, 15 Aug 2014 15:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wI8eM4149gkh for ; Fri, 15 Aug 2014 15:52:31 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD43F1A007C for ; Fri, 15 Aug 2014 15:52:29 -0700 (PDT) Received: from [192.168.0.3] (cpe-23-241-118-60.socal.res.rr.com [23.241.118.60]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s7FMpnZx003471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 15 Aug 2014 15:51:52 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=windows-1252 From: manning In-Reply-To: Date: Fri, 15 Aug 2014 15:51:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> <6D6BB793-E7FF-4F4B-ABFF-60B8BCFF6ADD@karoshi.com> To: Randy Bush X-Mailer: Apple Mail (2.1878.2) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@karoshi.com Archived-At: http://mailarchive.ietf.org/arch/msg/saag/MfiSRCQ6BgZOl0etXA05-x67ErI Cc: saag Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 22:52:33 -0000 On 15August2014Friday, at 15:17, Randy Bush wrote: >> A presumptive is that folks will care for and actively manage their >> Trust Anchors. Just like folks care for and actively manage their >> Browser Certificates. >=20 > a bit easier to curate one TA than 300+ >=20 > randy Indeed. and a single point of failure is harder to miss, esp when it = fails. of course as long as most of the Internet links stay up/aren=92t = redirected, nearly=20 everyone should be able to walk the validation chain back to the TA. =20= And we all know how robust the Internet is=85 esp. these days. /bill= From nobody Fri Aug 15 18:04:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A99F1A092E for ; Fri, 15 Aug 2014 18:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAqnsiKZhD2F for ; Fri, 15 Aug 2014 18:04:53 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CAED1A0926 for ; Fri, 15 Aug 2014 18:04:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1XISQN-0002B5-Lo; Sat, 16 Aug 2014 01:04:52 +0000 Date: Sat, 16 Aug 2014 10:04:50 +0900 Message-ID: From: Randy Bush To: manning In-Reply-To: References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> <6D6BB793-E7FF-4F4B-ABFF-60B8BCFF6ADD@karoshi.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/saag/3m5Z_bsAaSO4hg2jDizAsW9iDA8 Cc: saag Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 01:04:54 -0000 >>> A presumptive is that folks will care for and actively manage their >>> Trust Anchors. Just like folks care for and actively manage their >>> Browser Certificates. >> a bit easier to curate one TA than 300+ > Indeed. and a single point of failure is harder to miss, esp when it > fails. fallacious logic. in any case, you have a cert to chase to a single TA. the point is the likelihood of good curation of one TA vs 300+. can you say diginotar? randy From nobody Fri Aug 15 21:49:00 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9B41A6F88; Fri, 15 Aug 2014 21:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, J_CHICKENPOX_51=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzN312qFOk_q; Fri, 15 Aug 2014 21:48:57 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31231A6F84; Fri, 15 Aug 2014 21:48:56 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B9E8C2AB2B7; Sat, 16 Aug 2014 04:48:54 +0000 (UTC) Date: Sat, 16 Aug 2014 04:48:54 +0000 From: Viktor Dukhovni To: ietf@ietf.org, saag@ietf.org Message-ID: <20140816044854.GB5476@mournblade.imrryr.org> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/JniHXVU8vRGPVD4DMPY-s-b8ZPE Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 04:48:58 -0000 On Fri, Aug 15, 2014 at 09:03:09PM -0700, John Wroclawski wrote: > From my point of view, these two wordings are indistinguishable. > Setting a least common denominator and doing better whenever possible > *is* using less-stringent protection when stronger protection is > not available. I understand there?s nuance, relating to per-peer > (which I think everyone agrees with), to the multiple dimensions > of protection, and to whether ?none? is a variant of ?least? or > not. But IMO, fundamentally these two sentences say the same thing. > If the intent is that they don?t, *very* different words may be > needed. Except that it is different. There is no need to make a big "your security may be degraded" fuss when doing better than expected. However, when failing to achieve a security goal, and settling for less, applications have tended to put up all sorts of warnings, fussy dialogues, ... And are often unwilling to do less that the maximum, and simply fail. The change of perspective is crucial to making progress. Cleartext is the baseline, not comprehensive protection. You don't fall back from comprehensive protection, when it is does not work out, ... You do better than the baseline when that is possible, and just works, without disrupting communication in the absence of an attack. This is a design guide (manifesto), not not a protocol specification, and setting things in the right perspective matters. It is important to understand that peer capabilities you can assume to be there are only those that are required and available to all peers, anything else is something that requires a specific capability advertisement. It makes little sense to talk about fallback from authenticated encryption, because authentication is mostly only useful when it is enforced. It makes more sense to talk about enforcing authentication when the peer publishes the appropriate key material (DANE, TACK, ...). The mandated model of security, where everybody has to implement it or they don't play the game, makes sense in top-down environments like the military or enterprises. It is not a good model for the Internet. We've tried it for a few decades now, it has not worked well. It is time for a more flexible, pragmatic approach. I expect opportunistic security to provide more security to more peers than the top-down models we've grown accustomed to. The language matters, it sets the correct mental model for moving forward. We need to prioritize the user's needs (move the bits) first, and layer as much security on top of that as we can, but no more. Yes, you can describe a fun-house mirror view of this, in which we're falling back from comprehensive security, But that is not a good way to think about it. Especially when you conclude that authentication is not opportunistic or cleartext is outside the artificial boundary drawn around opportunistic security, making just unauthenticated crypt be opportunistic security, and everything else is out. The result of that view would be everyone implementing unauthenticated crypto, and calling it a day. That would be a shame, because in the long run we do want protection from active attacks, and a way of getting that deployed, and enabled by default, and yet not disrupting communication when not under attack. Perhaps I should expand the example section to explain opportunistic DANE TLS for SMTP (even if that spec is still some weeks from LC), not just opportunistic TLS. Then people might have a better understanding of how opportunistic authentication works with DANE, and should work generally. I don't want the draft to over-emphasize DANE, it not just about DANE, but leaving out that example may have resulted in text that is a too abstract. -- Viktor. From nobody Sat Aug 16 01:16:25 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97551A089D for ; Sat, 16 Aug 2014 01:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZWXPPayXk6I for ; Sat, 16 Aug 2014 01:16:20 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4DBB1A087A for ; Sat, 16 Aug 2014 01:16:20 -0700 (PDT) Received: from [192.168.0.3] (cpe-23-241-118-60.socal.res.rr.com [23.241.118.60]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s7G8G0nU028885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 16 Aug 2014 01:16:04 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=windows-1252 From: manning In-Reply-To: Date: Sat, 16 Aug 2014 01:15:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <79EA0ED1-B63D-4803-9315-8E0A90196596@karoshi.com> References: <20140730150819.GA15044@mournblade.imrryr.org> <00d801cfacb3$9e5c3440$4001a8c0@gateway.2wire.net> <53DA9B74.8040706@bbn.com> <001a01cfacfd$76b4d6a0$4001a8c0@gateway.2wire.net> <20140731223242.GS15044@mournblade.imrryr.org> <53DFBA2C.3040107@bbn.com> <53E0FB86.7000803@bbn.com> <20140805181419.GF15044@mournblade.imrryr.org> <20140805210434.GB23449@localhost> <53E17F34.9090804@dcrocker.net> <20140806012706.GN15044@mournblade.imrryr.org> <53E19242.5030208@dcrocker.net> <468ABF4C-BD12-4599-BF3F-57D2761DECFD@frobbit.se> <6F2A9C4EF7A35E87B09D37EF@JcK-HP8200.jck.com> <53E64B66.4000203@dcrocker.net> <6D6BB793-E7FF-4F4B-ABFF-60B8BCFF6ADD@karoshi.com> To: Randy Bush X-Mailer: Apple Mail (2.1878.2) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@karoshi.com Archived-At: http://mailarchive.ietf.org/arch/msg/saag/6kgjmjRwc5OAdTWHZlJiAVYJQzo Cc: saag Subject: Re: [saag] What does DNSSec protect? (Re: Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 08:16:23 -0000 On 15August2014Friday, at 18:04, Randy Bush wrote: >>>> A presumptive is that folks will care for and actively manage their >>>> Trust Anchors. Just like folks care for and actively manage their >>>> Browser Certificates. >>> a bit easier to curate one TA than 300+ >> Indeed. and a single point of failure is harder to miss, esp when = it >> fails. >=20 > fallacious logic. in any case, you have a cert to chase to a single > TA. the point is the likelihood of good curation of one TA vs 300+. > can you say diginotar? >=20 > randy Randy, I am agreeing with you. A single TA is easier to curate. And = if all you have is a single TA, it is much easier to notice when it breaks. Simple,easy=85 However = we can continue to argue about being agreeable... /bill= From nobody Sat Aug 16 06:10:41 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E79A1A878C for ; Sat, 16 Aug 2014 06:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psg3ZuchF5Qk for ; Sat, 16 Aug 2014 06:10:36 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22821A8785 for ; Sat, 16 Aug 2014 06:10:36 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 8B7456D5F0; Sat, 16 Aug 2014 09:10:33 -0400 (EDT) Message-ID: <53EF5848.4000200@iang.org> Date: Sat, 16 Aug 2014 14:10:32 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/E3zUCKTwryEMEHMXLf5qS5YEYq0 Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 13:10:39 -0000 On 15/08/2014 21:29 pm, Paul Wouters wrote: > On Fri, 15 Aug 2014, Viktor Dukhovni wrote: > >> On Fri, Aug 15, 2014 at 03:01:59PM -0400, Paul Wouters wrote: >> >>> Background Encryption ? >>> Preemptive Encryption ? >>> Preventive Encryption ? >>> Preventative Encryption ? >>> Countermeassure Encryption ? >>> Remedial Encryption ? >> >> This boat has sailed: >> >> TLS -> TLE: Transport Layer Encryption? >> IPsec -> IPenc: IP encryption? >> SSH -> ESH: Encrypted SHell? >> HTTPS -> HTTPE: HTTP over TLE? >> ... > > All these four protocols require AUTHENTICATION plus ENCRYPTION. Thus > there have a legitimate reason to call it security and not just > encryption. Yes, but where is it written that SECURITY requires AUTH + ENC? As far as I know, this derives from a model sometimes called the Internet Threat Model, referenced in one of those RFCs that Stephen posted a month back. The model itself dates back to CIA (the term not the spooks) and military context where MITM is a game they play if they can. That's a particular model of security, or a pattern or a tradition. It isn't synonymous with security per se. >> Let's talk about the substance of the draft. > > This draft proposes encryption in the possible absence of > authentication. While I can call it privacy or encryption, > I have a very hard time calling it security. On top of that, > we all know we would have called ie opportunistic encryption > if that term had not been picked already. We know the term is > a workaround. Some just feel it is a bad workaround. I disagree, I'm not part of that consensus. From where I sit, AUTH is just as good a target for opportunism as ENC, it's something that can be reasonably left to a higher layer if that higher layer has some better approach. E.g., SSH & Skype. > For its > implied (misleading) meaning and for its terrible acronym of "OS". > > RFC 4949 states: > > $ security > 1a. (I) A system condition that results from the establishment and > maintenance of measures to protect the system. >From a human/user perspective, that's a very curious definition of security. I'd rather define security by the protection that the user usefully received than by measures that the system prescriptively stated and imposed on the hapless user. But, looking at the definition as it is writ: 'Measures' is left undefined by definition, probably outsourced to some model (or standard or whatever you want to call it). So in one hypothetical model, if 'Measures' equals encryption then the definition is met, yet in another hypothetical if 'Measures' equals authentication, it is also met. A system is therefore secure if it says it is. Opportunistic security therefore meets its own objectives because it says what it does; it just sets a variable number N of 'Measures' dynamically, doesn't fix them in static policy. > 1b. (I) A system condition in which system resources are free from > unauthorized access and from unauthorized or accidental change, > destruction, or loss. (Compare: safety.) Right, so this might be seen to set a higher conceptual set of requirements, closer to my view of usefully protecting the user, as opposed to 'Measures' in 1a. > 2. (I) Measures taken to protect a system. > > Tutorial: Parker [Park] suggests that providing a condition of > system security may involve the following six basic functions, > which overlap to some extent: > - "Deterrence": Reducing an intelligent threat by discouraging > action, such as by fear or doubt. (See: attack, threat action.) > - "Avoidance": Reducing a risk by either reducing the value of > the potential loss or reducing the probability that the loss > will occur. (See: risk analysis. Compare: "risk avoidance" > under "risk".) > - "Prevention": Impeding or thwarting a potential security > violation by deploying a countermeasure. > - "Detection": Determining that a security violation is > impending, is in progress, or has recently occurred, and thus > make it possible to reduce the potential loss. (See: intrusion > detection.) > - "Recovery": Restoring a normal state of system operation by > compensating for a security violation, possibly by eliminating > or repairing its effects. (See: contingency plan, main entry > for "recovery".) > - "Correction": Changing a security architecture to eliminate or > reduce the risk of reoccurrence of a security violation or > threat consequence, such as by eliminating a vulnerability. (These aren't 'Measures' of a security system as per 1a, they are more characteristics of a mitigation deriving from a risk analysis; to unify 1 & 2, perhaps mitigations is a better word for 1a than 'Measures'.) > The draft covers none of these listed items - it should not be called > "XXX security" Is it the consensus that RFC4949 should be followed on the definition of security? From the snippets above, I'd say that's a bad idea. But if so, let's say so... iang From nobody Sat Aug 16 06:12:35 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6491A878B; Sat, 16 Aug 2014 06:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNYNqS95NAHM; Sat, 16 Aug 2014 06:12:30 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3761A8784; Sat, 16 Aug 2014 06:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=VPEgyHFTFNl5awT/mVN4mxAqjM1OmXDosV1yTwDDJSc=; b=YHnOsRdSl3JDObXIRhJ+w/5u1liKswkgvdVswshElvM9HAJX++DtzZIAn3yUrKjMETrdUnFf7f+baJDZge7b3QWjZDwsgjnUha3J/Ap/qKE2H9IQD6UfC4ve09+TbgA9nbOjn7llV4u+sHjREkN6U3vNVDlScL5SKs8MHSwW3rc=; Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1XIdmV-0001fh-U5; Sat, 16 Aug 2014 13:12:28 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 4923F58424F; Sat, 16 Aug 2014 09:12:27 -0400 (EDT) Date: Sat, 16 Aug 2014 09:12:27 -0400 From: Theodore Ts'o To: saag@ietf.org, ietf@ietf.org Message-ID: <20140816131227.GA801@thunk.org> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140816044854.GB5476@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/saag/1HTHzyS4Z8vvAoCZTI_Qsim_KlU Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 13:12:32 -0000 On Sat, Aug 16, 2014 at 04:48:54AM +0000, Viktor Dukhovni wrote: > Except that it is different. There is no need to make a big "your > security may be degraded" fuss when doing better than expected. > However, when failing to achieve a security goal, and settling for > less, applications have tended to put up all sorts of warnings, > fussy dialogues, ... And are often unwilling to do less that the > maximum, and simply fail. > > The change of perspective is crucial to making progress. Cleartext > is the baseline, not comprehensive protection. You don't fall back > from comprehensive protection, when it is does not work out, ... > You do better than the baseline when that is possible, and just > works, without disrupting communication in the absence of an attack. Yes. This. It would be good to have something which states this explicitly in the introduction of the I-D. A careful reader can infer this, but I think it's good to state this explicitly. Something else that I think would be good to include in the introduction is as we improve from cleartext to "authenticated, encrypted, and protected against passive and active active attacks", that the way station of "protected only against passive attackers" is a _still_ better than just staying at cleartext. The second paragraph of the abstract: This document promotes designs in which cryptographic protection against both passive and active attacks can be rolled out incrementally as new systems are deployed, without creating barriers to communication. ... seemes to emphasize more the concept of "some of the time" and doesn't spell out that the rollout might include protection against passive attacks only as being (a) within the scope of this document, and (b) desirable if the alternative is cleartext. > This is a design guide (manifesto), not not a protocol specification, > and setting things in the right perspective matters. Something that might be useful along this front, if we can find an appropriate reference, is the (possibly apocryphal, or maybe the authorative source is classified, perhaps out of embarassment? :-) story about air force pilots who would deliberately disable their fancy NSA-provided crypto gear because in a combat situation, when friendly fire can really ruin your day (or not getting support to ground forces who were using an incompatible crypto system), communicating in the clear is far more important than not communicating at all.... - Ted From nobody Sat Aug 16 07:47:27 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F021A0ACE for ; Sat, 16 Aug 2014 07:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idS-BHvEv9-l for ; Sat, 16 Aug 2014 07:47:23 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BE741A0A2E for ; Sat, 16 Aug 2014 07:47:23 -0700 (PDT) Received: from [10.0.225.78] ([216.2.65.151]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7GElIMr001776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 16 Aug 2014 07:47:22 -0700 Message-ID: <53EF6E64.7080401@dcrocker.net> Date: Sat, 16 Aug 2014 07:44:52 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <20140815204814.GX5476@mournblade.imrryr.org> <20140815211950.GZ5476@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 16 Aug 2014 07:47:22 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/lKxNLUOdls54ThEUZnCzUQQ-9Jw Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 14:47:25 -0000 > the problem is that "opportunity" does not convey "as well as can be > done in the circumstances." it means "something that works." > > i can not think of an american english word that conveys what you want. > gambatte, which can mean "do your best," comes closer but is a verb. The usual phrase to approximate that meaning is "best effort". Not a single word, but a common enough term. The focus of the draft is quite clearly encryption. Any other security mechanism that is cited is in the service of encryption only. Hence the simplest, clearest and most intuitive term for what is being described is "best effort encryption". d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Aug 16 08:19:25 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FFE1A03FE for ; Sat, 16 Aug 2014 08:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewAHaR3ranra for ; Sat, 16 Aug 2014 08:19:22 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C8B81A02F1 for ; Sat, 16 Aug 2014 08:19:22 -0700 (PDT) Received: from [10.0.225.78] ([216.2.65.151]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7GFJH06002475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 16 Aug 2014 08:19:21 -0700 Message-ID: <53EF75E3.6020606@dcrocker.net> Date: Sat, 16 Aug 2014 08:16:51 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ianG , saag@ietf.org References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <53EF5848.4000200@iang.org> In-Reply-To: <53EF5848.4000200@iang.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 16 Aug 2014 08:19:21 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/35J5YoFcGvFADmOCNx_pb52B98I Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 15:19:23 -0000 On 8/16/2014 6:10 AM, ianG wrote: >> This draft proposes encryption in the possible absence of >> > authentication. While I can call it privacy or encryption, >> > I have a very hard time calling it security. On top of that, >> > we all know we would have called ie opportunistic encryption >> > if that term had not been picked already. We know the term is >> > a workaround. Some just feel it is a bad workaround. > > I disagree, I'm not part of that consensus. From where I sit, AUTH is > just as good a target for opportunism as ENC, it's something that can be > reasonably left to a higher layer if that higher layer has some better > approach. E.g., SSH & Skype. In a general discussion about 'flexibility' in security-related mechanisms, you would be correct. However the current draft has a more limited scope. Its focus is encryption. Any other security-related topic, such as authentication, is ONLY discussed in terms of encryption. I'll emphasize that the assertion of scope is not just what I'd like it to be but an observation of what the draft actually IS. This draft is not a general exploration of opportunism in the world of security mechanisms. It is supposed to be an attempt to define and explain flexibility in mechanisms providing encryption. It achieves the exploration. It lacks text that qualifies as a definition. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Aug 16 08:30:24 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AC11A0450 for ; Sat, 16 Aug 2014 08:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weE4PXkIPV7v for ; Sat, 16 Aug 2014 08:30:22 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35A21A0458 for ; Sat, 16 Aug 2014 08:30:21 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 4D1306D64E; Sat, 16 Aug 2014 11:30:18 -0400 (EDT) Message-ID: <53EF7909.8000702@iang.org> Date: Sat, 16 Aug 2014 16:30:17 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dcrocker@bbiw.net, saag@ietf.org References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <53EF5848.4000200@iang.org> <53EF75E3.6020606@dcrocker.net> In-Reply-To: <53EF75E3.6020606@dcrocker.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/0adqZEOwFsPIkMm6u69zoRO0BCY Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 15:30:23 -0000 On 16/08/2014 16:16 pm, Dave Crocker wrote: > On 8/16/2014 6:10 AM, ianG wrote: >>> This draft proposes encryption in the possible absence of >>>> authentication. While I can call it privacy or encryption, >>>> I have a very hard time calling it security. On top of that, >>>> we all know we would have called ie opportunistic encryption >>>> if that term had not been picked already. We know the term is >>>> a workaround. Some just feel it is a bad workaround. >> >> I disagree, I'm not part of that consensus. From where I sit, AUTH is >> just as good a target for opportunism as ENC, it's something that can be >> reasonably left to a higher layer if that higher layer has some better >> approach. E.g., SSH & Skype. > > > In a general discussion about 'flexibility' in security-related > mechanisms, you would be correct. > > However the current draft has a more limited scope. > > Its focus is encryption. Any other security-related topic, such as > authentication, is ONLY discussed in terms of encryption. > > I'll emphasize that the assertion of scope is not just what I'd like it > to be but an observation of what the draft actually IS. > > This draft is not a general exploration of opportunism in the world of > security mechanisms. It is supposed to be an attempt to define and > explain flexibility in mechanisms providing encryption. It achieves the > exploration. It lacks text that qualifies as a definition. I do not derive this assertion of scope from the draft. Can you outline where this limitation comes from? I'm aware that the inspiration for the draft comes from the PM side. But unless we believe that the anti-PM project only inspires hammers that will hammer anything to submission, nail or not, I can't see immediately why a tool can't be more general. iang From nobody Sat Aug 16 09:13:45 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFCF1A08F6; Fri, 15 Aug 2014 17:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4jgILl4h9ou; Fri, 15 Aug 2014 17:25:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B5B1A08EF; Fri, 15 Aug 2014 17:25:45 -0700 (PDT) Received: from [172.31.98.227] (static-72-87-239-124.lsanca.fios.verizon.net [72.87.239.124]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7G0PbKC011981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 15 Aug 2014 17:25:41 -0700 Message-ID: <53EEA46F.80006@bbiw.net> Date: Fri, 15 Aug 2014 17:23:11 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Kent , ietf@ietf.org, saag References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> In-Reply-To: <53EE7D42.2030900@bbn.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Fri, 15 Aug 2014 17:25:41 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_k2mqUew5fcJTJeRXyXfFe9kDoU X-Mailman-Approved-At: Sat, 16 Aug 2014 09:13:43 -0700 Subject: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 00:25:47 -0000 On 8/15/2014 2:36 PM, Stephen Kent wrote: > I’m not fond of the phrase “protocol design patternâ€. I don’t recall > ever hearing that phrase before. If you substituted “guidelines†or > “principle†for pattern that would be more in keeping with existing > terminology. I was surprised by the term, but mostly felt it was at least trying to move discussion in a useful direction, compared with earlier claims, such as that it was a 'protocol'. However a quick search on the term produced some troubling existing usages that conflict with the usage in the draft: http://en.wikipedia.org/wiki/Canonical_protocol_pattern "...a design pattern, applied within the service-orientation design paradigm, which attempts to make services, within a service inventory,[1] interoperable with each other by standardizing the communication protocols used by the services. This eliminates the need for bridging communication protocols when services use different communication protocols.[" and: http://www.eventhelix.com/realtimemantra/patterncatalog/protocol_layer.htm "Provide a common framework for implementing different layers of a protocol stack." d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Aug 16 09:13:46 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1B71A6F1F; Fri, 15 Aug 2014 21:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xmdq8AMjkEX; Fri, 15 Aug 2014 21:03:15 -0700 (PDT) Received: from ana-server.csail.mit.edu (ana-server.csail.mit.edu [18.26.1.3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A951A6F14; Fri, 15 Aug 2014 21:03:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ana-server.csail.mit.edu (Postfix) with ESMTP id 664A0224B7E0; Sat, 16 Aug 2014 00:03:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at ana-server.csail.mit.edu Received: from ana-server.csail.mit.edu ([127.0.0.1]) by localhost (ana-server.csail.mit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-wgyq-aG7Cg; Sat, 16 Aug 2014 00:03:13 -0400 (EDT) Received: from callisto-vi.venice.schlepp.org (cpe-23-243-25-223.socal.res.rr.com [23.243.25.223]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ana-server.csail.mit.edu (Postfix) with ESMTPSA id 089E7224B7C0; Sat, 16 Aug 2014 00:03:11 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Wroclawski In-Reply-To: <20140815211457.GY5476@mournblade.imrryr.org> Date: Fri, 15 Aug 2014 21:03:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> To: ietf@ietf.org, saag@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/o0Za11CzLCAz63OavNa5Hc_g6Jk X-Mailman-Approved-At: Sat, 16 Aug 2014 09:13:43 -0700 Cc: presnick@qti.qualcomm.com, dcrocker@bbiw.net Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 04:03:16 -0000 Oh *man* I=92m going to regret this. Hi. Jumping randomly into this conversation from the point of view of = someone who is fascinated by the dynamics but, yes, _has not read the = draft_, I=92d like to observe something. On Aug 15, 2014, at 2:14 PM, Viktor wrote: >> >=20 >> [D. Crocker] Opportunism is the flexibility to use less-stringent = protection, >> when stronger protection is not possible. >=20 > This is a definition of something else. That something is not the > subject of the draft. [=85] >=20 > The subject is introducing the OS design pattern. The OS design > pattern as introduced, is to set a least common denominator baseline > (crypto)security policy (that might well be cleartext) and from > there do better whenever possible for each peer. =46rom my point of view, these two wordings are indistinguishable. = Setting a least common denominator and doing better whenever possible = *is* using less-stringent protection when stronger protection is not = available. I understand there=92s nuance, relating to per-peer (which I = think everyone agrees with), to the multiple dimensions of protection, = and to whether =93none=94 is a variant of =93least=94 or not. But IMO, = fundamentally these two sentences say the same thing. If the intent is = that they don=92t, *very* different words may be needed. Similarly, On Aug 15, 2014, at 1:48 PM, Pete Resnick = wrote: > Hatless... >=20 > [=85] > Opportunism here is to take the opportunity to do the *best* = encryption you can do. If the other end advertises authenticated = encryption, you take the opportunity to do authenticated encryption. If = that's unavailable but you can do unauthenticated encryption, that's the = best you can do and you opportunistically do that. [=85] >=20 >> [Crocker, again] Opportunism is the flexibility to use less-stringent = protection, when stronger protection is not possible. >> =20 > Using less-stringent protection when stronger protection is not = available is not an "opportunity". It's a compromise.=20 Again, to my mind there is *no difference* between the words "If X is = unavailable but you can do Y, that's the best you can do and you = opportunistically do that=94 and the words "Using less-stringent = protection when stronger protection is not available =85=94, yet in one = case it=92s being given as an example and in the other case it=92s being = stated as an incorrect non-example. =93this won=92t do=94, as they say. To be clear: I am not at all meaning to pick on Victor or Pete or Dave = specifically. But I thought it might be useful to mention that from the = perspective of someone who=92s randomly walked into the back of the = virtual room and is trying to understand things just from the emails, = you guys are saying exactly the same thing, and then claiming you = aren=92t. cheers john From nobody Sat Aug 16 09:13:47 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FAC1A6F87; Fri, 15 Aug 2014 22:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFrwSK5hga9y; Fri, 15 Aug 2014 22:02:04 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.119]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74E41A6F82; Fri, 15 Aug 2014 22:02:03 -0700 (PDT) Received: from [193.109.255.147:13755] by server-15.bemta-14.messagelabs.com id B1/9F-30948-AC5EEE35; Sat, 16 Aug 2014 05:02:02 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-6.tower-72.messagelabs.com!1408165321!14628267!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28890 invoked from network); 16 Aug 2014 05:02:01 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-6.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 16 Aug 2014 05:02:01 -0000 Received: from EXHY022V.surrey.ac.uk (131.227.201.104) by EXHT012P.surrey.ac.uk (131.227.200.39) with Microsoft SMTP Server (TLS) id 8.3.348.2; Sat, 16 Aug 2014 06:02:01 +0100 Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.201.241) by EXHY022v.surrey.ac.uk (131.227.201.104) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sat, 16 Aug 2014 06:02:00 +0100 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB438.eurprd06.prod.outlook.com (10.242.23.15) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Sat, 16 Aug 2014 05:02:00 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.1005.010; Sat, 16 Aug 2014 05:02:00 +0000 From: To: , Thread-Topic: [saag]: Review of: Opportunistic Security -03 preview for comment Thread-Index: AQHPuM4M2vlp3TluK0OIDdsuruI/OJvSqWOAgAAAxPU= Date: Sat, 16 Aug 2014 05:01:59 +0000 Message-ID: <1408165319071.3283@surrey.ac.uk> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu>, <20140816044854.GB5476@mournblade.imrryr.org> In-Reply-To: <20140816044854.GB5476@mournblade.imrryr.org> Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [124.170.214.211] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0305463112 x-forefront-antispam-report: SFV:NSPM; SFS:(10019005)(6009001)(189002)(199003)(24454002)(377454003)(2656002)(81342001)(76482001)(36756003)(46102001)(87936001)(81542001)(64706001)(101416001)(15975445006)(80022001)(83322001)(15198665003)(19580395003)(66066001)(19580405001)(15202345003)(20776003)(21056001)(4396001)(107886001)(107046002)(95666004)(76176999)(85852003)(77982001)(83072002)(106356001)(86362001)(79102001)(15395725005)(105586002)(31966008)(92566001)(106116001)(74482001)(99396002)(74662001)(74502001)(92726001)(85306004)(54356999)(50986999)(2501001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR06MB438; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB438.eurprd06.prod.outlook.com X-CrossPremisesHeadersFiltered: EXHY022v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/saag/f7S0vlHIzxAk587ETVy6BB11Ca8 X-Mailman-Approved-At: Sat, 16 Aug 2014 09:13:43 -0700 Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 05:02:06 -0000 The phrase I would use here is something like 'graceful escalation in the s= ecurity of communication capability, from cleartext to best, and graceful d= egradation to cleartext as a minimum where necessary'. Only reworded to be = less wanky, of course.=0A= =0A= As Viktor says, in security minds, there does not appear to be a concept of= graceful degradation - either it's considered secure to all possible attac= ks, or it's (just) been broken and it's not - hence the whole never-ever-us= e-MD5-ever-in-any-context kerfluffle of old.=0A= =0A= Expanding the examples to cover http/https will give a better idea of the s= cope, I think.=0A= =0A= Lloyd Wood=0A= http://about.me/lloydwood=0A= ________________________________________=0A= From: ietf on behalf of Viktor Dukhovni =0A= Sent: Saturday, 16 August 2014 2:48 PM=0A= To: ietf@ietf.org; saag@ietf.org=0A= Subject: Re: [saag]: Review of: Opportunistic Security -03 preview for comm= ent=0A= =0A= On Fri, Aug 15, 2014 at 09:03:09PM -0700, John Wroclawski wrote:=0A= =0A= > From my point of view, these two wordings are indistinguishable.=0A= > Setting a least common denominator and doing better whenever possible=0A= > *is* using less-stringent protection when stronger protection is=0A= > not available. I understand there?s nuance, relating to per-peer=0A= > (which I think everyone agrees with), to the multiple dimensions=0A= > of protection, and to whether ?none? is a variant of ?least? or=0A= > not. But IMO, fundamentally these two sentences say the same thing.=0A= > If the intent is that they don?t, *very* different words may be=0A= > needed.=0A= =0A= Except that it is different. There is no need to make a big "your=0A= security may be degraded" fuss when doing better than expected.=0A= However, when failing to achieve a security goal, and settling for=0A= less, applications have tended to put up all sorts of warnings,=0A= fussy dialogues, ... And are often unwilling to do less that the=0A= maximum, and simply fail.=0A= =0A= The change of perspective is crucial to making progress. Cleartext=0A= is the baseline, not comprehensive protection. You don't fall back=0A= from comprehensive protection, when it is does not work out, ...=0A= You do better than the baseline when that is possible, and just=0A= works, without disrupting communication in the absence of an attack.=0A= =0A= This is a design guide (manifesto), not not a protocol specification,=0A= and setting things in the right perspective matters.=0A= =0A= It is important to understand that peer capabilities you can assume=0A= to be there are only those that are required and available to all=0A= peers, anything else is something that requires a specific capability=0A= advertisement.=0A= =0A= It makes little sense to talk about fallback from authenticated=0A= encryption, because authentication is mostly only useful when it=0A= is enforced. It makes more sense to talk about enforcing authentication=0A= when the peer publishes the appropriate key material (DANE, TACK,=0A= ...).=0A= =0A= The mandated model of security, where everybody has to implement=0A= it or they don't play the game, makes sense in top-down environments=0A= like the military or enterprises. It is not a good model for the=0A= Internet. We've tried it for a few decades now, it has not worked=0A= well. It is time for a more flexible, pragmatic approach. I expect=0A= opportunistic security to provide more security to more peers than=0A= the top-down models we've grown accustomed to.=0A= =0A= The language matters, it sets the correct mental model for moving=0A= forward. We need to prioritize the user's needs (move the bits)=0A= first, and layer as much security on top of that as we can, but no=0A= more. Yes, you can describe a fun-house mirror view of this, in=0A= which we're falling back from comprehensive security, But that is=0A= not a good way to think about it. Especially when you conclude=0A= that authentication is not opportunistic or cleartext is outside=0A= the artificial boundary drawn around opportunistic security,=0A= making just unauthenticated crypt be opportunistic security, and=0A= everything else is out.=0A= =0A= The result of that view would be everyone implementing unauthenticated=0A= crypto, and calling it a day. That would be a shame, because in=0A= the long run we do want protection from active attacks, and a way=0A= of getting that deployed, and enabled by default, and yet not=0A= disrupting communication when not under attack.=0A= =0A= Perhaps I should expand the example section to explain opportunistic=0A= DANE TLS for SMTP (even if that spec is still some weeks from LC),=0A= not just opportunistic TLS. Then people might have a better=0A= understanding of how opportunistic authentication works with DANE,=0A= and should work generally. I don't want the draft to over-emphasize=0A= DANE, it not just about DANE, but leaving out that example may have=0A= resulted in text that is a too abstract.=0A= =0A= --=0A= Viktor.=0A= =0A= From nobody Sat Aug 16 09:22:44 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5001B1A0AFE for ; Sat, 16 Aug 2014 09:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeiCyETNdYnp for ; Sat, 16 Aug 2014 09:22:42 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF201A0649 for ; Sat, 16 Aug 2014 09:22:41 -0700 (PDT) Received: from [10.0.225.78] ([216.2.65.151]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7GGMbBq003142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 16 Aug 2014 09:22:40 -0700 Message-ID: <53EF84BA.40208@dcrocker.net> Date: Sat, 16 Aug 2014 09:20:10 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ianG , saag@ietf.org References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <53EF5848.4000200@iang.org> <53EF75E3.6020606@dcrocker.net> <53EF7909.8000702@iang.org> In-Reply-To: <53EF7909.8000702@iang.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 16 Aug 2014 09:22:40 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/W53hN1IZ5TrYEnOl4gmrvDtqGy4 Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 16:22:43 -0000 On 8/16/2014 8:30 AM, ianG wrote: > On 16/08/2014 16:16 pm, Dave Crocker wrote: >> This draft is not a general exploration of opportunism in the world of >> security mechanisms. It is supposed to be an attempt to define and >> explain flexibility in mechanisms providing encryption. ... > I do not derive this assertion of scope from the draft. Can you outline > where this limitation comes from? It is pervasive in the document: > Abstract ... > For example, the majority of Internet > SMTP traffic is now opportunistically encrypted. No reference to authentication. > Terminology ... > Authenticated encryption: ... > Unauthenticated encryption: No definitions related to authentication itself. > 3. The Opportunistic Security Design Pattern > > Opportunistic Security is a protocol design pattern that aims to > remove barriers to the widespread use of encryption on the Internet. ... > o No encryption (cleartext), which provides no protection against ... > o Unauthenticated encryption (definition in Section 2), which ... > o Authenticated encryption, (definition in Section 2) which protects > against both passive and active attacks. ... > An opportunistic security protocol first determines the capabilities > of a peer. This might include whether that peer supports > authenticated encryption, unauthenticated encryption or perhaps only > cleartext. No equivalent, /separate/ reference to authentication or any other security mechanisms. The rest of that section continues with the same focus, as does the rest of the document. Throughout the draft, the standalone references -- that is the term that focuses a statement -- is either "opportunistic security" or "encryption". The first term is used, perhaps, as if it means more than encryption, but there is never any substance provided to make that real. All of the substance concerns encryption. I believe that's because that is the actual focus right now. I also believe that's entirely appropriate. Everything else is abstract and without current effort or, frankly, thought. Hence the term should make clear that the issue at hand is encryption. d/ -- -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Aug 16 11:46:12 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DAF1A011E for ; Sat, 16 Aug 2014 11:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSgyIPXcUwj2 for ; Sat, 16 Aug 2014 11:46:08 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02BA91A0119 for ; Sat, 16 Aug 2014 11:46:07 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id c11so2954074lbj.33 for ; Sat, 16 Aug 2014 11:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=M8tj56ahtdJcXrSUVVKdnHpZ5BVd8IlLtoWOCVkEzaQ=; b=GymUcJRj3IhhpzovjffdoOu/p2oMCveEZ11WjktNoE3nGNPSjCxP+Wf3TZHux17y/m Z5gpWcwWGuJtVniW75Z+oW9LveCiAZ6iBcrhY0PAf2XGME6via1LDr0MRaf8g/jyBjPi T2fv1YXSpD4hnmjABiCvGn1xah0oTdBq8N0zIAUvw/fXfoyWupKrawRtX/Aq+UTvidHm dtQHuracENFhmwJvMBvZC8WLyidNoLRJvtWsxvffFyxyFWRLnvPocqyHggwRflx6yriV zfDrwKjZRs/XRZ5bi9ABCpleQ/PY2sBh3ekukrJN9WuCR4QtFXrwzpcI0HdgFV4d/zC1 gsUg== MIME-Version: 1.0 X-Received: by 10.112.155.226 with SMTP id vz2mr18106988lbb.23.1408214766218; Sat, 16 Aug 2014 11:46:06 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Sat, 16 Aug 2014 11:46:06 -0700 (PDT) Date: Sat, 16 Aug 2014 14:46:06 -0400 Message-ID: From: Kathleen Moriarty To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=089e0118281ce8747e0500c38cbd Archived-At: http://mailarchive.ietf.org/arch/msg/saag/3g_S2x6Oxz7ovG12mm4UpihRWhM Subject: [saag] IETF90 Meeting Minutes X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 18:46:09 -0000 --089e0118281ce8747e0500c38cbd Content-Type: text/plain; charset=UTF-8 Hi, IETF 90 meeting minutes have been posted. A big thank you to Rich Salz for taking minutes and Melinda Shore for helping out in the jabber room. The audio had issues, so I couldn't verify a few names that were missed, so if you have any corrections (and you might), please let us know. https://datatracker.ietf.org/meeting/90/materials.html#sec Thanks! -- Best regards, Kathleen & Stephen --089e0118281ce8747e0500c38cbd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

IETF 90 meeting minutes have been p= osted. =C2=A0A big thank you to Rich Salz for taking minutes and Melinda Sh= ore for helping out in the jabber room. =C2=A0

The= audio had issues, so I couldn't verify a few names that were missed, s= o if you have any corrections (and you might), please let us know.


--089e0118281ce8747e0500c38cbd-- From nobody Sat Aug 16 13:03:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329C61A0252; Sat, 16 Aug 2014 13:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGUmAYyW0dvE; Sat, 16 Aug 2014 13:03:49 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27151A026A; Sat, 16 Aug 2014 13:03:48 -0700 (PDT) X-AuditID: 1209190d-f79c06d000002f07-10-53efb9225e2d Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 23.EC.12039.229BFE35; Sat, 16 Aug 2014 16:03:46 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s7GK3jvK009523; Sat, 16 Aug 2014 16:03:46 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7GK3gXG029717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 16 Aug 2014 16:03:44 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7GK3gZj003457; Sat, 16 Aug 2014 16:03:42 -0400 (EDT) Date: Sat, 16 Aug 2014 16:03:42 -0400 (EDT) From: Benjamin Kaduk To: Dave Crocker In-Reply-To: <53EEA46F.80006@bbiw.net> Message-ID: References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1817125620-1408219422=:21571" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42IR4hTV1lXa+T7YYOd2E4vfnz6wWTzbOJ/F Ykp/J5MDs8elnSfZPJYs+ckUwBTFZZOSmpNZllqkb5fAlXHvYDtjwRGRin2dO1gaGN8LdDFy ckgImEi8XtvGAmGLSVy4t54NxBYSmM0kceOaLoS9kVFi3hqhLkYuIPsQk8SPNV9ZIZwGRone 1+fBOlgEtCX+7GliArHZBFQkZr7ZCBTn4BABspdPiQYxmQXUJY5f0QOpEBYolLi5qwOsk1NA TeJIWy8ziM0r4CixdMJeJoi96xgldi4WBbFFBXQkVu+fwgJRIyhxcuYTMJtZIFDi0Ltp7BMY BWchSc1CkoKw1SUaH5xlg7C1Je7fbGNbwMiyilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdILzez RC81pXQTIzi8JXl3ML47qHSIUYCDUYmHV6DvfbAQa2JZcWXuIUZJDiYlUV7mbUAhvqT8lMqM xOKM+KLSnNTiQ4wSHMxKIrwztgLleFMSK6tSi/JhUtIcLErivG+trYKFBNITS1KzU1MLUotg sjIcHEoSvIw7gBoFi1LTUyvSMnNKENJMHJwgw3mAhr/YDjK8uCAxtzgzHSJ/ilFRSpw3FCQh AJLIKM2D64Wln1eM4kCvCPP+AaniAaYuuO5XQIOZgAbXbH4LMrgkESEl1cDoJjBrTd38FZH+ xhnqzvenS8mLVNlG/iyJe5W9pLhty6mAfY8/zy/gWN7Ilxt1ZctLocd/7ZfmT/nUK3Xv6JKI KVozv+zs+BzrKXd9efrrdJXO6RMfmZhkV3u9Nri6NPv+q/A5LD6Xdt+d4V76OKZ/wfdFEyuY E0J2vC95r8R4f+E08x8VcnkflViKMxINtZiLihMBPN8i3BoDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/saag/nwlkLfVnFvMc9Do1XVdqqgOpGYg Cc: ietf@ietf.org, saag Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 20:03:51 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1817125620-1408219422=:21571 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 15 Aug 2014, Dave Crocker wrote: > On 8/15/2014 2:36 PM, Stephen Kent wrote: > > I=E2=80=99m not fond of the phrase =E2=80=9Cprotocol design pattern=E2= =80=9D. I don=E2=80=99t recall > > ever hearing that phrase before. If you substituted =E2=80=9Cguidelines= =E2=80=9D or > > =E2=80=9Cprinciple=E2=80=9D for pattern that would be more in keeping w= ith existing > > terminology. > > > I was surprised by the term, but mostly felt it was at least trying to > move discussion in a useful direction, compared with earlier claims, > such as that it was a 'protocol'. > > > However a quick search on the term produced some troubling existing > usages that conflict with the usage in the draft: > > > http://en.wikipedia.org/wiki/Canonical_protocol_pattern > > "...a design pattern, applied within the service-orientation design > paradigm, which attempts to make services, within a service > inventory,[1] interoperable with each other by standardizing the > communication protocols used by the services. This eliminates the need > for bridging communication protocols when services use different > communication protocols.[" I only see this results for google(protocol design pattern), not google("protocol design pattern") (with quotes). > and: > > > http://www.eventhelix.com/realtimemantra/patterncatalog/protocol_layer.ht= m > > "Provide a common framework for implementing different layers of a > protocol stack." I do get several results from this site from google("protocol design pattern"), but apparently not this particular one (which is in particular a "protocol *layer* design pattern", which seems quite different. The links on that site that I did follow seem to be about having a software framework that facilitates implementations of protocols that share common design features. As we would like the draft under discussion to inspire future protocol designs to share some common design features (regarding choosing to use encryption and/or other security features), I do not think that the usage is incompatible with our proposal. I think that your observations may just be a failure of the search engine, which is not reflected in the current use among computer science professionals. -Ben ---559023410-1817125620-1408219422=:21571-- From nobody Sat Aug 16 13:07:14 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47FA1A0294; Sat, 16 Aug 2014 13:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wr7usgB3ycgn; Sat, 16 Aug 2014 13:07:10 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D99791A0252; Sat, 16 Aug 2014 13:07:10 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 882D221DE58; Sat, 16 Aug 2014 13:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=YDLMVnTAerbvbMhg5cQsRndew2M=; b=a4EmVAJllZ7 /Q46FpHoeuxjGW3pCbr//5JEuUmXIfasuQUhMtjhWMh1tnbobR7I8q/N9wgq9kHN CbO+ncL9q7e3Vddnxl6FqpBOjhSK6PHzcqaEKFVX4kixJMER5I0LIptXOBj9e6rh uAoEMYT0QKks7W13ajTRfb/52gcU5UYc= Received: from localhost (211.sub-70-192-132.myvzw.com [70.192.132.211]) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPA id C518621DE57; Sat, 16 Aug 2014 13:07:09 -0700 (PDT) Date: Sat, 16 Aug 2014 15:07:08 -0500 From: Nico Williams To: Dave Crocker Message-ID: <20140816200706.GA8110@localhost> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <53EEA46F.80006@bbiw.net> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/saag/o6de3FG-lMA6Y1-idCi_xbsye2c Cc: saag , Stephen Kent , ietf@ietf.org Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 20:07:12 -0000 On Fri, Aug 15, 2014 at 05:23:11PM -0700, Dave Crocker wrote: > On 8/15/2014 2:36 PM, Stephen Kent wrote: > > I=E2=80=99m not fond of the phrase =E2=80=9Cprotocol design pattern=E2= =80=9D. I don=E2=80=99t recall > > ever hearing that phrase before. If you substituted =E2=80=9Cguidelin= es=E2=80=9D or > > =E2=80=9Cprinciple=E2=80=9D for pattern that would be more in keeping= with existing > > terminology. >=20 > I was surprised by the term, but mostly felt it was at least trying to > move discussion in a useful direction, compared with earlier claims, > such as that it was a 'protocol'. >=20 > However a quick search on the term produced some troubling existing > usages that conflict with the usage in the draft: Bikeshedding is what this is. I'm under no illusions as to having a single dictionary of terminology in such a large group. In fact, I've no patience for these games; I recall vividly Stephen Kent trying to school me as to the meaning of "network authentication", whereupon I had to point him to the very TITLE of RFC1510 (fun times). It's true that terminology matters, don't get me wrong, but you're demanding a level of conflict-free terminology that is infeasible, while at the same time failing to convince anyone that there's a problem here. Really, "protocol design pattern" is problematic?! The question is not "can you find some past usage of this or that term that you can use to nitpick?". The question is: is the I-D clear? IMO: the I-D is quite clear. Serious arguments otherwise would be nice; text nice still. Another question, even more important, is whether OS (the proposed protocol design pattern, not the term) is on the right path or whether it is dangerous, or how to improve it. I've yet to see anargument that Viktor's OS proposal is weak tea, dangerous, or could be improved, only lots and lots of verbiage about verbiage. Nico --=20 From nobody Sat Aug 16 13:07:53 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D271A0252; Sat, 16 Aug 2014 13:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LcV-McCr7W7; Sat, 16 Aug 2014 13:07:49 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9591A02BD; Sat, 16 Aug 2014 13:07:49 -0700 (PDT) X-AuditID: 1209190e-f79946d000007db1-9d-53efba136d14 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 88.56.32177.31ABFE35; Sat, 16 Aug 2014 16:07:47 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s7GK7j9I016228; Sat, 16 Aug 2014 16:07:46 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7GK7itd030859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 16 Aug 2014 16:07:45 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7GK7hYK003960; Sat, 16 Aug 2014 16:07:43 -0400 (EDT) Date: Sat, 16 Aug 2014 16:07:43 -0400 (EDT) From: Benjamin Kaduk To: John Wroclawski In-Reply-To: <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> Message-ID: References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-213991652-1408219663=:21571" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IR4hRV1hXe9T7YYMsPU4tnG+ezWEzp72Ry YPJYsuQnUwBjFJdNSmpOZllqkb5dAlfGxd4VLAXPBSraP11jb2C8xNvFyMkhIWAisWnjFFYI W0ziwr31bF2MXBxCArOZJE6uOscE4WxklJgx6TEzhHOISWLy93tQZQ1Ambu72bsYOThYBLQl HhyUBhnFJqAiMfPNRjYQW0RAXWJp2zKwFcwCChKrXz5lAbGFBQIljn5uBbM5BRwldq5exgRi 8wLZ38/tg5p/j0ni9qROsEGiAjoSq/dPYYEoEpQ4OfMJC8TQAIkFlxewT2AUnIUkNQtJCsLW k3j1bz4jhK0tcf9mG9sCRpZVjLIpuVW6uYmZOcWpybrFyYl5ealFusZ6uZkleqkppZsYwSEt ybeD8etBpUOMAhyMSjy8O7rfBwuxJpYVV+YeYpTkYFIS5WXeBhTiS8pPqcxILM6ILyrNSS0+ xCjBwawkwjtjK1CONyWxsiq1KB8mJc3BoiTO+9baKlhIID2xJDU7NbUgtQgmK8PBoSTBu3UH UKNgUWp6akVaZk4JQpqJgxNkOA/Q8DiQGt7igsTc4sx0iPwpRkUpcd65IAkBkERGaR5cLyzl vGIUB3pFmHc9SBUPMF3Bdb8CGswENLhm81uQwSWJCCkpYHy/nviZc06Hucq659v/2mmXhItq f2fKmXpGRWHh5XNuL14mpizkY7iqouCZkBD1xroiYkfS5S/COxrDTwjcuDgt68Gc2jvaTClF ujWvjy+uu6x6uqwqwu/u0sp9p7/J5qgHX4vd/v7y9osTpKaK705SnXutYiu3ix9rGV/v5Pgz wgvdAhRWXVNiKc5INNRiLipOBADEb0lQFAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/saag/LDK1XT4WPJC7TD_RipwhKO41ZFg Cc: ietf@ietf.org, saag@ietf.org Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 20:07:51 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-213991652-1408219663=:21571 Content-Type: TEXT/PLAIN; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 16 Aug 2014, John Wroclawski wrote: > Oh *man* I=92m going to regret this. > > Hi. Jumping randomly into this conversation from the point of view of > someone who is fascinated by the dynamics but, yes, _has not read the > draft_, I=92d like to observe something. > > On Aug 15, 2014, at 2:14 PM, Viktor wrote: > > >> >> > >> [D. Crocker] Opportunism is the flexibility to use less-stringent = protection, > >> when stronger protection is not possible. > > > > This is a definition of something else. That something is not the > > subject of the draft. [=85] > > > > The subject is introducing the OS design pattern. The OS design > > pattern as introduced, is to set a least common denominator baseline > > (crypto)security policy (that might well be cleartext) and from > > there do better whenever possible for each peer. > > From my point of view, these two wordings are indistinguishable. Setting > a least common denominator and doing better whenever possible *is* using > less-stringent protection when stronger protection is not available. I > understand there=92s nuance, relating to per-peer (which I think everyone > agrees with), to the multiple dimensions of protection, and to whether > =93none=94 is a variant of =93least=94 or not. But IMO, fundamentally the= se two > sentences say the same thing. If the intent is that they don=92t, *very* > different words may be needed. [trimmed the other example] Perhaps the part that is missing is what Ted was referencing, namely the unstated goal that the baseline can be raised over time, after gradual adoption of the better-protection options has reached a sufficient proportion of the population such that the downside of increasing the baseline is minimal. -Ben ---559023410-213991652-1408219663=:21571-- From nobody Sat Aug 16 13:19:51 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3B71A02D6; Sat, 16 Aug 2014 13:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0vEE6gvVIp1; Sat, 16 Aug 2014 13:19:48 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A23D41A0294; Sat, 16 Aug 2014 13:19:48 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 85708584064; Sat, 16 Aug 2014 13:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=WedXDIr5nqsBfyGU9kpaz0tRYhM =; b=CQucNerKtNj0P0IexFzqKg1Fcqk9exCwYGdurjJcw5Zgq21Qtws+wrG0iKL u4r40LRyBA4gS8VQEiv3mDtSlUlSC/YeElEVeyZvTRdXXknk9XPGAGbIWy/9UKAb N2AyUrE5XRJYjLe/6hCxu5P/0nluJlQd+vs6nUftPvcm85f4= Received: from localhost (211.sub-70-192-132.myvzw.com [70.192.132.211]) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPA id 0E30A584059; Sat, 16 Aug 2014 13:19:47 -0700 (PDT) Date: Sat, 16 Aug 2014 15:19:47 -0500 From: Nico Williams To: saag@ietf.org, ietf@ietf.org Message-ID: <20140816201945.GC8110@localhost> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140816044854.GB5476@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/M6tLWekQwKHzQFxJYx7Fv3FZzZ0 Subject: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 20:19:49 -0000 On Sat, Aug 16, 2014 at 04:48:54AM +0000, Viktor Dukhovni wrote: > Perhaps I should expand the example section to explain opportunistic > DANE TLS for SMTP (even if that spec is still some weeks from LC), > not just opportunistic TLS. Then people might have a better > understanding of how opportunistic authentication works with DANE, > and should work generally. I don't want the draft to over-emphasize > DANE, it not just about DANE, but leaving out that example may have > resulted in text that is a too abstract. For me DANE is the critical piece to understanding how the OS protocol design pattern can raise the floor without lowering the ceiling and without encouraging a general reduction of security against active attacks. The key lies in DNSSEC's authenticated non-existence functionality. Nico -- From nobody Sat Aug 16 13:53:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5625F1A036A for ; Sat, 16 Aug 2014 13:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydwL29EKbjz8 for ; Sat, 16 Aug 2014 13:53:15 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9C31A032F for ; Sat, 16 Aug 2014 13:53:15 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 0E8A62007F011; Sat, 16 Aug 2014 13:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=X5uKfTLYohPxD8 RgM7YYJbizkjc=; b=Xq+S/77vPdnNU3UAvoL7V+r64hTdsvJNnnalEW+o26TzNP U4tkKxfh3XwglFK9f603sbopZdjvlwkQdHOHJ9jjxKTUMIMbGNKY4Wl2O652TQSy VHhUQunG6f+EZM3zdCIinGwrlICogKzaVx8wBg6drKMoz+khPQu07XXJMdcTU= Received: from localhost (211.sub-70-192-132.myvzw.com [70.192.132.211]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 597122007F005; Sat, 16 Aug 2014 13:53:14 -0700 (PDT) Date: Sat, 16 Aug 2014 15:53:13 -0500 From: Nico Williams To: dcrocker@bbiw.net Message-ID: <20140816205311.GE8110@localhost> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <53EF5848.4000200@iang.org> <53EF75E3.6020606@dcrocker.net> <53EF7909.8000702@iang.org> <53EF84BA.40208@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53EF84BA.40208@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/9qalkpdkpyTVavjnzqiOLso-VpA Cc: saag@ietf.org Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 20:53:16 -0000 On Sat, Aug 16, 2014 at 09:20:10AM -0700, Dave Crocker wrote: > On 8/16/2014 8:30 AM, ianG wrote: > > On 16/08/2014 16:16 pm, Dave Crocker wrote: > >> This draft is not a general exploration of opportunism in the world of > >> security mechanisms. It is supposed to be an attempt to define and > >> explain flexibility in mechanisms providing encryption. > ... > > I do not derive this assertion of scope from the draft. Can you outline > > where this limitation comes from? > > It is pervasive in the document: > > > Abstract > ... > > For example, the majority of Internet > > SMTP traffic is now opportunistically encrypted. > > No reference to authentication. That is a description of reality, and the reality is IIUC that SMTP is now opportunistically encrypted without authentication, thus no mention of it. Anyways, I don't see the abstract as evidence of any pervasive flaw in the I-D. It is true that SMTP -being a store-and-forward protocol- is a bit far removed from user experience (therefore authentication requirements and status are a bit difficult to denote), therefer perhaps not the best OS use case for this I-D, but it's also the _first_ and most widely deployed OS application, therefore it is a great use case for this I-D. It is what it is. > > Terminology > ... > > Authenticated encryption: > ... > > Unauthenticated encryption: > > No definitions related to authentication itself. Propose text! > > 3. The Opportunistic Security Design Pattern > > > > Opportunistic Security is a protocol design pattern that aims to > > remove barriers to the widespread use of encryption on the Internet. > ... > > o No encryption (cleartext), which provides no protection against > ... > > o Unauthenticated encryption (definition in Section 2), which > ... > > o Authenticated encryption, (definition in Section 2) which protects > > against both passive and active attacks. > ... > > An opportunistic security protocol first determines the capabilities > > of a peer. This might include whether that peer supports > > authenticated encryption, unauthenticated encryption or perhaps only > > cleartext. > > > No equivalent, /separate/ reference to authentication or any other > security mechanisms. Eh? As in integrity protection without confidentiality protection? If so, "meh". I don't think listing that would improve anything here. > Everything else is abstract and without current effort or, frankly, > thought. [...] It is abstract. Necessarily. Because it's not proposing specific protocols. The "without thought" part is clearly incorrect (is there any way to take it as anything other than intended to slight??). > [...]. Hence the term should make clear that the issue at hand is > encryption. You're the one focusing on encryption. The DANE use cases can result in strong authentication in addition to mere encryption! That makes "encryption" unsuitable for the term we need for this protocol design pattern: encryption is not the only trick this opportunistic pony can do. Nico -- From nobody Sat Aug 16 14:01:30 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278B41A038E for ; Sat, 16 Aug 2014 14:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m31gcKLpGbBL for ; Sat, 16 Aug 2014 14:01:20 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 331001A0386 for ; Sat, 16 Aug 2014 14:01:20 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id BABD92C806B; Sat, 16 Aug 2014 14:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=D3fVpcBxsv3YFF VFcYX/uQ1RYco=; b=ENqqDPMKTi2A2ntrEXkkKo101CDP6Azd9/mn0eGb6hkAh9 6M1PVcTOr5pXdsRYrC5/od5lpFO/7pCBsUBvoYX+Qlrf+t8lqrICsod2msd2O3uc dq9ejkzZ54azBRlrRFQ3xAwy2MJgubqCQHDEYNSPr6KlsbFdIvGBtElt3U9d0= Received: from localhost (211.sub-70-192-132.myvzw.com [70.192.132.211]) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPA id 43E892C8058; Sat, 16 Aug 2014 14:01:19 -0700 (PDT) Date: Sat, 16 Aug 2014 16:01:18 -0500 From: Nico Williams To: ianG Message-ID: <20140816210116.GF8110@localhost> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <53EF5848.4000200@iang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53EF5848.4000200@iang.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/eHhVNHBvmtV0wMkqEzevkEJuNEo Cc: saag@ietf.org Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 21:01:27 -0000 On Sat, Aug 16, 2014 at 02:10:32PM +0100, ianG wrote: > On 15/08/2014 21:29 pm, Paul Wouters wrote: > >> TLS -> TLE: Transport Layer Encryption? > >> IPsec -> IPenc: IP encryption? > >> SSH -> ESH: Encrypted SHell? > >> HTTPS -> HTTPE: HTTP over TLE? > >> ... > > > > All these four protocols require AUTHENTICATION plus ENCRYPTION. Thus Not. - SSH's initial success is largely due to TOFU. - TLS supports unauthenticated use cases (ADH ciphersuites). - IPsec has BTNS. > > there have a legitimate reason to call it security and not just > > encryption. > > Yes, but where is it written that SECURITY requires AUTH + ENC? As far > as I know, this derives from a model sometimes called the Internet > Threat Model, referenced in one of those RFCs that Stephen posted a > month back. The model itself dates back to CIA (the term not the > spooks) and military context where MITM is a game they play if they can. > > That's a particular model of security, or a pattern or a tradition. It > isn't synonymous with security per se. Right. Security is relative. Relative to: adversaries, and baselines. If your baseline is _no_ security, then any improvement _is_ "security" (again: SSH and TOFU). If the threat is massive collection of plaintext, then unauthenticated encryption is a massive improvement over cleartext communications. Security is a very relative term. Encryption pretty much isn't. Since encryption is meaningless without a discussion of key management, everyone I know in this industry regularly regards with scorn any product advertisements that highlight AES-256 or "256-bit security", and so on -- it's all snake oil unless all the details are discussed and analyzed. This is why "TLS" >> "AES" in marketing materials, for example. And this is why "security" >> "encryption" for the term at hand. Nico -- From nobody Sat Aug 16 14:04:58 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550181A036F for ; Sat, 16 Aug 2014 14:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_5_AdFhPjqz for ; Sat, 16 Aug 2014 14:04:55 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A14DF1A036D for ; Sat, 16 Aug 2014 14:04:55 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 83EF72C806B; Sat, 16 Aug 2014 14:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=iDGEoerRy8hyOl kQFAzNPd6cKOA=; b=pl1YNJ93rEOzSHZLOKLDvHIPV9B2tpUhwEMfUmh2dE90rN 508RnDJ6coW5ho5JJhqlrFLCn1v9EZ3taBYGBtjyXE38cyQ4cZJGNrcRNYesPzFv YhUBlZ2VF7oCHhfpHgCffVp5lJQhrjsHUZJ1FRsu93rZUrblrngN5soZI+iSE= Received: from localhost (211.sub-70-192-132.myvzw.com [70.192.132.211]) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPA id 0E5E52C8058; Sat, 16 Aug 2014 14:04:54 -0700 (PDT) Date: Sat, 16 Aug 2014 16:04:54 -0500 From: Nico Williams To: dcrocker@bbiw.net Message-ID: <20140816210452.GG8110@localhost> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <20140815204814.GX5476@mournblade.imrryr.org> <20140815211950.GZ5476@mournblade.imrryr.org> <53EF6E64.7080401@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53EF6E64.7080401@dcrocker.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/AX3GR3-i3h0EZKXWlIk8TMltG8o Cc: saag Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 21:04:56 -0000 On Sat, Aug 16, 2014 at 07:44:52AM -0700, Dave Crocker wrote: > > the problem is that "opportunity" does not convey "as well as can be > > done in the circumstances." it means "something that works." > > > > i can not think of an american english word that conveys what you want. > > gambatte, which can mean "do your best," comes closer but is a verb. > > The usual phrase to approximate that meaning is "best effort". No. "Best effort" has negative connotations. "Opportunistic" has both, negative and positive connotations. And the protocol design pattern at hand is very much a positive, not a negative. It would be destructive and awful marketing to settle for a term that has negative connotations when the thing for which the term will stand has positive value. > Not a single word, but a common enough term. > > The focus of the draft is quite clearly encryption. Any other security > mechanism that is cited is in the service of encryption only. > > Hence the simplest, clearest and most intuitive term for what is being > described is "best effort encryption". No, a thousand times no. It's not about encryption. It's about security. Security is a relative term (see separate post). See above as to "best effort". Nico -- From nobody Sat Aug 16 14:19:24 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05BA1A03D3 for ; Sat, 16 Aug 2014 14:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTr8ACowBqVE for ; Sat, 16 Aug 2014 14:19:22 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 241EF1A03CF for ; Sat, 16 Aug 2014 14:19:22 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id EC51B3B805B; Sat, 16 Aug 2014 14:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Kt2geYi1E/z039 Xvq70ZCa3KuEU=; b=B5zrV8J7l94ioUyyixBwFZmikuNQtsxCHhJRH3nPNzZPdx VXBdSgy1ZmOJC8veq/mmGXsXYyKjA/yZualmyKNM1vmjQQDbH9i1MTiz5GgBFMPy ASZ86+F4pRoDRqdsSIY6wDUjunkwIvWSr8I7cpnlMYVqAvdPAWYIVRVPfhlTQ= Received: from localhost (211.sub-70-192-132.myvzw.com [70.192.132.211]) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPA id 47B2C3B8059; Sat, 16 Aug 2014 14:19:21 -0700 (PDT) Date: Sat, 16 Aug 2014 16:19:20 -0500 From: Nico Williams To: ianG Message-ID: <20140816211918.GH8110@localhost> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <53EF5848.4000200@iang.org> <53EF75E3.6020606@dcrocker.net> <53EF7909.8000702@iang.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53EF7909.8000702@iang.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/BGdzYsJ0kWDGMU5naxRk1DeQRDU Cc: dcrocker@bbiw.net, saag@ietf.org Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 21:19:22 -0000 On Sat, Aug 16, 2014 at 04:30:17PM +0100, ianG wrote: > I'm aware that the inspiration for the draft comes from the PM side. > But unless we believe that the anti-PM project only inspires hammers > that will hammer anything to submission, nail or not, I can't see > immediately why a tool can't be more general. I believe technology is morally neutral. I have no idea what anti-PM technology will inspire, nor do I think that relevant here, though to humor you, my guess is that massive cleartext collectors won't pack it up and go home. I offer that guess to make this clear: OS is NOT about anti-PM, but about greatly improving security for every day users of the Internet. That's all neither here nor there. Anti-PM may or may not have been an inspiration for Viktor's I-D; either way is irrelevant at this point. These questions that I think are relevant: - Is the OS protocol design pattern bad in any way? It took me some time to reach my answer ("no"). DANE was the key to my reaching that answer. - Can we improve the proposed OS protocol design pattern? Questions as to wordsmithing are also relevant, but much less important than those two questions above. Thus far I see no one making any serious arguments that the proposed OS protocol design pattern is bad in any way except that it might encourage settling for unauthenticated encryption as the most common, and maybe only common usage. My answer to that (Viktor's answer to that!) is "DANE", and I believe this is fairly well accepted by now amongst reviewers who had this concern (which includes myself!). As for improvement on the protocol design pattern, so far I've seen no discussion. My take is that we have consensus about what matters most here. Publish the thing! Nico -- From nobody Sat Aug 16 14:52:28 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F58B1A03F6; Sat, 16 Aug 2014 14:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4_DXHZ11JKw; Sat, 16 Aug 2014 14:52:24 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB7C1A03F4; Sat, 16 Aug 2014 14:52:24 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id D3E55598058; Sat, 16 Aug 2014 14:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=inDcD0m6XPIYS5 L/PzTN243sTGA=; b=O4EDty9jj3771uDAdLs6x5zREQnBAmpLA2udQ+ETPVbvgL 88ahJhuGF6s/KB22GruJid9wmRREQ6/YEhWX4CLu9PX1wWel7bs+ixEHOgknZHS1 HMe4eKsE0cX3Hgr71BJtrMyb1QAzd7edV9dGenQJeSpIkuwK0gPB9RwB95FcI= Received: from localhost (211.sub-70-192-132.myvzw.com [70.192.132.211]) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPA id 3C6D1598057; Sat, 16 Aug 2014 14:52:23 -0700 (PDT) Date: Sat, 16 Aug 2014 16:52:22 -0500 From: Nico Williams To: Paul Wouters Message-ID: <20140816215220.GI8110@localhost> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <20140815204814.GX5476@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/2CSWKYVmCM047PnQpvtJh8A8azs Cc: saag@ietf.org, ietf@ietf.org Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 21:52:25 -0000 On Fri, Aug 15, 2014 at 05:06:45PM -0400, Paul Wouters wrote: > On Fri, 15 Aug 2014, Viktor Dukhovni wrote: > >Opportunistic DANE TLS for SMTP is security > > Some disagree about the use of the term opportunistic in this case. > If an SMTP client supports DANE, and is contacting an SMTP server > supporting DANE, there is nothing opportunistic about it. It MUST use > encryption and MUST NOT fall back to cleartext. I suppoe it's all about definitions. Viktor's point is that the client is willing to use TLS or not depending on whether it knows (local config) or could know (DANE) that it must, with the latter being opportunistic. The opportunity in the DANE case is really the server's: if it publishes TLSA RRsets... > >It is security against passive attacks, > >that is, for a different threat model. > > I don't disagree. But it is still only encryption. > > >I would have objected regardless. Opportunistic security is a > >better match than OE for the content of the draft. I would not > >have objected to Opportunistic Cryptosecurity, but it is not a > >compelling improvement. > > While not compelling, it is an improvement :P Cryptosecurity reals like snake oil to me. Or, at least, that's how I fear it will read to non-initiates. I _feel_ that cryptosecurity is worse than not an improvement. It's a feeling, difficult to back up with facts and readon. But bikeshedding is like that (please do not take that as an insult. Bikeshedding is a very common kind of argument, and I've done it myself. It happens, we call it, and then generally it ends.). From nobody Sat Aug 16 15:07:34 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C609D1A03F8 for ; Sat, 16 Aug 2014 15:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R40BNwIXddB2 for ; Sat, 16 Aug 2014 15:07:31 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F831A03F6 for ; Sat, 16 Aug 2014 15:07:31 -0700 (PDT) Received: from [10.0.225.78] ([216.2.65.151]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7GM7Ru4008615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 16 Aug 2014 15:07:30 -0700 Message-ID: <53EFD58C.9040500@dcrocker.net> Date: Sat, 16 Aug 2014 15:05:00 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nico Williams References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <53EF5848.4000200@iang.org> <53EF75E3.6020606@dcrocker.net> <53EF7909.8000702@iang.org> <53EF84BA.40208@dcrocker.net> <20140816205311.GE8110@localhost> In-Reply-To: <20140816205311.GE8110@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 16 Aug 2014 15:07:30 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/IQnxM0VxfJlvrrPKKpcAvaUZMRw Cc: saag@ietf.org Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 22:07:33 -0000 On 8/16/2014 1:53 PM, Nico Williams wrote: > On Sat, Aug 16, 2014 at 09:20:10AM -0700, Dave Crocker wrote: >> On 8/16/2014 8:30 AM, ianG wrote: >>> On 16/08/2014 16:16 pm, Dave Crocker wrote: >>>> This draft is not a general exploration of opportunism in the world of >>>> security mechanisms. It is supposed to be an attempt to define and >>>> explain flexibility in mechanisms providing encryption. >> ... >>> I do not derive this assertion of scope from the draft. Can you outline >>> where this limitation comes from? Please note that my message was in response to this query by you. I provided documentation of the document's limited scope. The limitation is in the nature of what it discusses and what it does not discuss. >> It is pervasive in the document: >> >>> Abstract >> ... >>> For example, the majority of Internet >>> SMTP traffic is now opportunistically encrypted. >> >> No reference to authentication. > > That is a description of reality, That's not the point. The point is that it is what the document discusses. >>> Terminology >> ... >>> Authenticated encryption: >> ... >>> Unauthenticated encryption: >> >> No definitions related to authentication itself. > > Propose text! No. I documented the reality of what the document discusses. I happen to agree with that limited scope, so I've no interesting in aiding the mistake of expanding it. Since you are so enthusiastic about insisting that its scope be expanded, the task of providing text falls on you. >>> 3. The Opportunistic Security Design Pattern >>> >>> Opportunistic Security is a protocol design pattern that aims to >>> remove barriers to the widespread use of encryption on the Internet. >> ... >>> o No encryption (cleartext), which provides no protection against >> ... >>> o Unauthenticated encryption (definition in Section 2), which >> ... >>> o Authenticated encryption, (definition in Section 2) which protects >>> against both passive and active attacks. >> ... >>> An opportunistic security protocol first determines the capabilities >>> of a peer. This might include whether that peer supports >>> authenticated encryption, unauthenticated encryption or perhaps only >>> cleartext. >> >> >> No equivalent, /separate/ reference to authentication or any other >> security mechanisms. > > Eh? As in integrity protection without confidentiality protection? If > so, "meh". I don't think listing that would improve anything here. Again, the issue I was responding to was not about 'improving' the document (nor about its 'deficiencies, but documenting that its content is clearly limited quite strictly to a focus on encryption. >> [...]. Hence the term should make clear that the issue at hand is >> encryption. > > You're the one focusing on encryption. The document is. The burden now falls on you to cite text in the draft that does not have encryption as its focus. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Aug 16 15:44:33 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0781A0491 for ; Sat, 16 Aug 2014 15:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqFp40_kMHYZ for ; Sat, 16 Aug 2014 15:44:29 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0051A048F for ; Sat, 16 Aug 2014 15:44:29 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 12BBC4012D694 for ; Sat, 16 Aug 2014 15:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=dKKQ8Sl8UVGboGZAvxs7 N6uoWBU=; b=eydrDyOegD8rbCLrEXKuOo5ERwFpfYlvd2dPl3Yr+3mETT090FAT XgpHUtrT3hqbU6I1kU64cdLdTAAQOwkMgs1qIlWLnnS5LFjAVxyH5YRASBqnsTPA du0ttflJ16ot8LngB1aBVk/49ogmp+ahgo8If/uH26hvWHSisT5ee+g= Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id B7FDD4012D68E for ; Sat, 16 Aug 2014 15:44:28 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so3579031wev.41 for ; Sat, 16 Aug 2014 15:44:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.39.73 with SMTP id n9mr30569705wik.70.1408229067393; Sat, 16 Aug 2014 15:44:27 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Sat, 16 Aug 2014 15:44:27 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Sat, 16 Aug 2014 15:44:27 -0700 (PDT) In-Reply-To: <53EFD58C.9040500@dcrocker.net> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <53EF5848.4000200@iang.org> <53EF75E3.6020606@dcrocker.net> <53EF7909.8000702@iang.org> <53EF84BA.40208@dcrocker.net> <20140816205311.GE8110@localhost> <53EFD58C.9040500@dcrocker.net> Date: Sat, 16 Aug 2014 17:44:27 -0500 Message-ID: From: Nico Williams To: Dave Crocker Content-Type: multipart/alternative; boundary=001a1135edf05311710500c6e1e0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Y-Y_M_m2V6NiLFIPp4vV7XTc7M4 Cc: saag@ietf.org Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 22:44:30 -0000 --001a1135edf05311710500c6e1e0 Content-Type: text/plain; charset=UTF-8 On Aug 16, 2014 6:07 PM, "Dave Crocker" wrote: > > Since you are so enthusiastic about insisting that its scope be > expanded, the task of providing text falls on you. If the proposed score expansion is to include ESP Null, then "meh". If the proposed expansion is to cover authentication, then that is already covered. Perhaps you want more emphasis given to it? If the proposed score expansion is something else, please restate it. There has been so much written so far that I've lost track. --001a1135edf05311710500c6e1e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 16, 2014 6:07 PM, "Dave Crocker" <dhc@dcrocker.net> wrote:
>
> Since you are so enthusiastic about insisting that its scope be
> expanded, the task of providing text falls on you.

If the proposed score expansion is to include ESP Null, then= "meh".

If the proposed expansion is to cover authentication, then t= hat is already covered.=C2=A0 Perhaps you want more emphasis given to it?

If the proposed score expansion is something else, please re= state it.=C2=A0 There has been so much written so far that I've lost tr= ack.

--001a1135edf05311710500c6e1e0-- From nobody Sat Aug 16 16:01:58 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC281A0491 for ; Sat, 16 Aug 2014 16:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzMQujA3FZWy for ; Sat, 16 Aug 2014 16:01:54 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE0A1A0489 for ; Sat, 16 Aug 2014 16:01:54 -0700 (PDT) Received: from [10.0.225.78] ([216.2.65.151]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7GN1oMj009207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 16 Aug 2014 16:01:54 -0700 Message-ID: <53EFE24B.1060305@dcrocker.net> Date: Sat, 16 Aug 2014 15:59:23 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nico Williams References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <53EF5848.4000200@iang.org> <53EF75E3.6020606@dcrocker.net> <53EF7909.8000702@iang.org> <53EF84BA.40208@dcrocker.net> <20140816205311.GE8110@localhost> <53EFD58C.9040500@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 16 Aug 2014 16:01:54 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/BsUA0HBNGLHAzKYZfv-F4fGmD6A Cc: saag@ietf.org Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 23:01:57 -0000 On 8/16/2014 3:44 PM, Nico Williams wrote: > On Aug 16, 2014 6:07 PM, "Dave Crocker" > wrote: >> >> Since you are so enthusiastic about insisting that its scope be >> expanded, the task of providing text falls on you. ... > If the proposed expansion is to cover authentication, then that is > already covered. Perhaps you want more emphasis given to it? The only discussion that the draft has about authentication is in terms of encryption. There is no standalone discussion of anything that might be taken as "opportunistic authentication" or even an indication of what that means. > If the proposed score expansion is something else, please restate it. Again, Nico, I am not proposing an expansion of scope. You are claiming it's already expanded and I have documented that it is not. > There has been so much written so far that I've lost track. Indeed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Aug 16 19:24:00 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AADC11A066B for ; Sat, 16 Aug 2014 19:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-fPwmqYUlz0 for ; Sat, 16 Aug 2014 19:23:57 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D8DB21A0669 for ; Sat, 16 Aug 2014 19:23:57 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 8AE5A21DE58 for ; Sat, 16 Aug 2014 19:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=xNxsTDOq58rtc4JpYjXF W1QYzxs=; b=IylHzoz79k5qfuAPbtJzxHnAhtqb76TQFvjxqpLQxlOHklWSIGtG gVkZwHhUER1YRVOHMwERqbIHfiDrxHCaJVFXL2tghUPHhUVLBdAHtfScRAmZxY/h A+aph4D5LEtxEySN5ddv9mMsZXNomHAvkINliEdkuK6HkEISy9bWHzo= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 378AF21DE57 for ; Sat, 16 Aug 2014 19:23:57 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id l18so3525168wgh.13 for ; Sat, 16 Aug 2014 19:23:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.84.105 with SMTP id x9mr32229631wjy.67.1408242235785; Sat, 16 Aug 2014 19:23:55 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Sat, 16 Aug 2014 19:23:55 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Sat, 16 Aug 2014 19:23:55 -0700 (PDT) In-Reply-To: <53EFE24B.1060305@dcrocker.net> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <53EF5848.4000200@iang.org> <53EF75E3.6020606@dcrocker.net> <53EF7909.8000702@iang.org> <53EF84BA.40208@dcrocker.net> <20140816205311.GE8110@localhost> <53EFD58C.9040500@dcrocker.net> <53EFE24B.1060305@dcrocker.net> Date: Sat, 16 Aug 2014 21:23:55 -0500 Message-ID: From: Nico Williams To: Dave Crocker Content-Type: multipart/alternative; boundary=047d7bb042e838c8b50500c9f23f Archived-At: http://mailarchive.ietf.org/arch/msg/saag/pg3K6RS8Z19oL_GiEvpW9NuSbAs Cc: saag@ietf.org Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 02:23:58 -0000 --047d7bb042e838c8b50500c9f23f Content-Type: text/plain; charset=UTF-8 On Aug 16, 2014 7:01 PM, "Dave Crocker" wrote: > > On 8/16/2014 3:44 PM, Nico Williams wrote: > > On Aug 16, 2014 6:07 PM, "Dave Crocker" > > wrote: > >> > >> Since you are so enthusiastic about insisting that its scope be > >> expanded, the task of providing text falls on you. > ... > > If the proposed expansion is to cover authentication, then that is > > already covered. Perhaps you want more emphasis given to it? > > The only discussion that the draft has about authentication is in terms > of encryption. > > There is no standalone discussion of anything that might be taken as > "opportunistic authentication" or even an indication of what that means. There is. I'm not in a position to quote from it at the moment though. > > If the proposed score expansion is something else, please restate it. > > Again, Nico, I am not proposing an expansion of scope. You are claiming > it's already expanded and I have documented that it is not. Are we reading the same I-D? But look, I have opined that more text on the DANE case would be good. Would that satisfy you? (If so I'll have completely misunderstood you earlier.) Nico -- --047d7bb042e838c8b50500c9f23f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 16, 2014 7:01 PM, "Dave Crocker" <dhc@dcrocker.net> wrote:
>
> On 8/16/2014 3:44 PM, Nico Williams wrote:
> > On Aug 16, 2014 6:07 PM, "Dave Crocker" <dhc@dcrocker.net
> > <mailto:dhc@dcrocker.net>> wrote:
> >>
> >> Since you are so enthusiastic about insisting that its scope = be
> >> expanded, the task of providing text falls on you.
> ...
> > If the proposed expansion is to cover authentication, then that i= s
> > already covered.=C2=A0 Perhaps you want more emphasis given to it= ?
>
> The only discussion that the draft has about authentication is in term= s
> of encryption.
>
> There is no standalone discussion of anything that might be taken as > "opportunistic authentication" or even an indication of what= that means.

There is.=C2=A0 I'm not in a position to quote from it a= t the moment though.

> > If the proposed score expansion is something else,= please restate it.
>
> Again, Nico, I am not proposing an expansion of scope.=C2=A0 You are c= laiming
> it's already expanded and I have documented that it is not.

Are we reading the same I-D?=C2=A0 But look, I have opined t= hat more text on the DANE case would be good.=C2=A0 Would that satisfy you?= =C2=A0 (If so I'll have completely misunderstood you earlier.)

Nico
--

--047d7bb042e838c8b50500c9f23f-- From nobody Sat Aug 16 20:13:32 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BF11A068F; Sat, 16 Aug 2014 20:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWQC_lvCeDAW; Sat, 16 Aug 2014 20:13:26 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC551A068E; Sat, 16 Aug 2014 20:13:25 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so3486827lam.14 for ; Sat, 16 Aug 2014 20:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=im9P1Q9RVzMRlnW9Z3iVSzkHvdZQXd8BAoR4EP/mwe0=; b=qghYvpm+/iWo0VWa2q5OY5F9Jly/d7UOyYy083PhWGA1dWnD34TsoIsYqHGAdCwJR0 rKvK5n4aYwJ7jg19xZfwsmuANfR05jGRmXm78AtNhuqwYm32HXsKctwhzaHAsXMNnsKz N5GT54MnKKGlXtVvC96eGmqX4i7VzawEohHRLzkVT/B5d49vkvjdQW06PbXUCRJYfEKB HexUKgwg4QL4PZEx98L91CL2tipq5mPztYCltMfCFGp+VXuvk1/nDVlx4KnDeLOrEIcj R2wZeF9LkTjlUkSCfFbzE04lFWvF7srLnHvBWcuDi5QfYAqNfs+flo9WlbbXtuu84Bsp VxBQ== MIME-Version: 1.0 X-Received: by 10.152.25.170 with SMTP id d10mr20627049lag.37.1408245203956; Sat, 16 Aug 2014 20:13:23 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Sat, 16 Aug 2014 20:13:23 -0700 (PDT) In-Reply-To: <20140816201945.GC8110@localhost> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> Date: Sat, 16 Aug 2014 23:13:23 -0400 X-Google-Sender-Auth: -tUJCX9-vTLrs0KEXXviAcCI7_g Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/8Ml_PQkjRP_gc3I_lph2zFC8FaM Cc: "saag@ietf.org" , IETF Discussion Mailing List Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 03:13:27 -0000 On Sat, Aug 16, 2014 at 4:19 PM, Nico Williams wrote: > On Sat, Aug 16, 2014 at 04:48:54AM +0000, Viktor Dukhovni wrote: >> Perhaps I should expand the example section to explain opportunistic >> DANE TLS for SMTP (even if that spec is still some weeks from LC), >> not just opportunistic TLS. Then people might have a better >> understanding of how opportunistic authentication works with DANE, >> and should work generally. I don't want the draft to over-emphasize >> DANE, it not just about DANE, but leaving out that example may have >> resulted in text that is a too abstract. > > For me DANE is the critical piece to understanding how the OS protocol > design pattern can raise the floor without lowering the ceiling and > without encouraging a general reduction of security against active > attacks. The key lies in DNSSEC's authenticated non-existence > functionality. ??? DANE isn't opportunistic security. It is authenticated security policy and keys. Thats the opposite of opportunistic. From nobody Sat Aug 16 20:18:04 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D831A069C; Sat, 16 Aug 2014 20:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29YyyeTYYsWt; Sat, 16 Aug 2014 20:18:01 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66E0C1A0699; Sat, 16 Aug 2014 20:18:01 -0700 (PDT) X-AuditID: 1209190e-f79946d000007db1-f9-53f01ee87e54 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 39.DC.32177.8EE10F35; Sat, 16 Aug 2014 23:18:00 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s7H3HxTC003239; Sat, 16 Aug 2014 23:17:59 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7H3HvIk029487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 16 Aug 2014 23:17:58 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7H3HunR027512; Sat, 16 Aug 2014 23:17:56 -0400 (EDT) Date: Sat, 16 Aug 2014 23:17:56 -0400 (EDT) From: Benjamin Kaduk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsUixG6nrvtC7kOwwfHpvBbPNs5nsZj4YTaj xZT+TiYHZo8Lq78yeSxZ8pMpgCmKyyYlNSezLLVI3y6BK6OhZSprwQ7uio/LvzM2MM7i7GLk 4JAQMJGYMtO0i5ETyBSTuHBvPVsXIxeHkMBsJokvT+ewgiSEBDYySlxb5QeROMQkcffffnYI p4FR4uTPTmaQKhYBbYlZEz+ygNhsAioSM99sZAOxRQQMJB5uvsQEYjMLREnsXLcRrEZYoFji 6ZW1YDanQKDE1q5P7CA2r4CjxOdTd1ggFnxmljh5bTfYGaICOhKr909hgSgSlDg58wkLxFAt ieXTt7FMYBSchSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1jvdzMEr3UlNJNjKCg 5ZTk28H49aDSIUYBDkYlHt4d3e+DhVgTy4orcw8xSnIwKYnyvmb7ECzEl5SfUpmRWJwRX1Sa k1p8iFGCg1lJhPfPPqBy3pTEyqrUonyYlDQHi5I471trq2AhgfTEktTs1NSC1CKYrAwHh5IE b7cs0FDBotT01Iq0zJwShDQTByfIcB6g4dNAaniLCxJzizPTIfKnGBWlxHl7ZIASAiCJjNI8 uF5YUnnFKA70ijBvC0g7DzAhwXW/AhrMBDS4ZvNbkMEliQgpqQbGNRcM/3ut2cC4QipS3Cpo 6522ntP9e+wr1uY7n73CvW3/EYPIK8sClAXLgl6EMVkGbNUNPDb1burSK1PnT1ko/Ip9R3Xx TaeoG9czzh56p7z60t2rO1V65+rPq8/f4M1z7afF/P98fiUvtM3/8un5NAWxss2KT+BJbCtJ z+Hi45VTTuz79HWiEktxRqKhFnNRcSIAfXoHdwUDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/saag/b5mOajwPI_sX_M5g7EamMwCCyGk Cc: "saag@ietf.org" , IETF Discussion Mailing List Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 03:18:03 -0000 On Sat, 16 Aug 2014, Phillip Hallam-Baker wrote: > On Sat, Aug 16, 2014 at 4:19 PM, Nico Williams wrote: > > On Sat, Aug 16, 2014 at 04:48:54AM +0000, Viktor Dukhovni wrote: > >> Perhaps I should expand the example section to explain opportunistic > >> DANE TLS for SMTP (even if that spec is still some weeks from LC), > >> not just opportunistic TLS. Then people might have a better > >> understanding of how opportunistic authentication works with DANE, > >> and should work generally. I don't want the draft to over-emphasize > >> DANE, it not just about DANE, but leaving out that example may have > >> resulted in text that is a too abstract. > > > > For me DANE is the critical piece to understanding how the OS protocol > > design pattern can raise the floor without lowering the ceiling and > > without encouraging a general reduction of security against active > > attacks. The key lies in DNSSEC's authenticated non-existence > > functionality. > > ??? > > DANE isn't opportunistic security. It is authenticated security policy > and keys. Thats the opposite of opportunistic. There is a protocol design pattern that involves optimistically checking for and using DANE records where they exist, and not using them when their existence has been authoritatively denied. The overall protocol is optimistic, in that the use of DANE is not required, but its benefits are used when available. -Ben From nobody Sun Aug 17 06:23:32 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C501A08BC; Sun, 17 Aug 2014 06:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuKskRipGQB2; Sun, 17 Aug 2014 06:23:29 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629641A08B7; Sun, 17 Aug 2014 06:23:29 -0700 (PDT) Received: from [10.0.224.145] ([216.2.65.151]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7HDNNaJ030768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 17 Aug 2014 06:23:26 -0700 Message-ID: <53F0AC37.4040701@dcrocker.net> Date: Sun, 17 Aug 2014 06:20:55 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Benjamin Kaduk , Phillip Hallam-Baker References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 17 Aug 2014 06:23:27 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/OG5C7l1jOxzEa3db4RwqOg9dpSw Cc: "saag@ietf.org" , IETF Discussion Mailing List Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 13:23:30 -0000 On 8/16/2014 8:17 PM, Benjamin Kaduk wrote: > On Sat, 16 Aug 2014, Phillip Hallam-Baker wrote: >>> DANE isn't opportunistic security. It is authenticated security >>> policy and keys. Thats the opposite of opportunistic. > There is a protocol design pattern that involves optimistically > checking for and using DANE records where they exist, This is an example of confusion about the meaning of the term design pattern. It is, equally, an example of the draft's limitation in carefully documenting the concepts it is attempt to teach. There is nothing in the document that clarifies the point. By my reading of the current draft, it discusses the distinction between authenticated and unauthenticated encryption. However it does not indicate that there is an important difference between one kind of authenticated versus another kind of authenticated. In other words, does the term design pattern concern basic functional differences (eg, authenticated vs. not authenticated) or does it concern specific functional differences (CA-based authenticated vs. DANE-based authenticated)? My own view is that the utility of the term offered in the current draft concerns only very basis differences, and such details as which kind of exsternal authentication 'anchor' is used is of less import. Well... perhaps the difference between a TOFU and an "anchored" authenticated matter. But I do not see what significant utility is achieved by distinguishing between different types of anchored (independent, fixed, ...) authentication is used. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Aug 17 06:30:51 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42681A08CC for ; Sun, 17 Aug 2014 06:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5Lv6wF98c4r for ; Sun, 17 Aug 2014 06:30:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8399F1A08CA for ; Sun, 17 Aug 2014 06:30:45 -0700 (PDT) Received: from [10.0.224.145] ([216.2.65.151]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7HDUfSn030868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 17 Aug 2014 06:30:44 -0700 Message-ID: <53F0ADED.5060002@dcrocker.net> Date: Sun, 17 Aug 2014 06:28:13 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nico Williams References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <53EF5848.4000200@iang.org> <53EF75E3.6020606@dcrocker.net> <53EF7909.8000702@iang.org> <53EF84BA.40208@dcrocker.net> <20140816205311.GE8110@localhost> <53EFD58C.9040500@dcrocker.net> <53EFE24B.1060305@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 17 Aug 2014 06:30:44 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/GXbtCGYC2FWDhgD2dFlZt65YxuA Cc: saag@ietf.org Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 13:30:48 -0000 On 8/16/2014 7:23 PM, Nico Williams wrote: >> There is no standalone discussion of anything that might be taken as >> "opportunistic authentication" or even an indication of what that means. > > There is. I'm not in a position to quote from it at the moment though. Then you have some homework to do. Please do post another note when you have found the necessary details. >> > If the proposed score expansion is something else, please restate it. >> >> Again, Nico, I am not proposing an expansion of scope. You are claiming >> it's already expanded and I have documented that it is not. > > Are we reading the same I-D? Probably not. However I've made a point of documenting what I've seen in the draft. Your turn. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Aug 17 06:52:39 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533091A090E for ; Sun, 17 Aug 2014 06:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5xOnUBUFqVe for ; Sun, 17 Aug 2014 06:52:36 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 060E41A090D for ; Sun, 17 Aug 2014 06:52:36 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id CB67E6D74C; Sun, 17 Aug 2014 09:52:32 -0400 (EDT) Message-ID: <53F0B39F.90003@iang.org> Date: Sun, 17 Aug 2014 14:52:31 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> In-Reply-To: <53F0AC37.4040701@dcrocker.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/lc-eG1SwbOBO9yWUvacx-I7vvjA Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 13:52:37 -0000 On 17/08/2014 14:20 pm, Dave Crocker wrote: > On 8/16/2014 8:17 PM, Benjamin Kaduk wrote: >> On Sat, 16 Aug 2014, Phillip Hallam-Baker wrote: >>>> DANE isn't opportunistic security. It is authenticated security >>>> policy and keys. Thats the opposite of opportunistic. >> There is a protocol design pattern that involves optimistically >> checking for and using DANE records where they exist, > > > > This is an example of confusion about the meaning of the term design > pattern. It is, equally, an example of the draft's limitation in > carefully documenting the concepts it is attempt to teach. I am not confused at all about the term 'design pattern', it's a term in wide-spread usage. I'd also say that if there is any confusion, the draft is not the right place for that to be defined. Once the draft decides to define concepts and terms in ordinary and routine use, then it's gone too far. (OK, so perhaps the words above should have read: DANE follows the OS design pattern of optimistically checking...) > There is nothing in the document that clarifies the point. > > By my reading of the current draft, it discusses the distinction between > authenticated and unauthenticated encryption. However it does not > indicate that there is an important difference between one kind of > authenticated versus another kind of authenticated. It should not need to do that. The point is to take auth as opportunistic in general and not to categorise different ways of doing auth. > In other words, does the term design pattern concern basic functional > differences (eg, authenticated vs. not authenticated) or does it concern > specific functional differences (CA-based authenticated vs. DANE-based > authenticated)? The term design pattern can do either. But the use of the term in the draft is to indicate that any auth method, be it ca or dane, can be seen as an element in an opportunistic approach. Once you see many auth methods as just more tools in the kit, there is no point in cataloging them. > My own view is that the utility of the term offered in the current draft > concerns only very basis differences, and such details as which kind of > exsternal authentication 'anchor' is used is of less import. > > Well... perhaps the difference between a TOFU and an "anchored" > authenticated matter. But I do not see what significant utility is > achieved by distinguishing between different types of anchored > (independent, fixed, ...) authentication is used. If there is a point, it is to show that we can pick and choose? In order to illustrate the sense of the design pattern at hand. iang From nobody Sun Aug 17 06:56:35 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B6F1A0920 for ; Sun, 17 Aug 2014 06:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSohNt_4IuVi for ; Sun, 17 Aug 2014 06:56:33 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B301D1A091D for ; Sun, 17 Aug 2014 06:56:33 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id D4C086D81E; Sun, 17 Aug 2014 09:56:32 -0400 (EDT) Message-ID: <53F0B490.4040407@iang.org> Date: Sun, 17 Aug 2014 14:56:32 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815191129.GV5476@mournblade.imrryr.org> <53EF5848.4000200@iang.org> <53EF75E3.6020606@dcrocker.net> <53EF7909.8000702@iang.org> <53EF84BA.40208@dcrocker.net> <20140816205311.GE8110@localhost> <53EFD58C.9040500@dcrocker.net> <53EFE24B.1060305@dcrocker.net> In-Reply-To: <53EFE24B.1060305@dcrocker.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/eQR5vkNpl5__ht3xnqHBa35uksY Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 13:56:34 -0000 On 16/08/2014 23:59 pm, Dave Crocker wrote: > On 8/16/2014 3:44 PM, Nico Williams wrote: >> On Aug 16, 2014 6:07 PM, "Dave Crocker" > > wrote: >>> >>> Since you are so enthusiastic about insisting that its scope be >>> expanded, the task of providing text falls on you. > ... >> If the proposed expansion is to cover authentication, then that is >> already covered. Perhaps you want more emphasis given to it? > > The only discussion that the draft has about authentication is in terms > of encryption. > > There is no standalone discussion of anything that might be taken as > "opportunistic authentication" or even an indication of what that means. Perhaps the problem here is that the draft title should be seen as more like: "Opportunistic Security, with examples for encryption." iang From nobody Sun Aug 17 07:44:39 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3161A0A05; Sun, 17 Aug 2014 07:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiGTgWdcwLPj; Sun, 17 Aug 2014 07:44:36 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2741E1A0A02; Sun, 17 Aug 2014 07:44:36 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6112480048; Sun, 17 Aug 2014 10:44:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1408286674; bh=jGfUM/WN0Guufs/glSVbbwnFbGpiNBfw7ggvsku0CvY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=d+/pr58cd6f943TJzFCdhrFO4jVtfp2Ca+nvtvk3eZrYteyMYmEiRYKuWFQlBPDnh z0GhVnOH7IUzMnywSAsRKkp+4uWfmY54jh+Z9qKqt8fqzCzyVWnwdyYvDy17tDCstI hsDLnrNsMuqecYyrTSZl/1hm0ncRMfMdr6Wq6qu0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s7HEiWf5005258; Sun, 17 Aug 2014 10:44:33 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 17 Aug 2014 10:44:32 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/789cpjuFDBi9oPi5VxRtkuiGbP4 Cc: "saag@ietf.org" , IETF Discussion Mailing List Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 14:44:37 -0000 On Sat, 16 Aug 2014, Phillip Hallam-Baker wrote: >> For me DANE is the critical piece to understanding how the OS protocol >> design pattern can raise the floor without lowering the ceiling and >> without encouraging a general reduction of security against active >> attacks. The key lies in DNSSEC's authenticated non-existence >> functionality. > > ??? > > DANE isn't opportunistic security. It is authenticated security policy > and keys. Thats the opposite of opportunistic. And this is why OS is a bad term. People still don't see this new term as meaning "do authenticated encryption protocols when possible, anonymous encryption with fallback to clear if not". Paul From nobody Sun Aug 17 07:58:55 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2741A09D3; Sun, 17 Aug 2014 07:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPxkX7Bu_jNl; Sun, 17 Aug 2014 07:58:51 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6051A09A7; Sun, 17 Aug 2014 07:58:51 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6096880048; Sun, 17 Aug 2014 10:58:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1408287530; bh=7Zl67rPIwi6Je2EXjI2/n/2BWhZgKl7PpQY76A6pB1U=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=EevlUGQ64TgvRYax5JVoS1AW5uvMcM71UbSQn2QipGz3vaxJomdvV+Ci37LBGEKY2 ffXocfIcxNZPY6GCAQCfDxNP4UJgwGcOBAX2dHb89eidwxh0bM+uQ5OfuLnYtjBfNU JLNVX+2v6Sb9i5gNMcYtAI8/Lo530cq3u52OiD74= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s7HEwmBJ005666; Sun, 17 Aug 2014 10:58:48 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 17 Aug 2014 10:58:48 -0400 (EDT) From: Paul Wouters To: Nico Williams In-Reply-To: <20140816200706.GA8110@localhost> Message-ID: References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ZH1xk--k0Bb847ZA5Cg7hcdFwUQ Cc: ietf@ietf.org, Dave Crocker , saag Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 14:58:52 -0000 On Sat, 16 Aug 2014, Nico Williams wrote: >> However a quick search on the term produced some troubling existing >> usages that conflict with the usage in the draft: > > Bikeshedding is what this is. Except in this day, the bikeshed needn't have a name. Our products are RFC numbers. As I said before, why define a term that we can't agree on? Just call this document something like "Defending against pervasive monitors". Get rid of "OS" and "opportunistic security" and "design patterns". That's the actual bikeshed paint we don't need. > Another question, even more important, is whether OS (the proposed > protocol design pattern, not the term) is on the right path or whether > it is dangerous, or how to improve it. I've yet to see anargument that > Viktor's OS proposal is weak tea, dangerous, or could be improved, only > lots and lots of verbiage about verbiage. I've actually contributed quite some text for clarifications (see git history) and I know others have too, despite the paint discussion). I've also suggested this document brings in mroe technical content helping protocol designs but to some that seemed out of scope and a matter for another document. To me, once you remove the sillyness of the terminology, this document is precisely about giving protocol engineers generic help. Things I came up with that I think belong in this document - encrypt as much as possibly as soon as possible. eg no SNI style leaks - Mandate PFS/session keys protection (Viktor included that in -03) - Don't ask more identifying data then you need for protocol functioning (generic privacy/anonimity practises) - Follow RFCs as strict as possible to defeat fingerprinting attacks - If a connection is one-sided authenticated (eg like TLS) ensure your protocol is okay with a role-reversal (eg if it needs to authenticate the end that was anonymous) - Ensure crypto agility doesn't come at the cost of more RTTs when the world moves to something stronger (eg the IKE modp problem) Paul From nobody Sun Aug 17 10:29:51 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FB11A0AFF; Sun, 17 Aug 2014 10:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8wSvwDbyXyc; Sun, 17 Aug 2014 10:29:47 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D7F551A0AF9; Sun, 17 Aug 2014 10:29:47 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id AFA6E77805B; Sun, 17 Aug 2014 10:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=c8AIOgs4NBmAH5g98drr MSTJk3k=; b=ft2kjBa73TIf3PbLYrGKKJyFoGNcQ2DOV+sUik5Qwb/1wNEU6otd iLi0xRN8Rr+tQw3+HZA7t3Kxcfd5fB3oChO4BumpIqdfNNVNOvmXDATMB3PFNzv0 IDMtIosmbTH+6QabI+VfQJw0oATyC7wT1R1h3Sw0vsOEy3Ep5WE5FrM= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 34CB7778057; Sun, 17 Aug 2014 10:29:47 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id bs8so2720664wib.3 for ; Sun, 17 Aug 2014 10:29:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.11.10 with SMTP id m10mr34713729wjb.77.1408296585891; Sun, 17 Aug 2014 10:29:45 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Sun, 17 Aug 2014 10:29:45 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Sun, 17 Aug 2014 10:29:45 -0700 (PDT) In-Reply-To: References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> Date: Sun, 17 Aug 2014 12:29:45 -0500 Message-ID: From: Nico Williams To: Paul Wouters Content-Type: multipart/alternative; boundary=047d7b5d436ebd9e010500d6997b Archived-At: http://mailarchive.ietf.org/arch/msg/saag/81pLpsvnYNQGV7KyfJNkda2fyXI Cc: saag , Dave Crocker , ietf@ietf.org Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 17:29:49 -0000 --047d7b5d436ebd9e010500d6997b Content-Type: text/plain; charset=UTF-8 On Aug 17, 2014 10:58 AM, "Paul Wouters" wrote: > > On Sat, 16 Aug 2014, Nico Williams wrote: > >>> However a quick search on the term produced some troubling existing >>> usages that conflict with the usage in the draft: >> >> >> Bikeshedding is what this is. > > > Except in this day, the bikeshed needn't have a name. Our products are > RFC numbers. As I said before, why define a term that we can't agree on? Jonh Doe: this is a new utility shed design, it's highly portable and variably sized. Jane Doe: but the examples are kinda focused on bikes, and anyways, that's what it's clearly designed around, so just call it a bikeshed. John: but you could store lawnmowers, shovels, .. Jane: your use of the term general utility is not really common place and no one well understand it. John: you're just bikeshedding! Jane: see? it's a bikeshed, and anyways, i don't care what color you paint it, this is about the name of the thing. :) IMO it's bikeshedding the name. We could be minting new words and it wouldn't be a problem: because by giving them this meaning we'd overcome the objection that until now they were meaningless.y I assume there are no objections to the substance now. Publish it! Nico -- --047d7b5d436ebd9e010500d6997b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 17, 2014 10:58 AM, "Paul Wouters" <paul@nohats.ca> wrote:
>
> On Sat, 16 Aug 2014, Nico Williams wrote:
>
>>> However a quick search on the term produced some troubling exi= sting
>>> usages that conflict with the usage in the draft:
>>
>>
>> Bikeshedding is what this is.
>
>
> Except in this day, the bikeshed needn't have a name. Our products= are
> RFC numbers. As I said before, why define a term that we can't agr= ee on?

Jonh Doe: this is a new utility shed design, it's highly= portable and variably sized.

Jane Doe: but the examples are kinda focused on bikes, and a= nyways, that's what it's clearly designed around, so just call it a= bikeshed.

John: but you could store lawnmowers, shovels, ..

Jane: your use of the term general utility is not really com= mon place and no one well understand it.

John: you're just bikeshedding!

Jane: see?=C2=A0 it's a bikeshed, and anyways, i don'= ;t care what color you paint it, this is about the name of the thing.

:)

IMO it's bikeshedding the name.=C2=A0 We could be mintin= g new words and it wouldn't be a problem: because by giving them this m= eaning we'd overcome the objection that until now they were meaningless= .y

I assume there are no objections to the substance now.=C2=A0= Publish it!

Nico
--

--047d7b5d436ebd9e010500d6997b-- From nobody Sun Aug 17 21:20:55 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE771A02A5; Sun, 17 Aug 2014 21:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9w57rCroRUJ; Sun, 17 Aug 2014 21:20:48 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E09F1A02A3; Sun, 17 Aug 2014 21:20:47 -0700 (PDT) X-AuditID: 12074425-f79766d000006da8-47-53f17f1efb9f Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id E9.74.28072.E1F71F35; Mon, 18 Aug 2014 00:20:46 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s7I4Kiae027192; Mon, 18 Aug 2014 00:20:45 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7I4Kgio018983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Aug 2014 00:20:44 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7I4KgV7004878; Mon, 18 Aug 2014 00:20:42 -0400 (EDT) Date: Mon, 18 Aug 2014 00:20:41 -0400 (EDT) From: Benjamin Kaduk To: dcrocker@bbiw.net In-Reply-To: <53F0AC37.4040701@dcrocker.net> Message-ID: References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixCmqrStX/zHYYOkHGYvfnz6wWTzbOJ/F Ykp/J5MDs8elnSfZPJYs+ckUwBTFZZOSmpNZllqkb5fAlXGvbQV7QadwxYSfj9gaGLfwdzFy cEgImEgs+a/bxcgJZIpJXLi3nq2LkYtDSGA2k8Tq/tVMEM5GRonL634wQjiHmCT+HFgPlWlg lJi7qo0ZpJ9FQFvi5rfjLCA2m4CKxMw3G9lAbBEBUYmee3uYQGxmgSiJnes2gtUICxRLPL2y FszmFNCRmHP/F9gcXgFHiW8bdrFALDjNIvF7/muwZlGgotX7p7BAFAlKnJz5hAViqJbE8unb WCYwCs5CkpqFJLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRroVebmaJXmpK6SZGUNiyu6ju YJxwSOkQowAHoxIP74K3H4KFWBPLiitzDzFKcjApifJyln4MFuJLyk+pzEgszogvKs1JLT7E KMHBrCTC+6oCKMebklhZlVqUD5OS5mBREud9a20VLCSQnliSmp2aWpBaBJOV4eBQkuC9VgvU KFiUmp5akZaZU4KQZuLgBBnOAzT8L0gNb3FBYm5xZjpE/hSjopQ4rxNIQgAkkVGaB9cLSyuv GMWBXhHmvQ1SxQNMSXDdr4AGMwENrtn8FmRwSSJCSqqB0fPLYiau3QLhtoJtUl92rehojPcJ P9arlMG/eZPXtVsdDksWJT6cOMtp2YeaqTE1fQ8dopIYmWTXBkjIPfoRveYw15X3YQvf2vf/ jNBfbJ8qc8bryZVv2QEdr9yb+PoOLFp5I2q/WH/anMTjzHM/fDLcx/dzmtvFLYeXVyob6Z+R 7BBZ7bD1lBJLcUaioRZzUXEiACNdd80GAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/saag/5vh_kX-27lhiTlJItDp8OLZXQ9w Cc: "saag@ietf.org" , IETF Discussion Mailing List Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 04:20:51 -0000 On Sun, 17 Aug 2014, Dave Crocker wrote: > On 8/16/2014 8:17 PM, Benjamin Kaduk wrote: > > On Sat, 16 Aug 2014, Phillip Hallam-Baker wrote: > >>> DANE isn't opportunistic security. It is authenticated security > >>> policy and keys. Thats the opposite of opportunistic. > > There is a protocol design pattern that involves optimistically > > checking for and using DANE records where they exist, > > > > This is an example of confusion about the meaning of the term design > pattern. It is, equally, an example of the draft's limitation in > carefully documenting the concepts it is attempt to teach. I hope you will forgive my confusion, but I'm not sure what confusion my statement is supposed to be an example of. My best hypothesis so far is that this is supposed to refer to your question about whether the term "design pattern" concerns basic functional differences or specific functional differences, but I'm not entirely sure. > There is nothing in the document that clarifies the point. I do not dispute that the draft could make this point in a much clearer fashion; I have not gone over it with a fine-enough-toothed comb to make the claim that it contains "nothing" to clarify the point, though. > By my reading of the current draft, it discusses the distinction between > authenticated and unauthenticated encryption. However it does not > indicate that there is an important difference between one kind of > authenticated versus another kind of authenticated. > > In other words, does the term design pattern concern basic functional > differences (eg, authenticated vs. not authenticated) or does it concern > specific functional differences (CA-based authenticated vs. DANE-based > authenticated)? > > My own view is that the utility of the term offered in the current draft > concerns only very basis differences, and such details as which kind of > exsternal authentication 'anchor' is used is of less import. I would say that the term "design pattern" can apply to either basic or specific differences, depending on the context in which it is being applied. In this specific case, I would like it to actually apply to both (in that I see the optimistic security family of protocols including both general recommendations ("use encryption") and specific ones ("if you can use DANE as a trust anchor, attempt to do so, but fall back if there is no record"). -Ben From nobody Mon Aug 18 08:35:43 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD811A064B; Mon, 18 Aug 2014 08:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCvmovRCofzN; Mon, 18 Aug 2014 08:35:39 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADDE1A0564; Mon, 18 Aug 2014 08:35:39 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id C229A94059; Mon, 18 Aug 2014 08:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=5ZcZEx5bskpemMEcc4bk Jy+pFMg=; b=Tu9rGa+4j8qs06fRQ1qMi9OddXpobgo2I088CosA8+es+Pnstgil dUkEGR0VdTw179om6ma7DBBatEuDgLmj1i4d2hQNlUHA2d2tV/59niHanovjb+bR uvi1qz/glHiosvVnQLGcuNDT0HyNK03d6wZsVq4fDux/c8K29NUj/1g= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 37E5C9405E; Mon, 18 Aug 2014 08:35:37 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id x48so5225492wes.31 for ; Mon, 18 Aug 2014 08:35:36 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.72.209 with SMTP id f17mr37515026wiv.3.1408376136719; Mon, 18 Aug 2014 08:35:36 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Mon, 18 Aug 2014 08:35:36 -0700 (PDT) In-Reply-To: References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> Date: Mon, 18 Aug 2014 10:35:36 -0500 Message-ID: From: Nico Williams To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ZbRt2Kuk2B4jgHvBMOAX2GSHdGc Cc: "ietf@ietf.org" , Dave Crocker , saag Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 15:35:40 -0000 On Sun, Aug 17, 2014 at 9:58 AM, Paul Wouters wrote: > I've actually contributed quite some text for clarifications (see git > history) and I know others have too, despite the paint discussion). > I've also suggested this document brings in mroe technical content helping > protocol designs but to some that seemed out of scope and a matter for > another document. To me, once you remove the sillyness of the terminology, > this document is precisely about giving protocol engineers generic help. The silliness or not of the terminology is bikeshedding about terminology. > Things I came up with that I think belong in this document > > - encrypt as much as possibly as soon as possible. eg no SNI style leaks I agree, though this seems rather generic, not so specific to OS. > - Mandate PFS/session keys protection (Viktor included that in -03) Hmmm. I agree that when opportunistically engaging in unauthenticated encryption key agreement should be used, and public keys should be fresh enough that PFS results. I think that's pretty obvious. But I don't think we should mandate PFS for all OS cases. Again, this seems like a generic recommendation/requirement, not specific to OS. > - Don't ask more identifying data then you need for protocol functioning > (generic privacy/anonimity practises) Agreed. > - Follow RFCs as strict as possible to defeat fingerprinting attacks Agreed, but again: too generic. > - If a connection is one-sided authenticated (eg like TLS) ensure your > protocol is okay with a role-reversal (eg if it needs to authenticate > the end that was anonymous) Ditto. > - Ensure crypto agility doesn't come at the cost of more RTTs when the > world moves to something stronger (eg the IKE modp problem) Ditto. I don't think this I-D should become a dumping ground of good security protocol design patterns. It's just one pattern. Nico -- From nobody Mon Aug 18 08:41:44 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40AD1A066B for ; Mon, 18 Aug 2014 08:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AthTHLJJ_w6o for ; Mon, 18 Aug 2014 08:41:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6671A0667 for ; Mon, 18 Aug 2014 08:41:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIJ33710; Mon, 18 Aug 2014 15:41:37 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0158.001; Mon, 18 Aug 2014 16:41:33 +0100 From: Hosnieh Rafiee To: "saag@ietf.org" Thread-Topic: secauth requirements and usecase scenarios Thread-Index: AQHPuvlTiR67p5JpjEijne3xoJQcO5vWfQuQ Date: Mon, 18 Aug 2014 15:41:33 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: multipart/mixed; boundary="_002_814D0BFB77D95844A01CA29B44CBF8A7A27C16lhreml513mbbchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/saag/u5pyzHpFIaWmamsrJGKf1YFQxlc Subject: [saag] secauth requirements and usecase scenarios X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 15:41:41 -0000 --_002_814D0BFB77D95844A01CA29B44CBF8A7A27C16lhreml513mbbchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Just in case you are not aware of the activities of this secauth group.=20 < https://www.ietf.org/mailman/listinfo/secauth > I haven't yet submitted this document to IETF but would like to receive som= e comments before to do so. Please share your comments either editorial or technical. :-) thanks Hosnieh --_002_814D0BFB77D95844A01CA29B44CBF8A7A27C16lhreml513mbbchina_ Content-Type: application/msword; name="secauth_requirements.doc" Content-Description: secauth_requirements.doc Content-Disposition: attachment; filename="secauth_requirements.doc"; size=73728; creation-date="Mon, 18 Aug 2014 15:16:41 GMT"; modification-date="Mon, 18 Aug 2014 15:16:45 GMT" Content-ID: <053C87FA6E67F149A6D9E21DE8726909@huawei.com> Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAhwAAAAAAAAAA EAAAigAAAAEAAAD+////AAAAAIUAAACGAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEABoAJBAAA8BK/AAAAAAAAMAAAAAAACAAAs0UAAA4AYmpiarSitKIAAAAAAAAAAAAAAAAAAAAA AAAJBBYAOHgAANbIAADWyAAADz0AAAAAAACjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAAFoNAAAAAAAAWg0AAJ0a AAAAAAAAnRoAAAAAAACdGgAAAAAAAJ0aAAAAAAAAnRoAABQAAAAAAAAAAAAAAP////8AAAAAsRoA AAAAAACxGgAAAAAAALEaAAA4AAAA6RoAAAwAAAD1GgAAxAAAALEaAAAAAAAA6lkAAC4CAAC5GwAA AAAAALkbAAA6AAAA8xsAAAAAAADzGwAAAAAAAPMbAAAAAAAAUx0AAAAAAABTHQAAAAAAAFMdAAAA AAAAjVkAAAIAAACPWQAAAAAAAI9ZAAAAAAAAj1kAAAAAAACPWQAAAAAAAI9ZAAAAAAAAj1kAAAAA AAAYXAAAogIAALpeAABOAAAAj1kAABUAAAAAAAAAAAAAAAAAAAAAAAAAnRoAAAAAAABTHQAAAAAA AAAAAAAAAAAAAAAAAAAAAABTHQAAAAAAAFMdAAAAAAAAUx0AAAAAAABTHQAAAAAAAI9ZAAAAAAAA AAAAAAAAAACdGgAAAAAAAJ0aAAAAAAAA8xsAAAAAAAAAAAAAAAAAAPMbAABgAQAApFkAABYAAAA7 LAAAAAAAADssAAAAAAAAOywAAAAAAABTHQAAhgIAAJ0aAAAAAAAA8xsAAAAAAACdGgAAAAAAAPMb AAAAAAAAjVkAAAAAAAAAAAAAAAAAADssAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAUx0AAAAAAACNWQAAAAAAAAAAAAAAAAAAOywAAAAAAAA7LAAA pgEAAEVTAAAQAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5VYAAAAAAADzGwAAAAAAAP////8AAAAAEIjTave6 zwEAAAAAAAAAALEaAAAAAAAA2R8AAPoGAABVVgAAJAAAAAAAAAAAAAAAeVkAABQAAAC6WQAAMAAA AOpZAAAAAAAAeVYAAGwAAAAIXwAAAAAAANMmAABoBQAACF8AAEgAAADlVgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADl VgAAFAAAAAhfAAAAAAAAAAAAAAAAAACdGgAAAAAAAPlWAACAAgAAUx0AAAAAAABTHQAAAAAAADss AAAAAAAAUx0AAAAAAABTHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUx0A AAAAAABTHQAAAAAAAFMdAAAAAAAAj1kAAAAAAACPWQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAOywAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFMdAAAA AAAAUx0AAAAAAABTHQAAAAAAAOpZAAAAAAAAUx0AAAAAAABTHQAAAAAAAFMdAAAAAAAAUx0AAAAA AAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA AP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAAhfAAAAAAAAUx0AAAAAAABT HQAAAAAAAFMdAAAAAAAAUx0AAAAAAABTHQAAAAAAAFMdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABTHQAAAAAAAFMdAAAAAAAAUx0A AAAAAABaDQAACQwAAGMZAAA6AQAABQASAQAACQQECAEEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0NDVNl Y2F1dGggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEguIFJhZmllZQ1JTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAgICBIdWF3ZWkg VGVjaG5vbG9naWVzIER1ZXNzZWxkb3JmIEdtYkgNSW50ZW5kZWQgU3RhdHVzOiBJbmZvcm1hdGlv bmFsIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDUV4cGlyZXM6IEZl YnJ1YXJ5IDE4LCAyMDE1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAxOCwg MjAxNA0NDSAgICAgICAgICAgICAgICAgICAgU2VjYXV0aCBVc2VjYXNlcyBhbmQgUmVxdWlyZW1l bnRzDSAgICAgICAgICAgICAgICAgIDxkcmFmdC1yYWZpZWUtc2VjYXV0aC11c2VjYXNlLTAwLnR4 dD4NDUFic3RyYWN0DQ0gICBUaGlzIGRvY3VtZW50IGV4cGxhaW5zIHRoZSB1c2UgY2FzZXMgYW5k IHJlcXVpcmVtZW50cyBmb3Igc2VjdXJlIA0gICBhdXRoZW50aWNhdGlvbiBpbiBvdGhlciBsYXll cnMgYWJvdmUgdGhlIG5ldHdvcmsgbGF5ZXIsIGUuZy4gYW4gDSAgIGFwcGxpY2F0aW9uIGxheWVy IGFuZCB0aGUgdXNlIG9mIG5ldHdvcmsgbGF5ZXIgc2VjdXJpdHkgYXBwcm9hY2hlcyANICAgZm9y IHRoaXMgcHVycG9zZS4gSXQgYWxzbyBpbnRyb2R1Y2VzIHRoZSByZXF1aXJlbWVudCBmb3IgcHJp dmFjeSANICAgY29uc2lkZXJhdGlvbi4gDQ0NDVN0YXR1cyBvZiB0aGlzIE1lbW8NDSAgIFRoaXMg SW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUg DSAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuIA0NICAgSW50ZXJuZXQtRHJhZnRz IGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcgDSAgIFRh c2sgRm9yY2UgKElFVEYpLiBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1 dGUgd29ya2luZyANICAgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gVGhlIGxpc3Qgb2Yg Y3VycmVudCBJbnRlcm5ldC1EcmFmdHMgaXMgDSAgIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kcmFmdHMvY3VycmVudC4gDQ0gICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3Vt ZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMgDSAgIGFuZCBtYXkgYmUgdXBk YXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55IA0g ICB0aW1lLiBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVm ZXJlbmNlIA0gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBp biBwcm9ncmVzcy4iIA0NICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBGZWJy dWFyeSAxOCwgMjAxNS4gDQ0gICANDQ0NQ29weXJpZ2h0IE5vdGljZQ0NICAgQ29weXJpZ2h0IChj KSAyMDE0IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlIA0gICBk b2N1bWVudCBhdXRob3JzLiBBbGwgcmlnaHRzIHJlc2VydmVkLiBUaGlzIGRvY3VtZW50IGlzIHN1 YmplY3QgdG8gDSAgIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbCBQcm92aXNpb25z IFJlbGF0aW5nIHRvIElFVEYgDSAgIERvY3VtZW50cyAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcv bGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIA0gICBkYXRlIG9mIHB1YmxpY2F0aW9uIG9m IHRoaXMgZG9jdW1lbnQuIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzIA0gICBjYXJlZnVs bHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJl c3BlY3QgDSAgIHRvIHRoaXMgZG9jdW1lbnQuIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJv bSB0aGlzIGRvY3VtZW50IG11c3QgDSAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0 ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZiANDQ1SYWZpZWUgICAgICAgIEV4cGly ZXMgRmVicnVhcnkgMTgsIDIwMTUgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NDUlO VEVSTkVUIERSQUZUICAgICAgICAgICAgICAgICAgICAgIHNlY2F1dGggdXNlY2FzZXMgICAgIEF1 Z3VzdCAxOCwgMjAxNA0NICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92 aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzIA0gICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQg QlNEIExpY2Vuc2UuIA0NDQ1UYWJsZSBvZiBDb250ZW50cw0NICAgMS4gIEludHJvZHVjdGlvbiAg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDSAgIDIu ICBUZXJtaW5vbG9neSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgNA0gICAzLiAgVXNlIGNhc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNICAgICAzLjEuICBBdXRoZW50aWNhdGlvbi9BdXRo b3JpemF0aW9uIG9mIGEgVXNlciB0byBhIERldmljZSAgIC4gLiAuICA0DSAgICAgICAzLjEuMS4g IEJpb21ldHJpYyBBdXRoZW50aWNhdGlvbiAgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg NA0gICAgICAgICAzLjEuMS4xLiAgQWR2YW50YWdlcyAgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDQNICAgICAgICAgMy4xLjEuMi4gIERpc2FkdmFudGFnZXMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DSAgICAgICAzLjEuMi4gIFBhc3N3b3Jk IEF1dGhlbnRpY2F0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0gICAgICAg ICAzLjEuMi4xLiAgQWR2YW50YWdlcyAgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDUNICAgICAgICAgMy4xLjIuMi4gIERpc2FkdmFudGFnZXMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DSAgICAgICAzLjEuMy4gIEV4dGVybmFsIEhhcmR3YXJl IEF1dGhlbnRpY2F0aW9uICAgLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0gICAgICAgICAzLjEuMy4x LiAgQWR2YW50YWdlcyAgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUN ICAgICAgICAgMy4xLjMuMi4gIERpc2FkdmFudGFnZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA2DSAgICAgICAzLjEuNC4gIFByb3h5IFNlcnZlciBTY2VuYXJpbyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNg0gICAgICAgMy4xLjUuICBOQVQgU2NlbmFy aW8gICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNICAgICAgIDMu MS42LiAgVmFsaWQgSVAgYWRkcmVzcyAgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA2DSAgICAgMy4yLiAgQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gb2YgdHdv IERldmljZXMgIC4gLiAuIC4gLiAgNg0gICAgICAgMy4yLjEuICBBIHByb3h5IHNlcnZlciAgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNICAgICAgIDMuMi4yLiAgTm8g SW50ZXJtZWRpYXRlIERldmljZSBTY2VuYXJpbyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2DSAg ICAgMy4zLiAgQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gb2YgVmlydHVhbCBEZXZp Y2VzICAgIC4gLiAgNg0gICAgICAgMy4zLjEuICBPcGVuZmxvdyB0byB2aXJ0dWFsIG5vZGUgYXV0 aGVudGljYXRpb24gICAgLiAuIC4gLiAuIC4gIDYNICAgICAgIDMuMy4yLiAgU0ROIGNvbnRyb2wg cGxhbmUgYXV0aGVudGljYXRpb24gICAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DSAgIDQuICBSZXF1 aXJlbWVudHMgICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNw0gICAgIDQuMS4gIEZ1bmN0aW9uYWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDcNICAgICA0LjIuICBJbXBsZW1lbnRhdGlvbiBhbmQgT3BlcmF0 aW9uYWwgVmlldyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DSAgIDUuICBTZWN1cml0eSBDb25z aWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0gICA2 LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDgNICAgNy4gIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4DSAgICAgNy4xLiAgTm9ybWF0aXZlICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0gICAgIDcuMi4gIElu Zm9ybWF0aXZlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDgNICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA5DQ0NDQ0NDQ0NDQ0NDQ0NDQ0NUmFmaWVlICAgICAgICBFeHBpcmVz IEZlYnJ1YXJ5IDE4LCAyMDE1ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQ1JTlRF Uk5FVCBEUkFGVCAgICAgICAgICAgICAgICAgICAgICBzZWNhdXRoIHVzZWNhc2VzICAgICBBdWd1 c3QgMTgsIDIwMTQNDQ0xLiAgSW50cm9kdWN0aW9uIA0NICAgVG9kYXksIHZhcmlvdXMgYXV0aGVu dGljYXRpb24sIGF1dGhvcml6YXRpb24gYW5kIGFjY291bnRpbmcgDSAgIGFwcHJvYWNoZXMgYXJl IGF2YWlsYWJsZSB0byBiZSB1c2VkIGZvciBkaWZmZXJlbnQgcHVycG9zZXMuIFNvbWUgDSAgIGV4 YW1wbGVzIG9mIHRoZXNlIGFwcHJvYWNoZXMgYXJlIFJlbW90ZSBBdXRoZW50aWNhdGlvbiBEaWFs LUluIFVzZXIgDSAgIFNlcnZpY2UgKFJBRElVUykgW1JGQzY5MjldLCBIb3N0IElkZW50aXR5IFBy b3RvY29sIChISVApIFtSRkM0NDIzXSwgDSAgIE9wZW4gU3RhbmRhcmQgZm9yIEF1dGhvcml6YXRp b24gKE9BdXRoKSBbUkZDNjc0OV0gYW5kIERpYW1ldGVyIA0gICBbUkZDNjczM10uIA0NICAgVXN1 YWxseSwgSW50ZXJuZXQgUHJvdG9jb2wgc2VjdXJpdHkgKElQc2VjKSBbUkZDIDQzMDFdLCBUcmFu c3BvcnQgDSAgIExheWVyIFNlY3VyaXR5IChUTFMpIFtSRkM1MjQ2XSBvciBTZWN1cmUgU29ja2V0 IExheWVyIChTU0wpIFtSRkM2MTAxXSANICAgaXMgdXNlZCB0byBzZWN1cmUgdGhlc2UgY29tbXVu aWNhdGlvbnMgYW5kIHByb3ZpZGUgZGF0YSANICAgY29uZmlkZW50aWFsaXR5IGZvciB1c2Vycy4g V2hlbiBJUHNlYyBpcyBpbiB1c2UsIHRoZSBrZXkgbWFuYWdlbWVudCANICAgbWlnaHQgYmUgYSBw cm9ibGVtLiBXaGVuIFNTTCBvciBUTFMgaXMgaW4gdXNlIGVpdGhlciB0aGVyZSBzaG91bGQgYmUg DSAgIGEgaGFyZGNvcHkgb2YgY2VydGlmaWNhdGVzIGF2YWlsYWJsZSBvbiBhIG5vZGUgb3IgdGhl cmUgc2hvdWxkIGJlIGEgDSAgIENlcnRpZmljYXRlIEF1dGhvcml0eSAoQ0EpIHRvIHNpZ24gdGhp cyBjZXJ0aWZpY2F0aW9uIHRvIGJlIGVhc2lseSANICAgdmVyaWZpZWQgb24gbm9kZXMgd2hpY2gg c3VwcG9zZSB0byB1c2UgdGhpcyBzZXJ2aWNlLiBUaGUgcHJvYmxlbSB3aXRoIA0gICB0aGUgZm9y bWVyIGFwcHJvYWNoIG1pZ2h0IGJlIHByaXZhY3kgd2hlbiBhIG5vZGUgbmVlZHMgdG8gYWxzbyAN ICAgcHJvY2VzcyBrZXkgZXhjaGFuZ2UuIFdoZW4gdGhpcyBpcyBub3QgcmVxdWlyZWQsIHRoZSBu dW1iZXIgb2Yga2V5cyANICAgdGhhdCBpcyBuZWVkZWQgdG8gYmUgc3RvcmVkIGluIG5vZGU/cyBt ZW1vcnkgKHRoZSBhc3N1bXB0aW9uIGlzIHRoYXQgDSAgIGEgbm9kZSBtaWdodCBuZWVkIHRvIGNv bW11bmljYXRlIHdpdGggZGlmZmVyZW50IHNlcnZpY2UgcHJvdmlkZXIgYW5kIA0gICBiZSBhdXRo ZW50aWNhdGVkIGFnYWluc3QgdGhlbS4pIG1pZ2h0IGJlIGEgcHJvYmxlbSwgZXNwZWNpYWxseSBv biANICAgbm9kZXMgd2l0aCBsaW1pdGVkIHJlc291cmNlcy4gQW5vdGhlciBwcm9ibGVtIHdpdGgg aGFyZGNvcHkgb2YgdGhpcyANICAga2V5IHdvdWxkIGJlIG5vZGUgc3RvbGVuLiBJbiBvdGhlciB3 b3Jkcywgd2hlbiBhbiBhdHRhY2tlciBzdGVhbHMgYSANICAgZGV2aWNlIHdpdGggdGhlIGhhcmRj b3B5IG9mIGEga2V5IGF2YWlsYWJsZSB0aGVyZSwgaGUgbWlnaHQgYmUgYWJsZSANICAgdG8gdXNl IHRoZSBvd25lcj9zIGNyZWRlbnRpYWwgdG8gaGF2ZSB1bmF1dGhvcml6ZWQgYWNjZXNzIHRvIHRo ZSANICAgdXNlcj9zIHJlc291cmNlcyBhbmQgaGFybSBwcml2YWN5IGFuZCBzZWN1cml0eSBvZiB0 aGlzIHVzZXIgb3IgYSANICAgdGFyZ2V0IG5ldHdvcmsuIFRoaXMgaXMgZXNwZWNpYWxseSBhIHJl YWwgcHJvYmxlbSByZWNlbnRseSBiZWNhdXNlIA0gICBtYW55IHZlbmRvcnMgdXNlIHRoaXMgYXBw cm9hY2guIA0NICAgVGhlIHByb2JsZW0gd2l0aCBsYXR0ZXIgYXBwcm9hY2ggbWlnaHQgYmUgY29z dCBvZiBoYXZpbmcgDSAgIGNlcnRpZmljYXRpb24gc2lnbmVkIGJ5IENBcy4gVGhpcyBpcyBlc3Bl Y2lhbGx5IHVucHJhY3RpY2FsIGlmIGV2ZXJ5IA0gICBzaW5nbGUgbm9kZSB3aGljaCBzdXBwb3Nl ZCB0byBiZSBhdXRoZW50aWNhdGVkIGFnYWluc3QgYW5vdGhlciBub2RlIA0gICBuZWVkcyB0byBo YXZlIGEgY2VydGlmaWNhdGlvbi4gVGhlIG90aGVyIHByb2JsZW0gd291bGQgYmUgdGhlIA0gICBs aWtlbGlob29kIG9mIGdvdmVybm1lbnQ/cyBzdXJ2ZWlsbGFuY2UuIA0NICAgVGhpcyBkb2N1bWVu dCBhZGRyZXNzZXMgdGhlIGZvbGxvd2luZyBwcm9ibGVtczogDQ0gICAtIHNlbGYgY2VydGlmaWNh dGlvbiBhbmQgYXZvaWRpbmcgaWRlbnRpdHkgc3Bvb2Zpbmcgb2YgYSBub2RlICggZm9yIA0gICBl eGFtcGxlLCBhIHNlbGYgY2VydGlmaWVkIG1haWwgc2VydmVyKSANDSAgIC0gU2VjdXJlIGF1dGhl bnRpY2F0aW9uIA0NICAgLSBQcml2YWN5IGFuZCBkYXRhIGNvbmZpZGVudGlhbGl0eSANDSAgIC0g YXV0aGVudGljYXRpb24gb2YgZGV2aWNlcyBpbiBjYXNlIG9mIHByb3h5IHNlcnZlcnMgDQ0gICAt IGV0Yy4gDQ0gICBUaGVyZWZvcmUsIHRoZSBwdXJwb3NlIG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8g ZGVmaW5lIHRoZSBwcm9ibGVtIA0gICBzdGF0ZW1lbnQgYW5kIGlkZW50aWZpZXMgdGhlIHJlcXVp cmVtZW50cyBmb3IgYSByb2J1c3QgZWFzeSBzZWN1cmUgDSAgIGF1dGhlbnRpY2F0aW9uIGFuZCBh dXRob3JpemF0aW9uIG9mIG5vZGVzIHVzaW5nIGEgY29tYmluYXRpb24gb2YgDQ0NUmFmaWVlICAg ICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE4LCAyMDE1ICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDNdDQ1JTlRFUk5FVCBEUkFGVCAgICAgICAgICAgICAgICAgICAgICBzZWNhdXRoIHVzZWNh c2VzICAgICBBdWd1c3QgMTgsIDIwMTQNDSAgIG5ldHdvcmsgbGF5ZXIgYW5kIGFwcGxpY2F0aW9u IGxheWVyIHNlY3VyaXR5IGFwcHJvYWNoZXMuIA0NDTIuICBUZXJtaW5vbG9neSANDSAgIERldmlj ZTogYW55IGRpZ2l0YWwgaGFyZHdhcmUgdGhhdCBoYXMgY29tbXVuaWNhdGlvbiBhYmlsaXR5LiBB IGRldmljZSANICAgaXMgbW9yZSBnZW5lcmFsIHRoYW4gYSBub2RlLiANDSAgIE5vZGU6IHJvdXRl cnMgYW5kIGhvc3RzIGluIGEgbmV0d29yayANDSAgIEludGVybWVkaWF0ZSBEZXZpY2U6IGEgcHJv eHkgc2VydmVyIG9yIGEgTkFUIGRldmljZSBvciBhbnkgb3RoZXIgbm9kZSANICAgdGhhdCBpbnRl cmNlcHQgdGhlIGNvbW11bmljYXRpb24gaW4gbm8gbWFsaWNpb3VzIHdheSBhbmQgYnkgcHVycG9z ZSANDSAgIEF1dGhlbnRpY2F0aW9uOiBBbiBhY3Qgb2YgdmVyaWZ5aW5nIGEgdXNlciANDSAgIEF1 dGhvcml6YXRpb246IGFjdCBvZiBkZXRlcm1pbmluZyB3aGV0aGVyIHJlcXVlc3RpbmcgZW50aXR5 IGlzIA0gICBhbGxvd2VkIGFjY2VzcyB0byBhIHJlc291cmNlIA0NICAgQWNjb3VudGluZzogYWN0 IG9mIGNvbGxlY3RpbmcgaW5mbyBvbiByZXNvdXJjZSB1c2FnZSBhbmQgbG9nZ2luZyB1c2VyIA0g ICBhY3Rpdml0aWVzIGFmdGVyIGF1dGhvcml6YXRpb24gc3RlcC4gDQ0gICBUQkQgDQ0NMy4gIFVz ZSBjYXNlcyANDSAgIFRoZSBmb2xsb3dpbmcgc3Vic2VjdGlvbnMgZXhwbGFpbnMgZGlmZmVyZW50 IHVzZSBjYXNlIHNjZW5hcmlvcyANDQ0zLjEuICBBdXRoZW50aWNhdGlvbi9BdXRob3JpemF0aW9u IG9mIGEgVXNlciB0byBhIERldmljZSANDSAgIFVzdWFsbHkgZm9yIGF1dGhlbnRpY2F0aW9uIG9m IGEgdXNlciwgYmlvbWV0cmljIHNhbXBsZXMgb3IgYSB1c2VybmFtZSANICAgaXMgaW4gdXNlLiBV c2luZyBlYWNoIG9mIHRoZXNlIGFwcHJvYWNoZXMgaGFzIHNvbWUgYWR2YW50YWdlcyBhbmQgDSAg IGRpc2FkdmFudGFnZXMuIA0NDTMuMS4xLiAgQmlvbWV0cmljIEF1dGhlbnRpY2F0aW9uIA0NDTMu MS4xLjEuICBBZHZhbnRhZ2VzIA0NICAgLSBpdCBpcyBhbHdheXMgd2l0aCB0aGUgdXNlciwgZGlz c2ltaWxhciB0byBwYXNzd29yZHMgdGhleSBjYW5ub3QgYmUgDSAgIGZvcmdvdHRlbiANDSAgIC0g SXQgbWlnaHQgaWRlbnRpZnkgYSBwZXJzb24gc28gdGhhdCBtYW55IHNlcnZpY2VzIGNhbiBiZSBv ZmZlcmVkIHRvIA0gICB0aGlzIHVzZXIgcmVtb3RlbHkuIA0NDTMuMS4xLjIuICBEaXNhZHZhbnRh Z2VzIA0NICAgLSBUaGV5IGNhbiBiZSBzdG9sZW4gDQ0gICBBbiBhdHRhY2tlciBjYW4gc3RvbGUg dGhlIGZpbmdlciBwcmludCBvZiBhIHVzZXIgd2hlbiBoZSB0b3VjaGVzLCBmb3IgDQ0NUmFmaWVl ICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE4LCAyMDE1ICAgICAgICAgICAgICAgICAgICAgICAg IFtQYWdlIDRdDQ1JTlRFUk5FVCBEUkFGVCAgICAgICAgICAgICAgICAgICAgICBzZWNhdXRoIHVz ZWNhc2VzICAgICBBdWd1c3QgMTgsIDIwMTQNDSAgIGV4YW1wbGUsIGEgZ2xhc3MuIA0NICAgLSBU aGV5IHdpbGwgbmV2ZXIgY2hhbmdlIA0NICAgV2hlbiB0aGV5IGFyZSBzdG9sZW4sIGRpc3NpbWls YXIgdG8gcGFzc3dvcmRzLCBpdCBpcyBub3QgcG9zc2libGUgdG8gDSAgIGNoYW5nZSB0aGVtIHNp bmNlIHRoZXkgYXJlIGEgc2NhbiBzYW1wbGUgcGFydCBvZiBhIHVzZXIncyBib2R5IA0NICAgLSBU aGV5IG1pZ2h0IGNhdXNlIHRocmVhdCBmb3IgdGhlIHVzZXIgDQ0gICBXaGVuIGEgY3JpbWluYWwg a25vdyB0aGF0IGV2ZXJ5IHBhc3N3b3JkIGlzIHRoZSBiaW9tZXRyaWMgaW5mb3JtYXRpb24gDSAg IG9mIGEgdXNlciwgaGUgY2FuIGtpZG5hcCB0aGlzIHBlcnNvbiBhbmQgYWNjZXNzIHRvIGFsbCBp bmZvcm1hdGlvbiANICAgdGhhdCB1c2VzIHRoaXMga2luZCBvZiBiaW9tZXRyaWMgc2FtcGxlcy4g DQ0gICBJdCBjYW4gYWxzbyBlbmNvdXJhZ2UgY3JpbWluYWxzIHRvIGtpbGwgYSBwZXJzb24gdG8g YWNjZXNzIHRvIA0gICBiaW9tZXRyaWMgc2FtcGxlcyEgDQ0NMy4xLjIuICBQYXNzd29yZCBBdXRo ZW50aWNhdGlvbiANDQ0zLjEuMi4xLiAgQWR2YW50YWdlcyANDSAgIC0gQSB1c2VyIGNhbiBjaGFu Z2UgaXQgd2hlbiBpdCBpcyBzdG9sZW4gDQ0gICAtIEEgdXNlciBjYW4gdXNlIGRpZmZlcmVudCB1 c2VybmFtZSBhbmQgcGFzc3dvcmRzIGluIGRpZmZlcmVudCANICAgc3lzdGVtcyANDSAgIC0gSXQg bWlnaHQgbm90IGlkZW50aWZ5IGEgcGVyc29uIA0NDTMuMS4yLjIuICBEaXNhZHZhbnRhZ2VzIA0N ICAgLSBJdCBpcyBub3QgZWFzeSB0byBtZW1vcml6ZSBvbmUgdG8gbWFueSBwYXNzd29yZHMgZm9y IGRpZmZlcmVudCANICAgc3lzdGVtcyAoZmluZGluZyBhIHN0cm9uZyBwYXNzd29yZCB0aGF0IGNh biBiZSBtZW1vcml6ZWQgZWFzaWx5LikgDQ0gICAtIEl0IGNhbiBiZSBoYWNrZWQgDQ0gICAtIFdo ZW4gYSB1c2VyIHVzZXMgb25lIHBhc3N3b3JkIGZvciBhbGwgc3lzdGVtcywgdGhlbiBoZSBpcyBw cm9uZSB0byANICAgZGF0YSBsb3NzIG9yIHByaXZhY3kgYXR0YWNrLiANDQ0zLjEuMy4gIEV4dGVy bmFsIEhhcmR3YXJlIEF1dGhlbnRpY2F0aW9uIA0NICAgSW4gcmVjZW50IHllYXJzLCBpdCBpcyBj b21tb24gdG8gdXNlIHRoZSBleHRlcm5hbCBkZXZpY2VzIHN1Y2ggYXMgDSAgIGNoaXAgY2FyZHMs IFVTQnMsIGV0Yy4gdGhhdCBzdG9yZXMgc29tZSBzZWNyZXQga2V5cyB0byBhdXRob3JpemUgYSAN ICAgdXNlciB0byBhY2Nlc3Mgc29tZSBzeXN0ZW1zIG9yIGluZm9ybWF0aW9uIG92ZXIgdGhlIGlu dGVybmV0IG9yIG92ZXIgDSAgIHRoZSBuZXR3b3JrLiANDQ0zLjEuMy4xLiAgQWR2YW50YWdlcyAN DSAgIC0gVGhlIHVzZXIgZG9lcyBub3QgbmVlZCB0byBtZW1vcml6ZSBhbnkgcGFzc3dvcmQgDQ0N DVJhZmllZSAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxOCwgMjAxNSAgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSA1XQ0NSU5URVJORVQgRFJBRlQgICAgICAgICAgICAgICAgICAgICAgc2Vj YXV0aCB1c2VjYXNlcyAgICAgQXVndXN0IDE4LCAyMDE0DQ0NMy4xLjMuMi4gIERpc2FkdmFudGFn ZXMgDQ0gICAtIEl0IGNhbiBiZSBzdG9sZW4gDQ0gICAtIEl0IGNhbiBiZSBkYW1hZ2VkIA0NICAg VGhlcmUgYXJlIHR3byBkaWZmZXJlbnQgdXNlIGNhc2VzIHVuZGVyIHRoaXMgY2F0ZWdvcnkgdGhh dCBhcmUgDSAgIGV4cGxhaW5lZCBpbiB0aGUgZm9sbG93aW5nIHNlY3Rpb25zIA0NDTMuMS40LiAg UHJveHkgU2VydmVyIFNjZW5hcmlvIA0NICAgQWxpY2UgaXMgYmVoaW5kIGEgcHJveHkgc2VydmVy IGFuZCBhbnkgcmVxdWVzdCB0byB0aGUgZGV2aWNlIGlzIGZpcnN0IA0gICByZWNlaXZlZCBieSB0 aGUgcHJveHkgDQ0NMy4xLjUuICBOQVQgU2NlbmFyaW8gDQ0gICBBbGljZSBkb2VzIG5vdCBoYXZl IGFueSB2YWxpZCBJUCBhZGRyZXNzIGFuZCBuZWVkcyB0byBiZSANICAgYXV0aGVudGljYXRlZCBv biBhbiBhcHBsaWNhdGlvbiBzZXJ2ZXIgDQ0NMy4xLjYuICBWYWxpZCBJUCBhZGRyZXNzIA0NICAg QWxpY2UgaGFzIGEgdmFsaWQgSVAgYWRkcmVzcyBhbmQgbmVlZHMgdG8gYmUgYXV0aGVudGljYXRl ZCBvbiBhbiANICAgYXBwbGljYXRpb24gc2VydmVyLiANDQ0zLjIuICBBdXRoZW50aWNhdGlvbiBh bmQgQXV0aG9yaXphdGlvbiBvZiB0d28gRGV2aWNlcyANDQ0zLjIuMS4gIEEgcHJveHkgc2VydmVy ICANDSAgIEZvciBleGFtcGxlLCBub2RlIEEgZXN0YWJsaXNoZXMgU2Vzc2lvbiBJbml0aWF0aW9u IFByb3RvY29sIChTSVApIHRvIA0gICBub2RlIEIuIFRoZXJlIGlzIFNJUCBwcm94eSBpbiBiZXR3 ZWVuLiBTSVAgcHJveHkgcmVjZWl2ZXMgbWVzc2FnZXMgDSAgIGZyb20gbm9kZSBBLiBTSVAgcHJv eHkgbmVlZHMgdG8gYXV0aGVudGljYXRlIG5vZGUgQS4gQWZ0ZXIgdGhpcyBzdGVwIA0gICBTSVAg cHJveHkgZm9yd2FyZHMgYWxsIHBhY2tldHMgZnJvbSBub2RlIEIuIE5vZGUgQiBhdXRoZW50aWNh dGVzIFNJUCANICAgcHJveHkgYW5kIGFjY2VwdHMgYWxsIHBhY2tldHMgaW50ZXJjZXB0cyBieSBT SVAgcHJveHkuIA0NDTMuMi4yLiAgTm8gSW50ZXJtZWRpYXRlIERldmljZSBTY2VuYXJpbyANDQ0z LjMuICBBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBvZiBWaXJ0dWFsIERldmljZXMg IA0NICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgYXV0aGVudGljYXRpb24gb2YgZGlmZmVy ZW50IHZpcnR1YWwgDSAgIHByb3RvY29sIGluIFNETiB0ZWNobmlxdWVzIHRvIGNvbnRyb2wgcGxh bmUuIA0NDTMuMy4xLiAgT3BlbmZsb3cgdG8gdmlydHVhbCBub2RlIGF1dGhlbnRpY2F0aW9uICAN DSAgIEEgdW5pcXVlIGlkZW50aWZpZXIgaXMgdXNlZCB0byBhdXRoZW50aWNhdGUgYW4gb3BlbmZs b3cgb24gYSB2aXJ0dWFsIA0NDVJhZmllZSAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxOCwgMjAx NSAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0NSU5URVJORVQgRFJBRlQgICAgICAg ICAgICAgICAgICAgICAgc2VjYXV0aCB1c2VjYXNlcyAgICAgQXVndXN0IDE4LCAyMDE0DQ0gICBu b2RlLiBUaGlzIHZpcnR1YWwgbm9kZSAobGlrZSBhIHN3aXRjaCBvciBhIHJvdXRlcikgYWxsb3dz IHRoaXMgDSAgIG9wZW5mbG93IHRvIGJlIGV4ZWN1dGVkIHdoZW4gaXQgY2FuIGZpbmQgdGhpcyB1 bmlxdWUgaWRlbnRpZmllciBpbiANICAgaXRzIGFjY2VzcyBsaXN0LiANDQ0zLjMuMi4gIFNETiBj b250cm9sIHBsYW5lIGF1dGhlbnRpY2F0aW9uICANDSAgIEJlZm9yZSBhbnkgcnVsZSBjYW4gYmUg cHJvcGFnYXRlZCBvdmVyIGFsbCBkaXN0cmlidXRlZCBjb250cm9sIHBsYW5lIA0gICB2aWEgdGhl IGNlbnRyYWxpemVkIGNvbnRyb2wgcGxhbmUsIHRoZSBzZW5kZXIgb2YgdGhpcyBuZXcgcnVsZSAo b25lIA0gICBvZiB0aGUgU0ROIGNvbnRyb2wgcGxhbmUpIHNob3VsZCBiZSBhdXRoZW50aWNhdGVk IG9uIHRoZSBjZW50cmFsaXplZCANICAgY29udHJvbCBwbGFuZSAoY29udHJvbGxlcikgdG8gYXZv aWQgcHJvcGFnYXRpb24gb2YgYSBtYWxpY2lvdXMgcnVsZSANICAgb24gYWxsIFNETiBkZXZpY2Vz LiANDQ00LiAgUmVxdWlyZW1lbnRzIA0NICAgVGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIHNjb3Bl IG9mIHRoaXMgZG9jdW1lbnQgYW5kIGludHJvZHVjZXMgdGhlIA0gICByZXF1aXJlbWVudCBvZiBh biBBUEkgZm9yIHRoaXMgcHJvdG9jb2wuIA0NDTQuMS4gIEZ1bmN0aW9uYWxpdHkgDQ0gICAtCU9w ZXJhdGVzIGluIGJvdGggSVB2NCBhbmQgSVB2NiBuZXR3b3JrcyANDSAgIC0JUmVxdWlyZXMgbWlu aW11bSBodW1hbiBpbnRlcmFjdGlvbiAoYXV0b21hdGVzIHRoZSBwcm9jZXNzIGFzIG11Y2ggDSAg IGFzIHBvc3NpYmxlKSANDSAgIC0JU3VwcG9ydHMgZGlmZmVyZW50IGNsaWVudHMgd2l0aCBkaWZm ZXJlbnQgcmVzb3VyY2VzIChNZW1vcnksIA0gICBCYXR0ZXJ5LCBDUFUsIGV0Yy4pID8gTGFwdG9w cywgSVBvZCwgU21hcnRwaG9uZSwgc2Vuc29yIG5vZGVzLCBjYXJzLCANICAgZXRjLiANDSAgIEdv b2QgcGVyZm9ybWFuY2UgZm9yIGNvbnN0cmFpbmVkIGRldmljZXMuIA0NICAgLQlQcm92aWRlcyBz ZWN1cml0eSBhbmQgYSB1c2VyIGRlZmluZWQgcHJpdmFjeSAoZmxleGlibGUgdG8gcG9saWN5KSAN DSAgIC0JQmUgYWJsZSB0byBhdXRoZW50aWNhdGUgYW5kIGF1dGhvcml6ZSBub2RlcyBpbiBjYXNl IHRoZXJlIGFyZSBwcm94eSANICAgc2VydmVycyBvciBvdGhlciBpbnRlcm1lZGlhdGUgbm9kZXMg aW4gdGhlIG1pZGRsZSBvZiB0aGUgDSAgIGNvbW11bmljYXRpb25zIA0NICAgLQlFbmFibGUgdGhl IHVzZSBvZiB0aGlzIGFwcHJvYWNoIGluIHZpc3VhbGl6YXRpb24gZW52aXJvbm1lbnQgYW5kIA0g ICBmb3IgdGhlIGF1dGhlbnRpY2F0aW9uIG9mIGRpZmZlcmVudCB2aXJ0dWFsIG5vZGVzIGluIGNs b3VkcyB3aGVyZSANICAgU29mdHdhcmUgRGVmaW5lZCBOZXR3b3JrIChTRE4pIG9yIE5ldHdvcmsg RnVuY3Rpb24gVmlydHVhbGl6YXRpb24gDSAgIChORlYpIHRlY2huaXF1ZXMgYXJlIGluIHVzZS4g DQ0NNC4yLiAgSW1wbGVtZW50YXRpb24gYW5kIE9wZXJhdGlvbmFsIFZpZXcgDQ0gICAtCVBsYXRm b3JtIGluZGVwZW5kZW50LiBJbiBvdGhlciB3b3Jkcywgc3VwcG9ydHMgbXVsdGlwbGUgcGxhdGZv cm1zIA0gICAoV2luZG93cywgTGludXgsIFVOSVgsIGV0Yy4pIA0NICAgLQlFYXNpbHkgaW50ZWdy YXRlIHdpdGggYW55IG90aGVyIGFwcGxpY2F0aW9uIGxheWVyIGF1dGhlbnRpY2F0aW9uIA0gICBt ZWNoYW5pc21zIA0NDQ1SYWZpZWUgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTgsIDIwMTUgICAg ICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgN10NDUlOVEVSTkVUIERSQUZUICAgICAgICAgICAg ICAgICAgICAgIHNlY2F1dGggdXNlY2FzZXMgICAgIEF1Z3VzdCAxOCwgMjAxNA0NICAgLSBQcm92 aWRlIGFuIGVhc3kgZnJhbWV3b3JrIGZvciBkaXN0cmlidXRpbmcgdW5pcXVlIGlkZW50aXR5IGJ1 dCBhdCANICAgdGhlIHNhbWUgdGltZSBhd2FyZSBvZiBwcml2YWN5LiANDSAgIC0JUHJvdmlkZSBz dXBwb3J0cyBmb3IgU29mdHdhcmUgRGVmaW5lZCBOZXR3b3JrcyAoU0ROKSANDTUuICBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucw0NICAgVGhlcmUgaXMgbm8gc2VjdXJpdHkgY29uc2lkZXJhdGlvbiAN DQ0NNi4gIElBTkEgQ29uc2lkZXJhdGlvbnMNDSAgIFRoZXJlIGlzIG5vIElBTkEgY29uc2lkZXJh dGlvbiANDQ0NDQ03LiAgUmVmZXJlbmNlcw0NNy4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgDQ0g ICBbUkZDNDMwMV0gS2VudCwgUy4sIFNlbywgSy4sICJTZWN1cml0eSBBcmNoaXRlY3R1cmUgZm9y IHRoZSANICAgICAgICAgICAgIEludGVybmV0IFByb3RvY29sIiwgUkZDIDQzMDEsIERlY2VtYmVy IDIwMDUuIA0NICAgW1JGQzQ0MjNdIE1vc2tvd2l0eiwgUi4sIE5pa2FuZGVyLCBQLiwgIkhvc3Qg SWRlbnRpdHkgDSAgICAgICAgICAgICBQcm90b2NvbCAoSElQKSBBcmNoaXRlY3R1cmUiLCBSRkMg NDQyMywgTWF5IDIwMDYuIA0NICAgW1JGQzQ4NDNdIE5pa2FuZGVyLCBQLiwgTGFnYW5pZXIsIEou LCBEdXBvbnQsIEYuICwgIkFuIElQdjYgDSAgICAgICAgICAgICBQcmVmaXggZm9yIE92ZXJsYXkg Um91dGFibGUgQ3J5cHRvZ3JhcGhpYyBIYXNoIElkZW50aWZpZXJzIA0gICAgICAgICAgICAgKE9S Q0hJRCkiLCBSRkMgNDg0MywgQXByaWwgMjAwNy4gDQ0gICBbUkZDNjEwMV0gRnJlaWVyLCBBLiwg S2FybHRvbiwgUC4sIEtvY2hlciwgUC4gLCAiVGhlIFNlY3VyZSANICAgICAgICAgICAgIFNvY2tl dHMgTGF5ZXIgKFNTTCkgUHJvdG9jb2wgVmVyc2lvbiAzLjAiLCBSRkMgNjEwMSwgQXVndXN0IA0g ICAgICAgICAgICAgMjAxMS4gDQ0gICBbUkZDNjczM10gRmFqYXJkbywgVi4sIEFya2tvLCBKLiwg TG91Z2huZXksIEouLCBab3JuLCBHLiwgDSAgICAgICAgICAgICAiRGlhbWV0ZXIgQmFzZSBQcm90 b2NvbCIgUkZDIDY3MzMsIE9jdG9iZXIgMjAxMi4gDQ0gICBbUkZDNjc0OV0gSGFyZHQsIEQuLCAi VGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIA0gICAgICAgICAgICAgRnJhbWV3b3JrIiwgUkZD IDY3NDksIE9jdG9iZXIgMjAxMi4gDQ0gICBbUkZDNjkyOV0gRGVLb2ssIEEuLCBMaW9yLCBBLiwg IlJlbW90ZSBBdXRoZW50aWNhdGlvbiANICAgICAgICAgICAgIERpYWwtSW4gVXNlciBTZXJ2aWNl IChSQURJVVMpIFByb3RvY29sIEV4dGVuc2lvbnMiLFJGQyANICAgICAgICAgICAgIDY5MjksIEFw cmlsIDIwMTMgDQ03LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIA0NICAgDQ0NDQ0NUmFmaWVl ICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE4LCAyMDE1ICAgICAgICAgICAgICAgICAgICAgICAg IFtQYWdlIDhdDQ1JTlRFUk5FVCBEUkFGVCAgICAgICAgICAgICAgICAgICAgICBzZWNhdXRoIHVz ZWNhc2VzICAgICBBdWd1c3QgMTgsIDIwMTQNDUF1dGhvcnMnIEFkZHJlc3Nlcw0NICAgICAgSG9z bmllaCBSYWZpZWUNICAgICAgSFVBV0VJIFRFQ0hOT0xPR0lFUyBEdWVzc2VsZG9yZiBHbWJIDSAg ICAgIFJpZXNzdHJhc3NlIDI1LCA4MDk5Mg0gICAgICBNdW5pY2gsIEdlcm1hbnkNICAgICAgUGhv bmU6ICs0OSAoMCkxNjIgMjA0IDc0IDU4DSAgICAgIEUtbWFpbDogaG9zbmllaC5yYWZpZWVAaHVh d2VpLmNvbQ0DDQ0EDQ0DDQ0EDQ0NDQ0HU2VjYXV0aCBSZXF1aXJlbWVudHMgYW5kIFVzZWNhc2Vz BwcHDQ0NDRMgREFURSBcQCAieXl5eS1NTS1kZCIgFDIwMTQtMDgtMTgVBwdQYWdlE1BBR0UUMRUs IFRvdGFsEyBOVU1QQUdFUyAgXCogQXJhYmljICBcKiBNRVJHRUZPUk1BVCAUMTIVBwcNDQ0NDQ0N DQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAMIAACVCAAAqEAAAPJAAAAPRQAAEEUAABJFAAATRQAA FUUAABZFAAAYRQAAGUUAABtFAAAcRQAAHUUAAB5FAAAfRQAAQEUAAEJFAABERQAARUUAAEZFAABH RQAASEUAAF5FAABfRQAAaUUAAGpFAABsRQAAcEUAAHFFAAB1RQAAdkUAAHdFAAB4RQAAf0UAAIBF AAClRQAApkUAAKhFAACpRQAAqkUAAKxFAACtRQAArkUAAK9FAACwRQAAskUAALNFAADv2u/a79LO 0s7SztLOys7DyrzDys7KzrGqsZ6xw5exkLGesZexkLGescPKzsrOys7vAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBVorzOAABZoZCrSAAAMFWivM4AAFmiAGw4AABcVaK8z gAAWaK8zgABtSAAEbkgABHUIAQwVaK8zgAAWaC8YlQAAFQNqAAAAABVorzOAABZoZCrSAFUIAQwV aK8zgAAWaLRbXAAADBVorzOAABZoTALkAAAGFmhMAuQAAAYWaPAiQAAADwNqAAAAABZo8CJAAFUI ASgVaNtYDgAWaNtYDgBDShQAT0oDAFFKAwBeSgMAYUoUAG1IBwRzSAcEACAVaNtYDgAWaNtYDgBD ShQAT0oDAFFKAwBeSgMAYUoUADEACAAAAQgAAAIIAAADCAAATAgAAJUIAADeCAAAJwkAACgJAAAp CQAAXwkAAJcJAACYCQAAoQkAAKIJAADnCQAAKwoAAHIKAAC3CgAA0QAAAAAAAAAAAAAAAKMAAAAA AAAAAAAAAACjAAAAAAAAAAAAAAAAowAAAAAAAAAAAAAAAKMAAAAAAAAAAAAAAACjAAAAAAAAAAAA AAAAowAAAAAAAAAAAAAAAKMAAAAAAAAAAAAAAACjAAAAAAAAAAAAAAAAowAAAAAAAAAAAAAAAKMA AAAAAAAAAAAAAACjAAAAAAAAAAAAAAAAowAAAAAAAAAAAAAAAKMAAAAAAAAAAAAAAACjAAAAAAAA AAAAAAAAowAAAAAAAAAAAAAAAKMAAAAAAAAAAAAAAACjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAC4AAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAA AAAAD4QAABJk8AABADEkATckATgkAUgkAVZEAABehAAAZ2TbWA4ALgAADcYyABCUAygHvApQDuQR eBUMGaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAAPhKQBEmTwAAEAMSQBNyQBOCQB SCQBVkQAAF6EpAFnZNtYDgAAErcKAADKCgAAywoAAMwKAADNCgAA4QoAAOIKAAAkCwAASQsAAEoL AACQCwAA2gsAACMMAABWDAAAVwwAAKEMAADqDAAALA0AAGsNAABsDQAApg0AAKcNAACrDQAArA0A AK0NAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA 0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAA AAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAA AAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEA AAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAA AAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAAAAAAAAAAAuAAANxjIAEJQDKAe8ClAO5BF4 FQwZoBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAAA+EAAASZPAAAQAxJAE3JAE4JAFI JAFWRAAAXoQAAGdk21gOAAAYrQ0AAK4NAAC/DQAAwA0AAAQOAABLDgAAjQ4AANMOAAAbDwAAZQ8A AK0PAAD0DwAA9Q8AAPYPAAA/EAAAQBAAAIkQAACKEAAAzhAAAPsQAAD8EAAA/RAAAP4QAAAQEQAA EREAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADR AAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAA AAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAA AADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAA AAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAA AAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAAAAAAAAAAC4AAA3GMgAQlAMoB7wKUA7kEXgV DBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAD4QAABJk8AABADEkATckATgkAUgk AVZEAABehAAAZ2TbWA4AABgREQAAWhEAAKMRAADsEQAANRIAAH4SAADHEgAAEBMAAFkTAACiEwAA 6xMAADQUAAB9FAAAxhQAAA8VAABYFQAAoRUAAOoVAAAzFgAAfBYAAMUWAAAOFwAAVxcAAKAXAADp FwAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEA AAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAA AAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAA ANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAA AAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAA AAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAAAAAAAAAALgAADcYyABCUAygHvApQDuQReBUM GaAcNCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAAPhAAAEmTwAAEAMSQBNyQBOCQBSCQB VkQAAF6EAABnZNtYDgAAGOkXAAAyGAAAexgAAMQYAAANGQAAVhkAAJ8ZAADoGQAA6RkAAOoZAADr GQAA7BkAAO0ZAADuGQAA7xkAAPAZAADxGQAA8hkAAPMZAAD0GQAA9RkAAPYZAAD3GQAA+BkAAPkZ AADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAA AAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAA AAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA 0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAA AAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAA AAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAAAAAAAAAAAuAAANxjIAEJQDKAe8ClAO5BF4FQwZ oBw0IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAAA+EAAASZPAAAQAxJAE3JAE4JAFIJAFW RAAAXoQAAGdk21gOAAAY+RkAAEIaAABDGgAAjBoAAI0aAACOGgAAoBoAAKEaAADhGgAAJhsAAG4b AAC2GwAA+RsAAAgcAAAJHAAATxwAAJkcAADVHAAAHR0AAGYdAACuHQAA9R0AAD8eAACCHgAAyh4A ANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAA AAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAA AAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADR AAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAA AAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAA AADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAAAAAAAAAAC4AAA3GMgAQlAMoB7wKUA7kEXgVDBmg HDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAD4QAABJk8AABADEkATckATgkAUgkAVZE AABehAAAZ2TbWA4AABjKHgAAEx8AAFwfAACiHwAA6h8AADIgAAB6IAAAvyAAAAQhAABLIQAAbyEA AHAhAACtIQAA9iEAAD4iAACAIgAArSIAAK4iAADiIgAA4yIAACsjAABWIwAAVyMAAHMjAAB0IwAA 0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAA AAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAA AAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEA AAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAA AAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAA ANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAAAAAAAAAALgAADcYyABCUAygHvApQDuQReBUMGaAc NCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAAPhAAAEmTwAAEAMSQBNyQBOCQBSCQBVkQA AF6EAABnZNtYDgAAGHQjAACbIwAAnCMAANUjAADWIwAA4SMAAOIjAAAnJAAAbiQAALMkAAC0JAAA tSQAAP4kAAD/JAAASCUAAEklAACGJQAAhyUAAIglAACZJQAAmiUAAOQlAAAFJgAABiYAAC8mAADR AAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAA AAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAA AADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAA AAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAA AAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA 0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAAAAAAAAAAAuAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0 IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAAA+EAAASZPAAAQAxJAE3JAE4JAFIJAFWRAAA XoQAAGdk21gOAAAYLyYAADAmAAB6JgAAwiYAAMMmAADyJgAA8yYAADYnAABXJwAAWCcAAKInAADL JwAAzCcAANQnAADVJwAA1icAAOUnAADmJwAAKigAACsoAAAsKAAAZigAAGcoAACxKAAA9ygAANEA AAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAA AAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAA ANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAA AAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAA AAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADR AAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAAAAAAAAAAC4AAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQg yCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAD4QAABJk8AABADEkATckATgkAUgkAVZEAABe hAAAZ2TbWA4AABj3KAAACikAAAspAAAMKQAALikAAC8pAAAwKQAARikAAEcpAACQKQAAnikAAJ8p AADoKQAAACoAAAEqAAACKgAAGyoAABwqAAA1KgAANioAAIAqAACBKgAAgioAAMsqAADMKgAA0QAA AAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAA AAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA 0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAA AAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAA AAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEA AAAAAAAAAAAAAADRAAAAAAAAAAAAAAAAAAAAAAAALgAADcYyABCUAygHvApQDuQReBUMGaAcNCDI I1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAAPhAAAEmTwAAEAMSQBNyQBOCQBSCQBVkQAAF6E AABnZNtYDgAAGMwqAAAVKwAAFisAACwrAAAtKwAASisAAEsrAACUKwAA1ysAANgrAAADLAAABCwA AE4sAACVLAAAwywAAMQsAAAGLQAAHS0AAB4tAAAfLQAAQC0AAEEtAABCLQAAWC0AAFktAADRAAAA AAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAA AAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADR AAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAA AAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAA AADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAA AAAAAAAAAAAAANEAAAAAAAAAAAAAAAAAAAAAAAAuAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgj XCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAAA+EAAASZPAAAQAxJAE3JAE4JAFIJAFWRAAAXoQA AGdk21gOAAAYWS0AAIYtAACHLQAAyi0AANYtAADXLQAA/C0AAP0tAAD+LQAAFy4AABguAABdLgAA oy4AAKQuAAC7LgAAvC4AAAUvAAAmLwAAJy8AACgvAABSLwAAUy8AAJkvAADgLwAAKTAAANEAAAAA AAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAA AAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEA AAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAA AAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAA ANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAA AAAAAAAAAAAA0QAAAAAAAAAAAAAAAAAAAAAAAC4AAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNc J/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAD4QAABJk8AABADEkATckATgkAUgkAVZEAABehAAA Z2TbWA4AABgpMAAAOjAAADswAAA8MAAAUjAAAFMwAACJMAAAijAAAIswAACMMAAA1TAAANYwAAAf MQAAIDEAACExAAA6MQAAOzEAAFIxAABTMQAAazEAAGwxAACvMQAA1zEAANgxAADZMQAA0QAAAAAA AAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAA AADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAA AAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAA AAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA 0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAA AAAAAAAAAADRAAAAAAAAAAAAAAAAAAAAAAAALgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn 8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAAAPhAAAEmTwAAEAMSQBNyQBOCQBSCQBVkQAAF6EAABn ZNtYDgAAGNkxAAD4MQAA+TEAAEMyAABdMgAAXjIAAF8yAAB1MgAAdjIAALMyAADeMgAA3zIAAOAy AAD6MgAA+zIAAEAzAABYMwAAWTMAAFozAACRMwAAkjMAAJMzAACsMwAArTMAAPYzAADRAAAAAAAA AAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAA ANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAA AAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAA AAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADR AAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAA AAAAAAAAANEAAAAAAAAAAAAAAAAAAAAAAAAuAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfw KoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAAA+EAAASZPAAAQAxJAE3JAE4JAFIJAFWRAAAXoQAAGdk 21gOAAAY9jMAAD00AACGNAAAzzQAAAo1AAALNQAADDUAADU1AAA2NQAANzUAAHM1AAB0NQAAtzUA AOg1AADpNQAA6jUAABw2AAAdNgAAZjYAAGc2AABoNgAAsTYAALI2AAD7NgAA/DYAANEAAAAAAAAA AAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA 0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAA AAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAA AAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEA AAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAA AAAAAAAA0QAAAAAAAAAAAAAAAAAAAAAAAC4AAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/Aq hC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAD4QAABJk8AABADEkATckATgkAUgkAVZEAABehAAAZ2Tb WA4AABj8NgAAQDcAAIc3AACcNwAAnTcAAJ43AADJNwAAyjcAABM4AABbOAAApDgAAOw4AAAEOQAA BTkAAAY5AAAYOQAAGTkAAGA5AACNOQAAjjkAAI85AACkOQAApTkAANM5AADUOQAA0QAAAAAAAAAA AAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADR AAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAA AAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAA AADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAA AAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAA AAAAAADRAAAAAAAAAAAAAAAAAAAAAAAALgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqE LhgyrDVAOQAAAAAAAAAAAAAAAAAAAAAPhAAAEmTwAAEAMSQBNyQBOCQBSCQBVkQAAF6EAABnZNtY DgAAGNQ5AAAcOgAALToAAC46AABxOgAAujoAAMM6AADEOgAA8joAAPM6AAA7OwAAPDsAAIY7AADD OwAA1jsAANc7AAAePAAAZDwAAKo8AADLPAAAzDwAAM08AAD4PAAA+TwAAEE9AADRAAAAAAAAAAAA AAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEA AAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAA AAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAA ANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAA AAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAA AAAAANEAAAAAAAAAAAAAAAAAAAAAAAAuAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQu GDKsNUA5AAAAAAAAAAAAAAAAAAAAAA+EAAASZPAAAQAxJAE3JAE4JAFIJAFWRAAAXoQAAGdk21gO AAAYQT0AAGI9AABjPQAAqj0AALk9AAC6PQAAuz0AALw9AAAFPgAABj4AAE8+AABQPgAAmD4AALw+ AAC9PgAA+D4AAPk+AAAVPwAAFj8AAD0/AAA+PwAAPz8AAEA/AABYPwAAWT8AANEAAAAAAAAAAAAA AADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAA AAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAA AAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA 0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAA AAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAA AAAA0QAAAAAAAAAAAAAAAAAAAAAAAC4AAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4Y Mqw1QDkAAAAAAAAAAAAAAAAAAAAAD4QAABJk8AABADEkATckATgkAUgkAVZEAABehAAAZ2TbWA4A ABhZPwAAfD8AAH0/AAB+PwAAfz8AAIA/AACBPwAAkD8AAJE/AACtPwAArj8AAO4/AAApQAAAKkAA AGRAAACkQAAApUAAAOVAAAAuQQAAXUEAAF5BAACeQQAA6EEAAPxBAAD9QQAA0QAAAAAAAAAAAAAA ANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAA AAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAA AAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADR AAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAA AAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAA AADRAAAAAAAAAAAAAAAAAAAAAAAALgAADcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqELhgy rDVAOQAAAAAAAAAAAAAAAAAAAAAPhAAAEmTwAAEAMSQBNyQBOCQBSCQBVkQAAF6EAABnZNtYDgAA GP1BAAA7QgAAekIAAHtCAACxQgAA40IAAORCAAAeQwAAY0MAAIJDAACDQwAAoUMAAKJDAACmQwAA p0MAAKhDAACpQwAAqkMAAKtDAAD0QwAA9UMAAD5EAAA/RAAAUkQAAFNEAADRAAAAAAAAAAAAAAAA 0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAA AAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAA AAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEA AAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAA AAAAAAAA0QAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAA ANEAAAAAAAAAAAAAAAAAAAAAAAAuAAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0IMgjXCfwKoQuGDKs NUA5AAAAAAAAAAAAAAAAAAAAAA+EAAASZPAAAQAxJAE3JAE4JAFIJAFWRAAAXoQAAGdk21gOAAAY U0QAAGhEAACTRAAAr0QAAMVEAADnRAAAD0UAABFFAAASRQAAFEUAABVFAAAXRQAAGEUAABpFAAAb RQAAHEUAAB1FAAAeRQAAH0UAANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAA ANEAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAAMsAAAAAAAAAAAAAAADCAAAA AAAAAAAAAAAAywAAAAAAAAAAAAAAAMIAAAAAAAAAAAAAAADLAAAAAAAAAAAAAAAAwgAAAAAAAAAA AAAAAMsAAAAAAAAAAAAAAADCAAAAAAAAAAAAAAAAvAAAAAAAAAAAAAAAAMsAAAAAAAAAAAAAAAC2 AAAAAAAAAAAAAAAArAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAKAAAPhKQBFiQBSWYBAAAAXoSkAQYXABYkAUlmAQAAAAAFFwARhGgBYIRoAQAIAAAPhKQBXoSk AWdk8CJAAAAFAAAPhKQBXoSkAS4AAA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1 QDkAAAAAAAAAAAAAAAAAAAAAD4QAABJk8AABADEkATckATgkAUgkAVZEAABehAAAZ2TbWA4AABIf RQAAQUUAAEJFAABDRQAAREUAAEVFAABGRQAAR0UAAGtFAABsRQAA7wAAAAAAAAAAAAAAAOUAAAAA AAAAAAAAAAB/AAAAAAAAAAAAAAAAfQAAAAAAAAAAAAAAAHcAAAAAAAAAAAAAAABxAAAAAAAAAAAA AAAAdwAAAAAAAAAAAAAAAGsAAAAAAAAAAAAAAABcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADxYAEYRaABYkAUlmAQAAAFdEMgBghFoAZ2Q7WC8ABhYAFiQBSWYBAAAAAAUW ABGEaAFghGgBAAUAAA+EpAFehKQBAAEXAGYAAGtkAAAAABYkARckAUlmAQAAAAKWOQADNAEHlPf8 CNZGAAPH/y8CSxssIgAEXgEAAAAAAAAAAAYBAAAAAAAAAAVCDgAAAAAAAAAABgEAAAAAAAAABegD AAAAAAAAAAAGAQAAAAAAABT2AogTFTYBF/YDAAAa1gwAAAD/AAAA/wAAAP8b1gwAAAD/AAAA/wAA AP8c1gwAAAD/AAAA/wAAAP8d1gwAAAD/AAAA/wAAAP801gYAAQUDAAA01gYAAQoDOQBh9gMAAGY0 AQoXABGEIQAWJAFJZgEAAABghCEAEBcAAyQBEYRoARYkAUlmAQAAAGCEaAFhJAFnZLRbXAAACWxF AACqRQAAq0UAAKxFAACtRQAArkUAAK9FAACwRQAAsUUAAPIAAAAAAAAAAAAAAABnAAAAAAAAAAAA AAAAZQAAAAAAAAAAAAAAAF8AAAAAAAAAAAAAAABZAAAAAAAAAAAAAAAAXwAAAAAAAAAAAAAAAFMA AAAAAAAAAAAAAABfAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABRYAEYRo AWCEaAEABRcAEYRoAWCEaAEABQAAD4SkAV6EpAEAARYAiwAAa2SRAAAAFiQBFyQBSWYBAAAAApZs AAXWGAQBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjWRgADlP//BpcZoiQABOkDAAAAAAAAAAAAAAAA AAAAAAAEzQkAAAAAAAAAAAAAAAAAAAAAAATSBQAAAAAAAAAAAAAAAAAAAAAKdAAA4AET1jAAAAD/ BAEAAAAAAP8AAAAAAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAU9gLNFBU2ARf2AwAA GtYMAAAA/wAAAP8AAAD/G9YMAAAA/wAAAP8AAAD/HNYMAAAA/wAAAP8AAAD/HdYMAAAA/wAAAP8A AAD/NNYGAAEFAwAANNYGAAEKA2wAYfYDAAANFgADJAIRhGgBFiQBSWYBAAAAYIRoAWEkAgAIsUUA ALJFAACzRQAA9gAAAAAAAAAAAAAAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4A AA3GMgAQlAMoB7wKUA7kEXgVDBmgHDQgyCNcJ/AqhC4YMqw1QDkAAAAAAAAAAAAAAAAAAAAAD4QA ABJk8AABADEkATckATgkAUgkAVZEAABehAAAZ2TbWA4AAAgAAA+EpAFehKQBZ2TwIkAAAAI2ADGQ OAEyUAIAOnDbWA4AH7CCLiCwxkEhsIoFIrAFByOQoAUkkKAFJbAAABewUwMYsOADDJCpAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI8AFiQB FyQBSWYBAAAAAZYAACF2AANoATXWBQABA2gCNdYFAQIDHBk11gUCAwPhBiN2AAFoAiN2AQIcGSN2 AgPhBjpWCwACljkAAzQBB5T3/BT2AogTFTYBLNYDAQMCNdYFAAECXgE11gUBAgJCDjXWBQIDAugD L9YLAAMEAAAA/wYBAAA01gYAAQoDOQBmNAGhABYkARckAUlmAQAAAAGWAAAhdgADaAE11gUAAQNr BzXWBQECA5gSNdYFAgMDCwsjdgABawcjdgECmBIjdgIDCws6VgsAApZsAAp0AADgARPWMAAAAP8E AQAAAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAAAAD/AAAAABT2As0UFTYBNdYFAAEC 6QM11gUBAgLNCTXWBQIDAtIFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABiBCAAEgABAAsBDwAH AAAABAAAAAAABAAIAAAACAAAAAgAAAAIAAAADgAAAA4AAAAOAAAADgAAAA4AAAAOAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAADAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAyBgAAGAAAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABg BAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAMgYAACgCAADYAQAA6AEAACAE AAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQA ADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAA MAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAw BAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAE AABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQA AEAEAABQBAAAYAQAAHAEAACABAAAkAQAADgBAABYAQAA+AEAAAgCAAAYAgAAVgIAAH4CAAAYAAAA UEoEAF9IAQRtSAkEbkgECHNICQR0SAQIAAAAAGYAAGDx/wIAZgAMEAAATALkAAAABgBOAG8AcgBt AGEAbAAAACAAAAAPhMgAEmRoAQEAMSQANyQAOCQASCQAVkTIAF6EyAAgAENKFQBQSgAAX0gBBGFK FQBtSAkEbkgECHNICQR0SAQIhgABIPH/IgCGAAwQAABMAuQAAAAJAEgAZQBhAGQAaQBuAGcAIAAx AAAALQABAAMkAwYkAQomAAtGIwAPhK8BEYRR/hOk8AAUpPAAQCYAXoSvAWCEUf5hJAMAKwA1CIFD SiAAT0oCAFBKBQBRSgIAX0gBBGFKIABtSAkEbkgECHNICQR0SAQIAHIAAiDx/wIAcgAMEAAATALk AAAACQBIAGUAYQBkAGkAbgBnACAAMgAAAB0AAgADJAMGJAEKJgELRiMAE6TwABSk8ABAJgFhJAMA KABDShgAT0oCAFBKBQBRSgIAX0gBBGFKGABtSAkEbkgECHNICQR0SAQIdAADAAEAAgB0AAwQAABM AuQAAAAJAEgAZQBhAGQAaQBuAGcAIAAzAAAALAADAAUkAQYkAQomAgtGIwASZKABAQATpAQBFKQE ATckATgkAUAmAkgkAWEkAxsAQ0oYAEtIAgBPSgIAUEoCAFFKAgBcCAFhShgAAAAAAAAAAAAAAAAA AEQAQSDy/6EARAAMDQAAAAAAABAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgA IABGAG8AbgB0AAAAAABSAGlA8/+zAFIADB0AAAAAAAAwBgwAVABhAGIAbABlACAATgBvAHIAbQBh AGwAAAAcABf2AwAANNYGAAEKA2wANNYGAAEFAwAAYfYDAAACAAsAAAAoAGsg9P/BACgAAA0AAAAA AAAwBgcATgBvACAATABpAHMAdAAAAAIADAAAAAAAZgD+L/H/AgBmAAwAAABMAuQAAAAFAFQAYQBi AGwAZQAAAB4ADwADJAEFJAEKJggLRgUAD4QAAFhEZABehAAAYSQBJABDShIAT0oCAFFKAgBfSAEE YUoSAG1ICQRuSAQIc0gJBHRIBAhgAP4v8f8CAWAABAAAAEwC5AAAAAoAVABhAGIAbABlACAAVABl AHgAdAAAAAoAEAANxgUAAQAAAycAQ0oVAE9KAgBRSgIAX0gBBGFKFQBtSAAEbkgABHNICQR0SAQI dQgBAGIA/i/x/xIBYgAMAAAATALkAAAADABUAGEAYgBsAGUAIABIAGUAYQBkAGUAcgAAAAgAEQAD JAFhJAEnADUIgUNKFQBPSgIAUUoCAF9IAQRhShUAbUgJBG5IBAhzSAkEdEgECACIAP4vswAjAYgA DAAAAEwC5AAAAAsAVABhAGIAbABlACAAUwB0AHkAbABlAAAARwA6VhIAE9YwAAAA/wQBAAAAAAD/ BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAfDQBh9YKAAAA/wAAAP8AAAAFABIA YSQDAAgAQ0oSAGFKEgBCAJkAAQAyAUIADAAYAEwC5AAAAAwAQgBhAGwAbABvAG8AbgAgAFQAZQB4 AHQAAAAIABMAEmTwAAEACABDShIAYUoSAFIA/g8BAEIBUgAMAAAATALkAAAADABGAGkAZwB1AHIA ZQAgAFMAdAB5AGwAZQAAAB8AFAAGJAETpFAAFKRQADEkAVZEAABehAAAXoQAAGEkAQAAAGwA/g8B AFIBbAAMAAAATALkAAAADgBEAG8AYwB1AG0AZQBuAHQAIABUAGkAdABsAGUAAAAhABUAE6QsARSk LAEVxgUAAQAAAFZEAABehAAAXoQAAGEkAQAUAENKJABPSgIAUEoFAFFKAgBhSiQAWAAgYPH/YgFY AAwAAABMAuQAAAAGAEYAbwBvAHQAZQByAAAADQAWAA3GCAACnhE8IwECACQAQ0oSAE9KAgBRSgIA X0gBBGFKEgBtSAkEbkgECHNICQR0SAQIYAAfYPH/cgFgAAwAAABMAuQAAAAGAEgAZQBhAGQAZQBy AAAAFgAXAAMkAw3GCAACORByIAECRyQAYSQDJABDShIAT0oCAFFKAgBfSAEEYUoSAG1ICQRuSAQI c0gJBHRIBAhGAP4PogCBAUYADAATAEwC5AAAABEAQgBhAGwAbABvAG8AbgAgAFQAZQB4AHQAIABD AGgAYQByAAAADABDShIAUEoAAGFKEgBSAP4PAQCSAVIADAAAAEwC5AAAAAwATgBvAHQAZQBzACAA SABlAGEAZABlAHIAAAAQABkATsYIAAAAAAQBAQBhJAMQAENKEgBPSgIAUEoFAFFKAgBWAP4PAQCi AVYADAAAAEwC5AAAAAoATgBvAHQAZQBzACAAVABlAHgAdAAAABQAGgBQxggAAAAABAEBAGCEaAFh JAMUAENKEgBPSgIAUEoGAFFKAgBhShIAVAD+DwEAsgFUAAwAAABMAuQAAAAQAEMAbwBtAHAAaQBs AGkAbgBnACAAQQBkAHYAaQBjAGUAAAACABsAGAA2CAFCKgJPSgIAUUoCAF5KAgBwaAAA/wBCAP4P AQDCAUIADAAAAEwC5AAAAAYARgBpAGcAdQByAGUAAAAYABwACiYHC0YFAFZEAABehAAAXoQAAGEk AQQAUEoEAEAAswABANIBQAAMEAAA8DoLACACDgBMAGkAcwB0ACAAUABhAHIAYQBnAHIAYQBwAGgA AAAJAB0AXoTQAm0kAQAAAKYAZQABAOIBpgAMCB8A21gOADAGEQBIAFQATQBMACAAUAByAGUAZgBv AHIAbQBhAHQAdABlAGQAAABVAB4AEmTwAAEAFcYyABCUAygHvApQDuQReBUMGaAcNCDII1wn8CqE LhgyrDVAOQAAAAAAAAAAAAAAAAAAAAAxJAE3JAE4JAFIJAFWRAAAXoQAAF6EAAAAFABDShQAT0oD AFFKAwBeSgMAYUoUAFQA/g+iAPEBVAAMAB4A21gOADAGFgBIAFQATQBMACAAUAByAGUAZgBvAHIA bQBhAHQAdABlAGQAIABDAGgAYQByAAAAEABPSgMAUEoAAFFKAwBeSgMAUEsDBBQABgAIAAAAIQCC irwT+gAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rDMBBF94X+g9C22HK6KKXYzqJJ d30s0g8Y5LEtao+ENAnJ33fsuFC6CC10IxBizpl7Va6P46AOGJPzVOlVXmiFZH3jqKv0++4pu9cq MVADgyes9AmTXtfXV+XuFDApmaZU6Z45PBiTbI8jpNwHJHlpfRyB5Ro7E8B+QIfmtijujPXESJzx xNB1+SoLRNegeoPILzCKx7Cg8Pv5DCSAmAtYq8czYVqi0hDC4CywRDAHan7oM9+2zmLj7X4UaT6D F9jNBDO/XGD1P+ov5wZb2A+stkfp4lx/xCH9LdtSay6Tc/7Uu5AuGC6Xt7Rh5r+tPwEAAP//AwBQ SwMEFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAABfcmVscy8ucmVsc4SPz2rDMAyH74W9g9F9UdLD GCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cGCrsIhKTv96k9/q6L+eGU5yAWmqoGw+JDP8to4XY9v3+C yYWkpyUIW3hwhqN727VfvFDRozzNMRulSLYwlRIPiNlPvFKuQmTRyRDSSkXbNGIkf6eRcV/XH5ie GeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzlRQRuN5RMaeRioagv41O9kKhlqtQe0LW4+db9AQAA //8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACKAAAAHAAAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdl ci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLLrrv2AEOcGkHHoNKf29fl44M3zt8U1ZtLDVksnAcN imXNLoi38Hwspxuo2kgcxSxs4ccV5ul4GMm0jRPfSchzUX0j1ZCFrbXdINa1K9Uh7yzdXrkkaj2L R1fo0/cp4kXrKyYKAjj9AQAA//8DAFBLAwQUAAYACAAAACEAlrWt4pYGAABQGwAAFgAAAHRoZW1l L3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZstTRvEboceaYmW2FCiQNJJ fRva44ABw7phhxXYbYdhW4EW2KX7NNk6bB3Qr7BHUpLFWF6SNtiKrT4kEvnj+/8eH6mr1+7HDB0S ISlP2l79cs1DJPF5QJOw7d0e9i+teUgqnASY8YS0vSmR3rWN99+7itdVRGKCYH0i13Hbi5RK15eW pA/DWF7mKUlgbsxFjBW8inApEPgI6MZsablWW12KMU08lOAYyN4aj6lP0FCT9DZy4j0Gr4mSesBn YqBJE2eFwQYHdY2QU9llAh1i1vaAT8CPhuS+8hDDUsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxB cLBseIpwVDCt9xutK1sFfQNgah7X6/W6vXpBzwCw74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ ypzMrU6n02xlsliiBmQfG3P4tdpqY3PZwRuQxTfn8I3OZre76uANyOJX5/D9K63Vhos3oIjR5GAO rR3a72fUC8iYs+1K+BrA12oZfIaCaCiiS7MY80QtirUY3+OiDwANZFjRBKlpSsbYhyju4ngkKNYM 8DrBpRk75Mu5Ic0LSV/QVLW9D1MMGTGj9+r596+eP0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/9 7M/HH6M/nn7z8tEX1XhZxv/6wye//Px5NRDSZybOiy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvk CO3zGBQzVnElJyNxvhXDCNPyis0klDjBmksF/Z6KHPTNKWaZdxw5OsS14B0B5aMKeH1yzxF4EImJ ohWcd6LYAe5yzjpcVFphR/MqmXk4ScJq5mJSxu1jfFjFu4sTx7+9SQp1Mw9LR/FuRBwx9xhOFA5J QhTSc/yAkArt7lLq2HWX+oJLPlboLkUdTCtNMqQjJ5pmi7ZpDH6ZVukM/nZss3sHdTir0nqLHLpI yArMKoQfEuaY8TqeKBxXkRzimJUNfgOrqErIwVT4ZVxPKvB0SBhHvYBIWbXmlgB9S07fwVCxKt2+ y6axixSKHlTRvIE5LyO3+EE3wnFahR3QJCpjP5AHEKIY7XFVBd/lbobod/ADTha6+w4ljrtPrwa3 aeiINAsQPTMR2pdQqp0KHNPk78oxo1CPbQxcXDmGAvji68cVkfW2FuJN2JOqMmH7RPldhDtZdLtc BPTtr7lbeJLsEQjz+Y3nXcl9V3K9/3zJXZTPZy20s9oKZVf3DbYpNi1yvLBDHlPGBmrKyA1pmmQJ +0TQh0G9zpwOSXFiSiN4zOq6gwsFNmuQ4OojqqJBhFNosOueJhLKjHQoUcolHOzMcCVtjYcmXdlj YVMfGGw9kFjt8sAOr+jh/FxQkDG7TWgOnzmjFU3grMxWrmREQe3XYVbXQp2ZW92IZkqdw61QGXw4 rxoMFtaEBgRB2wJWXoXzuWYNBxPMSKDtbvfe3C3GCxfpIhnhgGQ+0nrP+6hunJTHirkJgNip8JE+ 5J1itRK3lib7BtzO4qQyu8YCdrn33sRLeQTPvKTz9kQ6sqScnCxBR22v1VxuesjHadsbw5kWHuMU vC51z4dZCBdDvhI27E9NZpPlM2+2csXcJKjDNYW1+5zCTh1IhVRbWEY2NMxUFgIs0Zys/MtNMOtF KWAj/TWkWFmDYPjXpAA7uq4l4zHxVdnZpRFtO/ualVI+UUQMouAIjdhE7GNwvw5V0CegEq4mTEXQ L3CPpq1tptzinCVd+fbK4Ow4ZmmEs3KrUzTPZAs3eVzIYN5K4oFulbIb5c6vikn5C1KlHMb/M1X0 fgI3BSuB9oAP17gCI52vbY8LFXGoQmlE/b6AxsHUDogWuIuFaQgquEw2/wU51P9tzlkaJq3hwKf2 aYgEhf1IRYKQPShLJvpOIVbP9i5LkmWETESVxJWpFXtEDgkb6hq4qvd2D0UQ6qaaZGXA4E7Gn/ue ZdAo1E1OOd+cGlLsvTYH/unOxyYzKOXWYdPQ5PYvRKzYVe16szzfe8uK6IlZm9XIswKYlbaCVpb2 rynCObdaW7HmNF5u5sKBF+c1hsGiIUrhvgfpP7D/UeEz+2VCb6hDvg+1FcGHBk0Mwgai+pJtPJAu kHZwBI2THbTBpElZ02atk7ZavllfcKdb8D1hbC3ZWfx9TmMXzZnLzsnFizR2ZmHH1nZsoanBsydT FIbG+UHGOMZ80ip/deKje+DoLbjfnzAlTTDBNyWBofUcmDyA5LcczdKNvwAAAP//AwBQSwMEFAAG AAgAAAAhAA3RkJ+2AAAAGwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1s LnJlbHOEj00KwjAUhPeCdwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My 3jFoqhoIOumVcZrBbbjsjkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44 o49W5CKjpkHIu9BI93V9oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4COb qkwEylu6usTfAAAA//8DAFBLAQItABQABgAIAAAAIQCCirwT+gAAABwCAAATAAAAAAAAAAAAAAAA AAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAA AAAAAAAAAAAAKwEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAA AAAAAAAAAAAAFAIAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEA lrWt4pYGAABQGwAAFgAAAAAAAAAAAAAAAADRAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQIt ABQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAAAAAAAAAAAAAAJsJAAB0aGVtZS90aGVtZS9fcmVs cy90aGVtZU1hbmFnZXIueG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAlgoAAAAAPD94bWwgdmVyc2lv bj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/Pg0KPGE6Y2xyTWFwIHht bG5zOmE9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9yZy9kcmF3aW5nbWwvMjAwNi9t YWluIiBiZzE9Imx0MSIgdHgxPSJkazEiIGJnMj0ibHQyIiB0eDI9ImRrMiIgYWNjZW50MT0iYWNj ZW50MSIgYWNjZW50Mj0iYWNjZW50MiIgYWNjZW50Mz0iYWNjZW50MyIgYWNjZW50ND0iYWNjZW50 NCIgYWNjZW50NT0iYWNjZW50NSIgYWNjZW50Nj0iYWNjZW50NiIgaGxpbms9ImhsaW5rIiBmb2xI bGluaz0iZm9sSGxpbmsiLz4AAAAAsz0AAA0AAHgAAAoA/////wAAAAADAAAABgAAAAYAAAAJAAAA DAAAAAwAAAAOAAAANgAAADgAAACeAAAAoAAAAKIAAAClAAAAAAgAALNFAAAjAAAAAAgAALcKAACt DQAAEREAAOkXAAD5GQAAyh4AAHQjAAAvJgAA9ygAAMwqAABZLQAAKTAAANkxAAD2MwAA/DYAANQ5 AABBPQAAWT8AAP1BAABTRAAAH0UAAGxFAACxRQAAs0UAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAA ACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAA OAAAADkAAAA6AAAAOwAAADgAAABPAAAAWgAAAGEAAABmAAAAaAAAAHAAAACWAAAAmQAAAKUAAAAT H5T/lYATIRT/lYATGhT/lYAPAADwbAAAAAAABvA4AAAAAhgAAAYAAAACAAAAAgAAAAIAAAABAAAA AQAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjAAvwDAAAAIZBAAAAAMVBAAAAAEAAHvEQ AAAA//8AAAAA/wCAgIAA9wAAEAEPAALwSAAAACAACPAIAAAAAQAAAAAEAAAPAAPwMAAAAA8ABPAo AAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAABAAABQAAAAAPAALwkgAAABAACPAI AAAAAQAAAAEIAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgA AAAACAAABQAAAA8ABPBCAAAAEgAK8AgAAAABCAAAAA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEA AAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAAAAAAAD0BAABEAQAARQEAAE0BAADFBAAAzgQAAGQI AABrCAAAbAgAAHQIAADUDgAA3A4AAGcSAABuEgAAbxIAAHcSAADaEwAA3xMAADEUAAA2FAAA+BQA AP0UAADsFgAA8hYAAIgYAACPGAAAwhgAAMgYAACRGgAAnRoAACMdAAAqHQAAKx0AADMdAADwIgAA 9yIAAPgiAAAAIwAAPCYAAD4mAAD6KAAAASkAAAIpAAAKKQAA8i0AAPotAABPLgAAVy4AANYuAADd LgAA3i4AAOYuAABDLwAASy8AACo2AAAxNgAAMjYAADo2AADFNwAAyDcAADc4AABAOAAARjgAAE44 AABrOQAAcTkAAHc5AAB+OQAACjoAABE6AAAXOgAAHDoAACI6AAAqOgAAiDoAAI06AACYOgAAnToA APE6AAD2OgAA/DoAAAA7AABSOwAAYTsAABk8AAAgPAAAITwAACk8AACCPAAAjTwAAJk8AACkPAAA Dz0AABE9AAASPQAAFD0AABU9AAAXPQAAGD0AABo9AAAbPQAAHz0AACY9AAA4PQAAQD0AALE9AAC0 PQAABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHQAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcABwACAAcAAgAHAAIABwACAAcAHAAHABwABwACAAAAAAByAQAAlQEA AOoBAAD4AQAALgIAADkCAAB1AgAAeAIAALoCAADHAgAAJwMAADEDAADdAwAA5gMAACYEAAAoBAAA pAQAAKcEAADtBAAA8QQAAC8FAAA3BQAABwYAAA8GAADWBgAA2gYAAB4HAAAnBwAAaAcAAGoHAACw BwAAtwcAAI0IAACQCAAA0QgAANoIAAD0CQAABQoAAEEKAABNCgAAjgoAAJsKAADXCgAA5woAABwL AAAnCwAAaQsAAHYLAACyCwAAwgsAAPcLAAACDAAARAwAAFEMAACNDAAAnQwAANIMAADaDAAAGw0A ACENAABkDQAAbA0AAKkNAAC6DQAA9g0AAPoNAAA/DgAARA4AAIQOAACVDgAA0Q4AANwOAAAaDwAA IA8AAKgPAAC4DwAA8Q8AAAIQAAAVEQAAIREAAF4RAABsEQAA5BIAAO4SAAApEwAAMRMAAJwUAACe FAAA2BQAAOcUAAAgFQAAJRUAAGkVAABqFQAA+BUAAAAWAABCFgAARRYAAIUWAACMFgAAzRYAANEW AAAWFwAAFxcAAF8XAABhFwAAfxcAAIQXAAClFwAAqhcAAO0XAADwFwAANRgAADsYAAB9GAAAfxgA AMIYAADHGAAABxkAAA0ZAABOGQAAUhkAALAZAAC9GQAA+RkAAP8ZAABBGgAARhoAAIMaAACNGgAA 6BoAAOwaAAAuGwAANRsAAKEbAACvGwAA2xsAAN4bAAAqHAAAMxwAAHEcAAB/HAAATB0AAFMdAADn HQAA6R0AAH0eAACBHgAAOR8AAEAfAAClHwAArx8AAC8gAABAIAAAtCAAALYgAAD6IAAAByEAABEh AAAdIQAANyEAAEQhAABMIQAATiEAAJMhAACcIQAA6yEAAO8hAAAJIgAAGSIAABkjAAAgIwAAlyMA AJ0jAABRJAAAUyQAAJgkAACcJAAACSUAABIlAAAkJQAALyUAAEklAABWJQAAzSUAANQlAAAFJgAA FSYAAGAmAABnJgAACCcAAAwnAAAtJwAAOCcAAJwnAACgJwAA4ycAAOcnAAAsKAAALygAAEMoAABQ KAAAKCkAADgpAACyKQAAuykAAN4pAADmKQAARioAAE4qAABkKgAAaioAALYqAADDKgAA5SoAAO0q AABDKwAATisAAF0rAABuKwAAmCsAAJwrAAD5KwAA/SsAAEAsAABELAAA0iwAANcsAAARLQAAFi0A ADotAABLLQAAui0AAMItAADvLQAA+i0AAP8uAAADLwAAQy8AAEsvAACKLwAAjS8AAKMvAACpLwAA FjAAABkwAABeMAAAYDAAAKcwAACuMAAA7zAAAPEwAABjMQAAbjEAAJIxAACiMQAAHzIAACEyAAB0 MgAAhzIAAL0yAADAMgAAiTMAAJAzAADGMwAA1DMAACE0AAAkNAAA0DQAAOE0AABENQAAYDUAAK01 AAC3NQAAmzYAAJ42AACUNwAAoDcAAI05AACQOQAACjoAADk6AABdOwAAYTsAAIY7AACUOwAADz0A ABE9AAASPQAAFD0AABU9AAAXPQAAGD0AABo9AAAbPQAAsT0AALQ9AAAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcABwACAAcAAgAHAAIA BwACAAcAAgAAAAAAcQEAAJgBAADqAQAAdQIAAIcCAAC6AgAAzQIAACcDAABNAwAA3QMAAPsDAAAm BAAAWgQAAKQEAADtBAAA8wQAAC8FAABvBQAABwYAABkGAADWBgAA/AYAAB4HAABoBwAAegcAALAH AAD2BwAAjQgAAP4IAADxCQAA9wkAADwKAABECgAAhwoAAJEKAADQCgAA2goAABcLAAAfCwAAYgsA AGwLAACrCwAAtQsAAPILAAD6CwAAPQwAAEcMAACGDAAAkAwAAM0MAADVDAAAFg0AAB4NAABfDQAA Zw0AAKYNAACsDQAA8Q0AAPkNAAA6DgAAQg4AAIEOAACHDgAAzA4AANQOAAAVDwAAHQ8AAKUPAACr DwAA7g8AAPQPAAASEQAAGBEAAFsRAABhEQAA5BIAACATAAApEwAAcRMAAJwUAADYFAAA8xQAACAV AAA0FQAAaRUAALEVAAD4FQAALRYAAEIWAACFFgAAmxYAAM0WAAClFwAAwxcAAO0XAAAHGAAANRgA AAcZAAAXGQAAThkAAHMZAACwGQAAzRkAAPkZAABgGgAAgxoAALEaAADmGgAAWhsAAJ8bAADZGwAA 5RsAACocAAC1HAAATB0AAIgdAADnHQAACR4AAH0eAADGHgAAOR8AAFsfAAClHwAAzx8AACwgAAAy IAAAtCAAAL8gAAD6IAAAFCEAADAhAAA6IQAASiEAAJMhAACiIQAA6yEAAAwiAAAZIwAAMCMAAJcj AADbIwAAUSQAAMckAAAJJQAAJyUAAEIlAABMJQAAzSUAANolAAD+JQAACCYAAGAmAACnJgAACCcA ACgnAAAwJwAAnCcAACwoAABGKAAAISkAACspAACyKQAA4SkAAEYqAABnKgAAtioAAOgqAABDKwAA YCsAAJMrAACbKwAA+SsAACAsAABALAAAiSwAANIsAAAMLQAAFC0AADctAAA9LQAAui0AAOotAADy LQAA/y4AAAUvAABDLwAAii8AAKYvAAAWMAAA7zAAAAYxAABjMQAAjzEAAJUxAAAfMgAAMTIAAHQy AACIMgAAvTIAAMcyAACJMwAAxjMAANozAAAhNAAAZzQAAM00AADTNAAARDUAAGY1AACtNQAAvDUA AJs2AADANgAAkTcAAJc3AABhOQAAqzkAAAA6AABIOgAAKzsAAHA7AACDOwAAiTsAAA49AAAPPQAA cD0AAHg9AAB/PQAAqT0AALQ9AAADAAcAAwAHAAUAAwAFAAMABwADAAUAAwAHAAMABwAFAAMABwAD AAUAAwAHAAMABwAFAAMABwADAAcAAwAFAAMABQADAAUAAwAFAAMABQADAAUAAwAFAAMABQADAAUA AwAFAAMABQADAAUAAwAFAAMABQADAAUAAwAFAAMABQADAAUAAwAFAAMABQADAAUAAwAFAAMABQAD AAcAAwAHAAMABwAFAAMABQADAAcAAwAHAAMABwAFAAMABwAFAAMABwADAAcABQADAAcAAwAFAAMA BwADAAcAAwAHAAMABwAFAAMABwADAAcAAwAHAAMABwADAAUAAwAFAAMABQADAAUAAwAFAAMABQAD AAcABQADAAUAAwAFAAMABwADAAcAAwAFAAMABQADAAUAAwAFAAMABwADAAcABQADAAcABQADAAUA AwAHAAMABQADAAcAAwAFAAMABQADAAcAAwAHAAMABwAFAAMABQADAAcABQADAAUAAwAHAAUAAwAH AAUAAwAHAAUAAwAFAAMABQADAAUAAwAHAAUAAwAHAAMABQADAAUAAwAFAAMABwADAAUAAwAFAAMA BwADAAcAAwAFAAMABwACAAcAAgAHAAIADwAjdz0KdsTQs/8P/w//D/8P/w//D/8P/w//DwAA8FBs C1LamhT/D/8P/w//D/8P/w//D/8P/w8AAPA+RSAsBibx/w//D/8P/w//D/8P/w//D/8PAACIaJ0r HQAJBP8P/w//D/8P/w//D/8P/w//DwAAqiHIMHbXKlD/D/8P/w//D/8P/w//D/8P/w8AAEBlADLC fiDP/w//D/8P/w//D/8P/w//D/8PAAAeeSs4HQAJBP8P/w//D/8P/w//D/8P/w//DwAA5U/kOJrn BP//D/8P/w//D/8P/w//D/8P/w8QAPRbSz/Ag1Rv/w//D/8P/w//D/8P/w//D/8PEAAKV/5CbuGs IP8P/w//D/8P/w//D/8PHAAPAAAA2FVBUuhTaqr/D/8P/w//D/8P/w//D/8P/w8AAHkI/FQdAAkE /w//D/8P/w//D/8P/w//D/8PAAApZFRjolNG/gEAAgADAP8P/w//D/8P/w//DwAAan40cgBHXNn/ D/8P/w//D/8P/w//D/8P/w8AAA47Dn7y+C7m/w//D/8P/w//D/8P/w//D/8PAAABAAAAAAABAAAA AAAAAAAAAAAAAAAAAAADGAAAD4SwARGEUP4VxgUAAbABBl6EsAFghFD+bygBAQAAAAEAAAAAAAED AAAAAAAAAAAAAAAAAAAAAAMYAAAPhEACEYTA/RXGBQABQAIGXoRAAmCEwP1vKAEDAAAALgABAAEA AAAAAAEDBQAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw/RXGBQAB0AIGXoTQAmCEMP1vKAEFAAAA LgABAC4AAgABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4SoAxGEWP0VxgUAATcCBl6EqANg hFj9bygBAgADAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+EqAMRhFj9FcYFAAE3AgZe hKgDYIRY/W8oAQIABAAJ/wEAAAAEAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhKgDEYRY/RXGBQAB NwIGXoSoA2CEWP1vKAECAAUACf8BAAAAAgABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4SoAxGEWP0V xgUAATcCBl6EqANghFj9bygAAQAGAAEAAAAAAAEDBQcJCw0PAAAAAAAAAAAAAAMYAAAPhKAFEYRg +hXGBQABoAUGXoSgBWCEYPpvKAEPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAAEAAAAA AAEDBQcJCw0PEQAAAAAAAAAAAAMYAAAPhDAGEYTQ+RXGBQABMAYGXoQwBmCE0PlvKAERAAAALgAB AC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAABAAAAAwADAAAAAAAAAAAAAAAAAAAAAAADGAAA D4QDBRGEUP4VxgUAAQMFBl6EAwVghFD+bygBAwBEllVfAAABAAAAAAABAwAAAAAAAAAAAAAAAAAA AAADGAAAD4STBRGEwP0VxgUAAZMFBl6EkwVghMD9bygBAwAAAC4AAQABAAAAAAABAwUAAAAAAAAA AAAAAAAAAAADGAAAD4QjBhGEMP0VxgUAASMGBl6EIwZghDD9bygBBQAAAC4AAQAuAAIAAQAAAAAA AQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E+wYRhFj9FcYFAAGKBQZehPsGYIRY/W8oAQIAAwAuAAEA AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhPsGEYRY/RXGBQABigUGXoT7BmCEWP1vKAECAAQA Cf8BAAAABAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4T7BhGEWP0VxgUAAYoFBl6E+wZghFj9bygB AgAFAAn/AQAAAAIAAQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E+wYRhFj9FcYFAAGKBQZehPsGYIRY /W8oAAEABgABAAAAAAABAwUHCQsNDwAAAAAAAAAAAAADGAAAD4TzCBGEYPoVxgUAAfMIBl6E8whg hGD6bygBDwAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwABAAAAAAABAwUHCQsNDxEAAAAA AAAAAAADGAAAD4SDCRGE0PkVxgUAAYMJBl6EgwlghND5bygBEQAAAC4AAQAuAAIALgADAC4ABAAu AAUALgAGAC4ABwAuAAgAAQAAAAMAAwAAAAAAAAAAAAAAAAAAAAAAAxgAAA+EsAERhFD+FcYFAAGw AQZehLABYIRQ/m8oAQMARJZVXwAAAQAAAAAAAQMAAAAAAAAAAAAAAAAAAAAAAxgAAA+EQAIRhMD9 FcYFAAFAAgZehEACYITA/W8oAQMAAAAuAAEAAQAAAAAAAQMFAAAAAAAAAAAAAAAAAAAAAxgAAA+E 0AIRhDD9FcYFAAHQAgZehNACYIQw/W8oAQUAAAAuAAEALgACAAEAAAAAAAEAAAAAAAAAAAAAAAAA AAAAAAMYAAAPhKgDEYRY/RXGBQABNwIGXoSoA2CEWP1vKAECAAMALgABAAAAAAABAAAAAAAAAAAA AAAAAAAAAAADGAAAD4SoAxGEWP0VxgUAATcCBl6EqANghFj9bygBAgAEAAn/AQAAAAQAAQAAAAAA AAAAAAAAAAAAAAAAAxgAAA+EqAMRhFj9FcYFAAE3AgZehKgDYIRY/W8oAQIABQAJ/wEAAAACAAEA AAAAAAAAAAAAAAAAAAAAAAMYAAAPhKgDEYRY/RXGBQABNwIGXoSoA2CEWP1vKAABAAYAAQAAAAAA AQMFBwkLDQ8AAAAAAAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg+m8oAQ8AAAAuAAEA LgACAC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAAAAAQMFBwkLDQ8RAAAAAAAAAAAAAxgAAA+EMAYR hND5FcYFAAEwBgZehDAGYITQ+W8oAREAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAI AAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhKkBEYRX/hXGBQABqQEGXoSpAWCEV/4BAAAA AQAAAAAAAQMAAAAAAAAAAAAAAAAAAAAAABgAAA+E4AMRhMn9FcYFAAF5BAZehOADYITJ/QMAAAAu AAEAAQAAAAAAAQMFAAAAAAAAAAAAAAAAAAAAABgAAA+EigURhMn9FcYFAAGLBwZehIoFYITJ/QUA AAAuAAEALgACAAEAAAAAAAEDBQcAAAAAAAAAAAAAAAAAAAAYAAAPhMAHEYQ8/RXGBQABBAwGXoTA B2CEPP0HAAAALgABAC4AAgAuAAMAAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAAABgAAA+E9wkRhK78 FcYFAAEVDwZehPcJYISu/AkAAAAuAAEALgACAC4AAwAuAAQAAQAAAAAAAQMFBwkLAAAAAAAAAAAA AAAAABgAAA+EvAwRhJL7FcYFAAEmEgZehLwMYISS+wsAAAAuAAEALgACAC4AAwAuAAQALgAFAAEA AAAAAAEDBQcJCw0AAAAAAAAAAAAAAAAYAAAPhPMOEYQE+xXGBQABNxUGXoTzDmCEBPsNAAAALgAB AC4AAgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAAABgAAA+EKhERhHb6 FcYFAAFIGAZehCoRYIR2+g8AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAAAAAQMF BwkLDQ8RAAAAAAAAAAAAABgAAA+E7hMRhFz5FcYFAAFaGwZehO4TYIRc+REAAAAuAAEALgACAC4A AwAuAAQALgAFAC4ABgAuAAcALgAIAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhLABEYRQ /hXGBQABsAEGXoSwAWCEUP5vKAEBAAAAAQAAAAAAAQMAAAAAAAAAAAAAAAAAAAAAAxgAAA+EQAIR hMD9FcYFAAFAAgZehEACYITA/W8oAQMAAAAuAAEAAQAAAAAAAQMFAAAAAAAAAAAAAAAAAAAAAxgA AA+E0AIRhDD9FcYFAAHQAgZehNACYIQw/W8oAQUAAAAuAAEALgACAAEAAAAAAAEAAAAAAAAAAAAA AAAAAAAAAAMYAAAPhKgDEYRY/RXGBQABNwIGXoSoA2CEWP1vKAECAAMALgABAAAAAAABAAAAAAAA AAAAAAAAAAAAAAADGAAAD4SoAxGEWP0VxgUAATcCBl6EqANghFj9bygBAgAEAAn/AQAAAAQAAQAA AAAAAAAAAAAAAAAAAAAAAxgAAA+EqAMRhFj9FcYFAAE3AgZehKgDYIRY/W8oAQIABQAJ/wEAAAAC AAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhKgDEYRY/RXGBQABNwIGXoSoA2CEWP1vKAABAAYAAQAA AAAAAQMFBwkLDQ8AAAAAAAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg+m8oAQ8AAAAu AAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAAAAAQMFBwkLDQ8RAAAAAAAAAAAAAxgAAA+E MAYRhND5FcYFAAEwBgZehDAGYITQ+W8oAREAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcA LgAIAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAABEYAAAPhLABEYRQ/hXGBQABsAEGXoSwAWCEUP41 CAA2CABDSiQAYUokAG8oAQEAAAABAAAAAAABAwAAAAAAAAAAAAAAAAAAAAARGAAAD4RAAhGEwP0V xgUAAUACBl6EQAJghMD9NQgANggAQ0oeAGFKHgBvKAEDAAAALgABAAEAAAAAAAEDBQAAAAAAAAAA AAAAAAAAABEYAAAPhNACEYQw/RXGBQAB0AIGXoTQAmCEMP01CAA2CABDShgAYUoYAG8oAQUAAAAu AAEALgACAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAABEYAAAPhKgDEYRY/RXGBQABNwIGXoSoA2CE WP01CAA2CABDShUAYUoVAG8oAQIAAwAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAABEYAAAPhKgD EYRY/RXGBQABNwIGXoSoA2CEWP01CAA2CABDShUAYUoVAG8oAQIABAAJ/wEAAAAEAAEAAAAAAAAA AAAAAAAAAAAAABEYAAAPhKgDEYRY/RXGBQABNwIGXoSoA2CEWP01CAA2CABDShUAYUoVAG8oAQIA BQAJ/wEAAAACAAEAAAAAAAAAAAAAAAAAAAAAABEYAAAPhKgDEYRY/RXGBQABNwIGXoSoA2CEWP01 CAA2CABDShUAYUoVAG8oAAEABgABAAAAAAABAwUHCQsNDwAAAAAAAAAAAAARGAAAD4SgBRGEYPoV xgUAAaAFBl6EoAVghGD6NQgANggAQ0oSAGFKEgBvKAEPAAAALgABAC4AAgAuAAMALgAEAC4ABQAu AAYALgAHAAEAAAAAAAEDBQcJCw0PEQAAAAAAAAAAABEYAAAPhDAGEYTQ+RXGBQABMAYGXoQwBmCE 0Pk1CAA2CABDShIAYUoSAG8oAREAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAAEA AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhKkBEYRX/hXGBQABqQEGXoSpAWCEV/4BAAAAAQAA AAAAAQMAAAAAAAAAAAAAAAAAAAAAABgAAA+E4AMRhMn9FcYFAAF5BAZehOADYITJ/QMAAAAuAAEA AQAAAAAAAQMFAAAAAAAAAAAAAAAAAAAAABgAAA+EigURhMn9FcYFAAGLBwZehIoFYITJ/QUAAAAu AAEALgACAAEAAAAAAAEDBQcAAAAAAAAAAAAAAAAAAAAYAAAPhMAHEYQ8/RXGBQABnAoGXoTAB2CE PP0HAAAALgABAC4AAgAuAAMAAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAAABgAAA+E9wkRhK78FcYF AAGtDQZehPcJYISu/AkAAAAuAAEALgACAC4AAwAuAAQAAQAAAAAAAQMFBwkLAAAAAAAAAAAAAAAA ABgAAA+EvAwRhJL7FcYFAAG+EAZehLwMYISS+wsAAAAuAAEALgACAC4AAwAuAAQALgAFAAEAAAAA AAEDBQcJCw0AAAAAAAAAAAAAAAAYAAAPhPMOEYQE+xXGBQABzxMGXoTzDmCEBPsNAAAALgABAC4A AgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAAABgAAA+EKhERhHb6FcYF AAHgFgZehCoRYIR2+g8AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAAAAAQMFBwkL DQ8RAAAAAAAAAAAAABgAAA+E7hMRhFz5FcYFAAHyGQZehO4TYIRc+REAAAAuAAEALgACAC4AAwAu AAQALgAFAC4ABgAuAAcALgAIAAAAAAAXAAAAAAAAAAAAAAAAAAAAAAAAABMQAAAPhNACEYSY/l6E 0AJghJj+T0oAAFBKBABRSgAAXkoAAG8oAAEALQABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPEAAA D4SgBRGEmP5ehKAFYISY/k9KAwBRSgMAXkoDAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAA AAALEAAAD4RwCBGEmP5ehHAIYISY/k9KBwBRSgcAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAA AAAAAAsQAAAPhEALEYSY/l6EQAtghJj+T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAA AAAAAAAADxAAAA+EEA4RhJj+XoQQDmCEmP5PSgMAUUoDAF5KAwBvKAABAG8AAQAAABeAAAAAAAAA AAAAAAAAAAAAAAAACxAAAA+E4BARhJj+XoTgEGCEmP5PSgcAUUoHAG8oAAEAp/ABAAAAF4AAAAAA AAAAAAAAAAAAAAAAAAALEAAAD4SwExGEmP5ehLATYISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAA AAAAAAAAAAAAAAAAAAAAAA8QAAAPhIAWEYSY/l6EgBZghJj+T0oDAFFKAwBeSgMAbygAAQBvAAEA AAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhFAZEYSY/l6EUBlghJj+T0oHAFFKBwBvKAABAKfw AAAAABcAAAAAAAAAAAAAAAAAAAAAAAAAExAAAA+E0AIRhJj+XoTQAmCEmP5PSgAAUEoEAFFKAABe SgAAbygAAQAtAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8QAAAPhKAFEYSY/l6EoAVghJj+T0oD AFFKAwBeSgMAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhHAIEYSY/l6EcAhg hJj+T0oHAFFKBwBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EQAsRhJj+XoRA C2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPEAAAD4QQDhGEmP5e hBAOYISY/k9KAwBRSgMAXkoDAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4Tg EBGEmP5ehOAQYISY/k9KBwBRSgcAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAP hLATEYSY/l6EsBNghJj+T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxAA AA+EgBYRhJj+XoSAFmCEmP5PSgMAUUoDAF5KAwBvKAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAA AAAACxAAAA+EUBkRhJj+XoRQGWCEmP5PSgcAUUoHAG8oAAEAp/ABAAAAAAABAAAAAAAAAAACAAAA AAAAAAAdEAAAD4TQAhGEAABehNACYIQAADUIADYIAENKJABPSgIAUEoFAFFKAgBhSiQAbygAAwAA ACAAIAABAAAAAAABAwAAAAAAAAACAAAAAAAAAAAZEAAAD4TQAhGEAABehNACYIQAADUIADYIAENK HgBPSgIAUUoCAGFKHgBvKAAFAAAALgABACAAIAABAAAAAAABAwUAAAAAAAACAAAAAAAAAAAZEAAA D4TQAhGEAABehNACYIQAADUIADYIAENKGABPSgIAUUoCAGFKGABvKAAHAAAALgABAC4AAgAgACAA AQAAAAAAAQMFBwAAAAAAAgAAAAAAAAAAGRAAAA+E0AIRhAAAXoTQAmCEAAA1CAA2CABDShUAT0oC AFFKAgBhShUAbygACQAAAC4AAQAuAAIALgADACAAIAABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAZ GAAAD4Q+BxGEyP4VxgUAAT4HBl6EPgdghMj+NQgANggAQ0oVAE9KAgBRSgIAYUoVAG8oAAIABAAu AAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAABkYAAAPhD4HEYTI/hXGBQABPgcGXoQ+B2CEyP41CAA2 CABDShUAT0oCAFFKAgBhShUAbygAAgAFACkAAQAAAAQAAQAAAAAAAAAAAAAAAAAAAAAAGRgAAA+E PgcRhMj+FcYFAAE+BwZehD4HYITI/jUIADYIAENKFQBPSgIAUUoCAGFKFQBvKAACAAYALgABAAAA AAkHAAAAAAAAAAABAAAAAAAAAAAdEAAAD4TQAhGEAABehNACYIQAADUIADYIAENKEgBPSgIAUEoF AFFKAgBhShIAbygABwBGAGkAZwB1AHIAZQAHAAEAAAAACQYAAAAAAAAAAAEAAAAAAAAAAB0QAAAP hNACEYQAAF6E0AJghAAANQgANggAQ0oSAE9KAgBQSgUAUUoCAGFKEgBvKAAGAFQAYQBiAGwAZQAI AAEAAAD/AAAAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhKkBEYRX/hXGBQABqQEGXoSpAWCEV/5vKAEE AESWVV9BACAAAQAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E4AMRhMn9FcYFAAHgAwZehOAD YITJ/W8oAQMAQQAuAAEAAQAAAAAAAQMFAAAAAAAAAAAAAAAAAAAAAxgAAA+EigURhMn9FcYFAAGK BQZehIoFYITJ/W8oAQUAAAAuAAEALgACAAEAAAAAAAEDBQcAAAAAAAAAAAAAAAAAAAMYAAAPhMAH EYQ8/RXGBQABwAcGXoTAB2CEPP1vKAEHAAAALgABAC4AAgAuAAMAAQAAAAAAAQMFBwkAAAAAAAAA AAAAAAAAAxgAAA+E9wkRhK78FcYFAAH3CQZehPcJYISu/G8oAQkAAAAuAAEALgACAC4AAwAuAAQA AQAAAAAAAQMFBwkLAAAAAAAAAAAAAAAAAxgAAA+EvAwRhJL7FcYFAAG8DAZehLwMYISS+28oAQsA AAAuAAEALgACAC4AAwAuAAQALgAFAAEAAAAAAAEDBQcJCw0AAAAAAAAAAAAAAAMYAAAPhPMOEYQE +xXGBQAB8w4GXoTzDmCEBPtvKAENAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMF BwkLDQ8AAAAAAAAAAAAAAxgAAA+EKhERhHb6FcYFAAEqEQZehCoRYIR2+m8oAQ8AAAAuAAEALgAC AC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAAAAAQMFBwkLDQ8RAAAAAAAAAAAAAxgAAA+E7hMRhFz5 FcYFAAHuEwZehO4TYIRc+W8oAREAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAAEA AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhKkBEYRX/hXGBQABqQEGXoSpAWCEV/4BAAAAAQAA AAAAAQMAAAAAAAAAAAAAAAAAAAAAABgAAA+E4AMRhMn9FcYFAAF5BAZehOADYITJ/QMAAAAuAAEA AQAAAAAAAQMFAAAAAAAAAAAAAAAAAAAAABgAAA+EigURhMn9FcYFAAGLBwZehIoFYITJ/QUAAAAu AAEALgACAAEAAAAAAAEDBQcAAAAAAAAAAAAAAAAAAAAYAAAPhMAHEYQ8/RXGBQABBAwGXoTAB2CE PP0HAAAALgABAC4AAgAuAAMAAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAAABgAAA+E9wkRhK78FcYF AAEVDwZehPcJYISu/AkAAAAuAAEALgACAC4AAwAuAAQAAQAAAAAAAQMFBwkLAAAAAAAAAAAAAAAA ABgAAA+EvAwRhJL7FcYFAAEmEgZehLwMYISS+wsAAAAuAAEALgACAC4AAwAuAAQALgAFAAEAAAAA AAEDBQcJCw0AAAAAAAAAAAAAAAAYAAAPhPMOEYQE+xXGBQABNxUGXoTzDmCEBPsNAAAALgABAC4A AgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAAABgAAA+EKhERhHb6FcYF AAFIGAZehCoRYIR2+g8AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAAAAAQMFBwkL DQ8RAAAAAAAAAAAAABgAAA+E7hMRhFz5FcYFAAFaGwZehO4TYIRc+REAAAAuAAEALgACAC4AAwAu AAQALgAFAC4ABgAuAAcALgAIAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhLABEYRQ/hXG BQABsAEGXoSwAWCEUP5vKAEBAAAAAQAAAAAAAQMAAAAAAAAAAAAAAAAAAAAAAxgAAA+EQAIRhMD9 FcYFAAFAAgZehEACYITA/W8oAQMAAAAuAAEAAQAAAAAAAQMFAAAAAAAAAAAAAAAAAAAAAxgAAA+E 0AIRhDD9FcYFAAHQAgZehNACYIQw/W8oAQUAAAAuAAEALgACAAEAAAAAAAEAAAAAAAAAAAAAAAAA AAAAAAMYAAAPhKgDEYRY/RXGBQABNwIGXoSoA2CEWP1vKAECAAMALgABAAAAAAABAAAAAAAAAAAA AAAAAAAAAAADGAAAD4SoAxGEWP0VxgUAATcCBl6EqANghFj9bygBAgAEAAn/AQAAAAQAAQAAAAAA AAAAAAAAAAAAAAAAAxgAAA+EqAMRhFj9FcYFAAE3AgZehKgDYIRY/W8oAQIABQAJ/wEAAAACAAEA AAAAAAAAAAAAAAAAAAAAAAMYAAAPhKgDEYRY/RXGBQABNwIGXoSoA2CEWP1vKAABAAYAAQAAAAAA AQMFBwkLDQ8AAAAAAAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg+m8oAQ8AAAAuAAEA LgACAC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAAAAAQMFBwkLDQ8RAAAAAAAAAAAAAxgAAA+EMAYR hND5FcYFAAEwBgZehDAGYITQ+W8oAREAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAI AAEAAAADAAMAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhLABEYRQ/hXGBQABsAEGXoSwAWCEUP5vKAED AESWVV8AAAEAAAAAAAEDAAAAAAAAAAAAAAAAAAAAAAMYAAAPhEACEYTA/RXGBQABQAIGXoRAAmCE wP1vKAEDAAAALgABAAEAAAAAAAEDBQAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw/RXGBQAB0AIG XoTQAmCEMP1vKAEFAAAALgABAC4AAgABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4SoAxGE WP0VxgUAATcCBl6EqANghFj9bygBAgADAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+E qAMRhFj9FcYFAAE3AgZehKgDYIRY/W8oAQIABAAJ/wEAAAAEAAEAAAAAAAAAAAAAAAAAAAAAAAMY AAAPhKgDEYRY/RXGBQABNwIGXoSoA2CEWP1vKAECAAUACf8BAAAAAgABAAAAAAAAAAAAAAAAAAAA AAADGAAAD4SoAxGEWP0VxgUAATcCBl6EqANghFj9bygAAQAGAAEAAAAAAAEDBQcJCw0PAAAAAAAA AAAAAAMYAAAPhKAFEYRg+hXGBQABoAUGXoSgBWCEYPpvKAEPAAAALgABAC4AAgAuAAMALgAEAC4A BQAuAAYALgAHAAEAAAAAAAEDBQcJCw0PEQAAAAAAAAAAAAMYAAAPhDAGEYTQ+RXGBQABMAYGXoQw BmCE0PlvKAERAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAABAAAA/wAAAAAAAAAA AAAAAAAAAAAAAAADGAAAD4SpARGEV/4VxgUAAakBBl6EqQFghFf+bygBBABEllVfQQAgAAEAAAAA AAMAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhOADEYTJ/RXGBQAB4AMGXoTgA2CEyf1vKAEDAEEALgAB AAEAAAAAAAEEBgAAAAAAAAAAAAAAAAAAAAMYAAAPhIoFEYTJ/RXGBQABigUGXoSKBWCEyf1vKAEG AAAAQQAuAAEALgACAAEAAAAAAAEDBQcAAAAAAAAAAAAAAAAAAAMYAAAPhMAHEYQ8/RXGBQABwAcG XoTAB2CEPP1vKAEHAAAALgABAC4AAgAuAAMAAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAAAxgAAA+E 9wkRhK78FcYFAAH3CQZehPcJYISu/G8oAQkAAAAuAAEALgACAC4AAwAuAAQAAQAAAAAAAQMFBwkL AAAAAAAAAAAAAAAAAxgAAA+EvAwRhJL7FcYFAAG8DAZehLwMYISS+28oAQsAAAAuAAEALgACAC4A AwAuAAQALgAFAAEAAAAAAAEDBQcJCw0AAAAAAAAAAAAAAAMYAAAPhPMOEYQE+xXGBQAB8w4GXoTz DmCEBPtvKAENAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAA AAAAAxgAAA+EKhERhHb6FcYFAAEqEQZehCoRYIR2+m8oAQ8AAAAuAAEALgACAC4AAwAuAAQALgAF AC4ABgAuAAcAAQAAAAAAAQMFBwkLDQ8RAAAAAAAAAAAAAxgAAA+E7hMRhFz5FcYFAAHuEwZehO4T YIRc+W8oAREAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIACcAAABqfjRyAAAAAAAA AAAAAAAAan40cgAAAAAAAAAAAAAAAGp+NHIAAAAAAAAAAAAAAAAKV/5CAAAAAAAAAAAAAAAAClf+ QgAAAAAAAAAAAAAAAGp+NHIAAAAAAAAAAAAAAABqfjRyAAAAAAAAAAAAAAAAan40cgAAAAAAAAAA AAAAAGp+NHIAAAAAAAAAAAAAAADwPkUgAAAAAAAAAAAAAAAA8D5FIAAAAAAAAAAAAAAAAPA+RSAA AAAAAAAAAAAAAABAZQAyAAAAAAAAAAAAAAAAHnkrOAAAAAAAAAAAAAAAACN3PQoAAAAAAAAAAAAA AACqIcgwAAAAAAAAAAAAAAAA2FVBUgAAAAAAAAAAAAAAANhVQVIAAAAAAAAAAAAAAADYVUFSAAAA AAAAAAAAAAAADjsOfgAAAAAAAAAAAAAAAA47Dn4AAAAAAAAAAAAAAAAOOw5+AAAAAAAAAAAAAAAA DjsOfgAAAAAAAAAAAAAAANhVQVIAAAAAAAAAAAAAAADYVUFSAAAAAAAAAAAAAAAADjsOfgAAAAAA AAAAAAAAAA47Dn4AAAAAAAAAAAAAAAAOOw5+AAAAAAAAAAAAAAAA8FBsCwAAAAAAAAAAAAAAANhV QVIAAAAAAAAAAAAAAADYVUFSAAAAAAAAAAAAAAAADjsOfgAAAAAAAAAAAAAAAClkVGMAAAAAAAAA AAAAAAApZFRjAAAAAAAAAAAAAAAAKWRUYwAAAAAAAAAAAAAAAIhonSsAAAAAAAAAAAAAAAB5CPxU AAAAAAAAAAAAAAAA9FtLPwAAAAAAAAAAAAAAAOVP5DgAAAAAAAAAAAAAAAD///////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////w8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAABIAutVmuwMACQQFAAkEAQAJBAMACQQFAAkEAQAJ BAMACQQFAAkEEgDclwABAwAJBAUACQQBAAkEAwAJBAUACQQBAAkEAwAJBAUACQQAAAAAAAAAAAAA AAABABR+63IAAAAAAAAAAAABAgACAJoAAAAEAAAACAAAAOUAAAAAAAAAAgAAAHNOAwBrMwcAFAsI APA6CwASTgsAgBsOAAIvDgDbWA4AnRoPAGV8DwBBbRQAZWUWAM81FwDzbxcAInwXAFIlGQBNJhkA zzwaANNnGgAWDhsAuGUcALcZHQAxCyUAYkYlAJUnJgDacCYAzlUnAIMRKADNCS8AYEwvADtYLwB3 eDQAD3s0AKd8NgBuLTcApBY4AM81OAByRDgAj0U4AB0yOQDwIkAAXCRCAC8/QgBQX0IAeB9DALYB RAD/MUQAfQxGAHpORwDCfEsA4zdMAENMTQC2TFgAvglaAAkAWwDVLVsAt1BcALRbXABSOl4AwXBg AHR0YACneGAA2ABkAJgQZQArFmYAGDBmAN9DZwBJHmgAzD5oAJRsaABVdWoAfxdvAGMXcACJenIA ngZ0ADRLdgBhZXYAWTd5AOxDegAdUHsAqg1/AK8zgADIOIAARAqBAAA6gwDfeIcAyymMAE1okADi FZEAIHmSADl2lAA3EpUALxiVAFwElgCJMpYASAKXAJ0kmwBVPp4ASAqgAFcZowCnQ6MAET+mAGpA pwDMFagAJjOpAKEKrQAyKK8Ak2mvAO4IsgAuN7MAigK5ALYlvwAtdsAA+QLCAK4lwgBKCMMALRjE AJYZxgCKOcoAtB7LANRRzQBPZtEAZCrSAJpm0gDBBNMArwfVALNu1gDSRtsAwFXbAME+3AD8Ft4A NTngAEo84QBZP+EAB03hADhR4wB6UeMATALkACQh5AAHd+UAkhfmAAJa5wAhU+gAYgPpAAIG7gDV HO8A2QfwAGV49QAmBfcAUB33AGA2+ABNffkAFm76ACMO/AAAAAAADz0AABE9AAAAAAAAAQAAAP9A AhAAAAAAAAAAsz0AAGgAABAAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAAAAAAAAAA AAD//wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAkAAABHHpABAAACAgYDBQQFAgME/yoA 4EF4AMAJAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1HpAB AgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzLpABAAAC CwYEAgICAgIE/yoA4EN4AMAJAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAPz2QAQAAAgcDCQIC BQIEBP8qAOBDeADACQAAAAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAADsOkAGG BwIBBgADAQEBAQEDAAAAAACPKBYAAAAAAAAAAQAEAAAAAABTAGkAbQBTAHUAbgAAAItbU08AADs9 kAGGBwIBBgkGAQEBAQG/AgCA+nzPOBYAAAAAAAAAAQAEAAAAAABTAGkAbQBIAGUAaQAAANGeU08A AEE9kAGGAAAAAAAAAAAAAAC/AgCA+nzPOBYAAAAAAAAAAQAEAAAAAABLAGEAaQBUAGkAXwBHAEIA MgAzADEAMgAAADsOkAECAAUAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBn AGQAaQBuAGcAcwAAAEEekAEAAAIEBQMFBAYDAgT/AgDg/yQAQgAAAAAAAAAAnwEAAAAAAABDAGEA bQBiAHIAaQBhACAATQBhAHQAaAAAACIABAAxCIgYAACkAQAAaAEAAAAAUJQoJ1CUKCcAAAAAAgAA AAAAHAkAAPMzAAAMAB8AAAAEAAMQbgAAABwJAADzMwAADAAfAAAAbgAAAAAAAAAhAwAAAAAAAAMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACKBaAFtACcAIKAEgAAAAAAAAAAAAAAAAAAAPA8AADwPAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAgAAAAAAAAAAAAQygxEAAAAAAAD8/QEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAISFgAAAAA CfD/DwAJAT8AAOQEAAD///9/////fwwAAAD///9/////f////3////9/t1BcAAAEAAAyAAAAAAAA AAAAAAAAAAAAAAAAAAAAIQQAAAAAAAAAAAAAAAAAAAAAAAAQHAAACAAAAAAAAAAAAHgAAAB4AAAA AAAAAAAAAACgBQAA//8SAAAAAAAAAAAAAAAAAAAACQBoADAAMAAyADgAMwA2ADcAOQAJAGgAMAAw ADIAOAAzADYANwA5AAAAAAAAAAAAAAAAAAAAAAAAAAAASAAAAAYAAAAPAAAAAAAMAAEADAACAAwA AwAMAAQADAAFAAwABgAMAAcADAAIAAwACQAMAAoADAALAAwADAAMAA0ADAAOAAwAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAA BgECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAAAkAQAADQAAAAEAAABw AAAABAAAAHgAAAAHAAAAjAAAAAgAAACgAAAACQAAALQAAAASAAAAwAAAAAoAAADgAAAADAAAAOwA AAANAAAA+AAAAA4AAAAEAQAADwAAAAwBAAAQAAAAFAEAABMAAAAcAQAAAgAAAOQEAAAeAAAADAAA AGgwMDI4MzY3OQAAAB4AAAAMAAAATm9ybWFsLmRvdG0AHgAAAAwAAABoMDAyODM2NzkAAAAeAAAA BAAAADIAAAAeAAAAGAAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZAAAAEAAAAAAAAAAAAAAAEAAAAAA +EFR97rPAUAAAAAA+EFR97rPAQMAAAAMAAAAAwAAABwJAAADAAAA8zMAAAMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAB0AFkAQwA0AHcA KwBzAFMAMgA4AE4AYwBLAEoAaABLADQALwBzAHUAeABDAHIANgBRAFoAWgBuAGEAMgBBADYASwBC AE0AdAA1AFcAdQBKAFUATABsAFkAegBtAFUAZQBaAEgAQgA0ADEATgB0ADYAcQBRAHIANwBxAHoA MwArAHcAQwBhADQAUAB2AA0ACgBFADMANgBHAHgARQBSAGoAUgBKAFcAOABRAEgAYQByAFUAMgBa AEMAMQA0AE0AMQBZAHQAbABuAHoAMQBJAHIASwA1ADYAKwBWAFMAYwB2ACsAdgA2AGQARgB2AHUA LwB0AHoAeQAwAGwAWAA5ADQASQB6AHcAaQBTADgAegBDAHgAUwBPAEsAUwBlAE8AMwANAAoAdQBj AFgAaABrADAAWgA4AFUAbABPADQAUQAzAGYAYwBiAEwAUQBGAGkARgBvAFUAawBhAGcAVABxAGQA bAArAHkAZABLAEoAbQBuAEoAUQBpAGIAagBKAFQAMgBvAEwASwB6AGEAdgBEAFIAUgAzAGUAVABy AHkATQB2ACsANQBRAEwATQA5ADMAcgBsAHcADQAKAC8AWgB3AG8AagBXAEMAOABvADQAQgBjAFYA VABOAFoARgBwAAAAHgAAABIAAABfbmV3X21zX3BJRF83MjU0MwAAAB8AAADxAAAAVABTADAAVQAz AFcAZgBqAHkANAA5AFkAZwBjAEMANwA5AHkANABPAHgAQgBiAHoALwBLADkAdQBtAEEAQgBTAGUA WQAyAG0AcQBRAFcAUgA0AE4AbwBQAGsAVwBKADYARAB2AEcAOABpAE8ADQAKADQASQB6AGgAOAAr AEIAWQB2AGIARgBnAE0AQgBxAFYAVAA4AFcAYgBrAHkAcABmAEQASQBOAEYAdgA5ADEAcgBFAEIA cwBFAHAAdQA1AEUAUwBCAE4AYQBDAGIATAB1AFAARwBVAGkAbgA2ACsANwAxAEwANgBjAGYAMAB3 AEQATgBKAGUAVQBjAGQAYQBrAA0ACgBNAEQAVAByAHAAUABFADcAUABCAG0AaAArAEsANABnAFAA MgA1AHUAcgBpAGkARwBFAEcAUgAyAG4AQQA2AG0AMABjAFkAOABNADkAeABMAE0AcABaAEsAVAA0 AHEANAA2AFcAZgBMADEASABoAEwARgAxAEsASwAzAFUATgBHAGwANwBPAGkANgA3AHUARgANAAoA cAArADEANQBqAGgAbAAyAHgAMgBWAFMAeABVAEwAdwBQAEoALwBuAEcAYQBBAHkAMAAxAHEAZQAw ADAAZQBOAC8AcQBEAGQAAAAAAB4AAAATAAAAX25ld19tc19wSURfNzI1NDMxAAAfAAAARwAAAG4A QwBEAEIARQBhAE0AbgBWAFEARAA3AGUAcgBMAHAAVwAyAFoAeABmAHEARwBQAGMANQA1AFYAYgBE AHcAagByAHkAYQBwAA0ACgBwAFcATgB4ADcAOABoAGMANQBZADcAeQBLAHIAQwAvAGMATgBKAGQA dgBBAGwAVwAvAGsAegBmAHgAUQA9AD0AAAAAAB4AAAATAAAAX25ld19tc19wSURfNzI1NDMyAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAA BgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAU AAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIA AAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAA ADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAP7///8+AAAA PwAAAEAAAABBAAAAQgAAAEMAAABEAAAA/v///0YAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABN AAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAFsA AABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAA AGoAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAA/v///3YAAAB3AAAA eAAAAHkAAAB6AAAAewAAAHwAAAD+////fgAAAH8AAAD+///////////////////////////////9 /////f///4gAAACJAAAAjQAAAP7///+MAAAAjgAAAP7///99AAAA//////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAA AAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAADQ98Rs97rPAYsAAADACgAAAAAAAEQAYQB0AGEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAK AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPQAAAAAQ AAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA4AAgABAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABFAAAAUF8AAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQoAAAAFAAAA/////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4eAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBv AHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIA//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdQAAAAAQAAAAAAAABQBEAG8AYwB1 AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgA AgEMAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAAAOAcA AAAAAABNAHMAbwBEAGEAdABhAFMAdABvAHIAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAGgABAP//////////BwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsErLave6zwEA YdNq97rPAQAAAAAAAAAAAAAAAMYA2QBRAMAAMwDDAFgAxgBaAFUA1gDAAEsA2gBSAMMA3wBTAN8A WgDNANAAPQA9AAAAAAAAAAAAAAAAAAAAAAAyAAEB//////////8IAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACwSstq97rPAQBh02r3us8BAAAAAAAAAAAAAAAASQB0AGUAbQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH/////CQAAAP////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5gAAAAAAAABQAHIAbwBwAGUA cgB0AGkAZQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAC AP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAABVAQAA AAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAASAAIBAgAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAACgAAAHkAAAAAAAAASQByAG0AVABvAG8AbABJAG4AZgBvAFMAdAByAGUAYQBtAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAgD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAABAAAAAgAAAAMAAAD+////BQAAAAYAAAAH AAAACAAAAAkAAAD+////CwAAAP7////+/////v///w8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUA AAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAA ACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAD+//////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////zxiOlNvdXJjZXMgU2VsZWN0ZWRTdHlsZT0i XEFQQS5YU0wiIFN0eWxlTmFtZT0iQVBBIEZpZnRoIEVkaXRpb24iIHhtbG5zOmI9Imh0dHA6Ly9z Y2hlbWFzLm9wZW54bWxmb3JtYXRzLm9yZy9vZmZpY2VEb2N1bWVudC8yMDA2L2JpYmxpb2dyYXBo eSIgeG1sbnM9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9yZy9vZmZpY2VEb2N1bWVu dC8yMDA2L2JpYmxpb2dyYXBoeSI+PC9iOlNvdXJjZXM+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCIgc3RhbmRhbG9uZT0ibm8iPz4N CjxkczpkYXRhc3RvcmVJdGVtIGRzOml0ZW1JRD0iezc2MjA5NDlCLUU2MzUtNEQ2NS1BMDJCLUE0 NjNGRDJGRDlCN30iIHhtbG5zOmRzPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcv b2ZmaWNlRG9jdW1lbnQvMjAwNi9jdXN0b21YbWwiPjxkczpzY2hlbWFSZWZzPjxkczpzY2hlbWFS ZWYgZHM6dXJpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvb2ZmaWNlRG9jdW1l bnQvMjAwNi9iaWJsaW9ncmFwaHkiLz48L2RzOnNjaGVtYVJlZnM+PC9kczpkYXRhc3RvcmVJdGVt PgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAP7/AwoAAP////8G CQIAAAAAAMAAAAAAAABGJwAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZCA5Ny0yMDAzIERvY3VtZW50 AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAA AMgbMgEMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADIGzIBEAAAAAAAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA/v8AAAYBAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss +a5EAAAABdXN1ZwuGxCTlwgAKyz5rkgBAAAEAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAmAAA AAYAAACgAAAAEQAAAKgAAAAXAAAAsAAAAAsAAABJAHIAbQBUAG8AbwBsAFMATABlAHYAZQBsAEkA bgBmAG8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAACAQsAAAAEAAAA/////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALgAAAAQAAAAwAAAABMAAADIAAAAFgAAANAAAAAN AAAA2AAAAAwAAADlAAAAAgAAAOQEAAAeAAAAIAAAAEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLEx0 ZC4AAAAAAwAAAG4AAAADAAAAHwAAAAMAAADwPAAAAwAAAAAADAALAAAAAAAAAAsAAAAAAAAACwAA AAAAAAALAAAAAAAAAB4QAAABAAAAAQAAAAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAA 8AUAAAkAAAAAAAAAUAAAAAEAAAAMAQAAAgAAABQBAAADAAAAKAEAAAQAAAAYAwAABQAAADQDAAAG AAAAIAUAAAcAAAA8BQAACAAAANQFAAAHAAAAAgAAAAYAAABzZmxhZwADAAAAEgAAAF9uZXdfbXNf cElEXzcyNTQzAAQAAAAVAAAAX25ld19tc19wSURfNzI1NDNfMDAABQAAABMAAABfbmV3X21zX3BJ RF83MjU0MzEABgAAABYAAABfbmV3X21zX3BJRF83MjU0MzFfMDAABwAAABMAAABfbmV3X21zX3BJ RF83MjU0MzIACAAAABYAAABfbmV3X21zX3BJRF83MjU0MzJfMDAAAAIAAADkBAAAHgAAAAwAAAAx NDA4MzUxMzE5AAAfAAAA9AAAACgAMwApAG4A --_002_814D0BFB77D95844A01CA29B44CBF8A7A27C16lhreml513mbbchina_-- From nobody Mon Aug 18 08:45:02 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A657A1A0667; Mon, 18 Aug 2014 08:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7raf2CFhDhP7; Mon, 18 Aug 2014 08:44:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB4181A064D; Mon, 18 Aug 2014 08:44:57 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D5BCD2AB2B7; Mon, 18 Aug 2014 15:44:56 +0000 (UTC) Date: Mon, 18 Aug 2014 15:44:56 +0000 From: Viktor Dukhovni To: ietf@ietf.org, saag@ietf.org Message-ID: <20140818154456.GO14392@mournblade.imrryr.org> References: <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Dmtf80_Ri9CWdzxqn9BiBEzEyT8 Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 15:45:00 -0000 On Mon, Aug 18, 2014 at 12:20:41AM -0400, Benjamin Kaduk wrote: > "if you can > use DANE as a trust anchor, attempt to do so, but fall back if there is no > record" [ Just want to add a possibly useful terminology improvement in light of the draft. ] Note, I'd like to promote the view that not negotiating a stronger mechanism is not fallback. In the next (2.12) Postfix development snapshot or so, while opportunistic DANE TLS still employs DANE when TLSA records are present and not otherwise, one can also specify a "fallback" TLS security level of "encrypt" or "may", which is used when DANE TLSA records are present, but authentication fails! This is effectively an "audit" mode of authentication enforcement, where mail is delivered even if authentication fails (possibly even in the clear with "may"), but warning are logged, making MiTM at least tamper-evident for those who enable this and don't just ignore the logs. Sending sites concerned with the potential impact of enabling opportunistic DANE TLS on mail delivery can initially turn it on in "audit-mode". So I'd like to think of "fallback" as the kind of noisy "your security is degraded, here's a dialogue to say it's OK" mess that we're currently in when not able to create a suitably secure channel. With opportunistic security, when the peer does not advertise support for some mechanism, and as a result that mechanism is not employed, there is no fuss, the peers operate closer to the baseline security level. [ Note, there is no specific recommendation to use DANE in the draft. This is deliberate, I wanted to avoid giving mechanism-specific advice. Be it at the cost of greater abstraction. ] The text about DANE in the draft, carefully suggests that it is but one of many possibilities. Opportunistic security protocols should provide a means to enforce authentication for those peers for which authentication can be expected to succeed based on information advertised by the peer via DANE, TOFU or other means. With DANE, the advertisement that a peer supports authentication is downgrade-resistant. What is "opportunistic" here is the selective use of authentication for certain peers; much in the same way as unauthenticated encrypted communication may be used "opportunistically" with peers capable of more than cleartext. Enforcement of authentication is not incompatible with opportunistic security. If an OS-enabled peer (A) makes available authentication key material, e.g., via DANE, to peer (B), then B should make use of this material to authenticate A, if B is OS-enabled and supports DANE. Of course at this time only DANE provides (for as yet too few domains) an authenticated channel with authenticated denial of existence for publishing peer authentication material. So I cannot offer practical examples of this with a different underlying technology. -- Viktor. From nobody Mon Aug 18 09:07:28 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516701A0683 for ; Mon, 18 Aug 2014 09:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWhHsafWn1BT for ; Mon, 18 Aug 2014 09:07:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5FA1A0677 for ; Mon, 18 Aug 2014 09:07:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIJ35594; Mon, 18 Aug 2014 16:07:23 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.03.0158.001; Mon, 18 Aug 2014 17:07:20 +0100 From: Hosnieh Rafiee To: "saag@ietf.org" Thread-Topic: secauth requirements and usecase scenarios - link Thread-Index: AQHPuv584P45jsJxaU+nnTxty7+lYQ== Date: Mon, 18 Aug 2014 16:07:19 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A27C5E@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/saag/36X-bH_zCm2UsTotv0h84KXaUhE Subject: [saag] secauth requirements and usecase scenarios - link X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 16:07:26 -0000 Follow up, This is also a link to where you can find the document < http://editor.rozanak.com/show.aspx?u=3DAZ6AA4BFD809BB71B2544CTAM > Best, Hosnieh From nobody Mon Aug 18 09:40:02 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38CC1A06DC for ; Mon, 18 Aug 2014 09:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7siwUAFjx2I7 for ; Mon, 18 Aug 2014 09:39:59 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056EB1A06CC for ; Mon, 18 Aug 2014 09:39:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E7CCD2AB2B7; Mon, 18 Aug 2014 16:39:57 +0000 (UTC) Date: Mon, 18 Aug 2014 16:39:57 +0000 From: Viktor Dukhovni To: "saag@ietf.org" Message-ID: <20140818163957.GP14392@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A27C5E@lhreml513-mbb.china.huawei.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_mvsrUdxH_jUR4Oq5btA3_UivaQ Subject: Re: [saag] secauth requirements and usecase scenarios - link X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 16:40:00 -0000 On Mon, Aug 18, 2014 at 04:07:19PM +0000, Hosnieh Rafiee wrote: > This is also a link to where you can find the document > http://editor.rozanak.com/show.aspx?u=AZ6AA4BFD809BB71B2544CTAM On Mon, Aug 18, 2014 at 03:41:33PM +0000, Hosnieh Rafiee wrote: > Just in case you are not aware of the activities of this secauth group. > < https://www.ietf.org/mailman/listinfo/secauth > > I haven't yet submitted this document to IETF but would like to receive some comments before to do so. Quick note on wording, what a user or device gets from a CA (i.e. a "certification authority") is a "certificate". Somehow you've reversed these, so that in the draft "ceritificate authorities" (not correct, though not entirely uncommon) issue "certifications" (definitely not correct). In terms of content, it seems as yet unclear where this draft is going based on the current outline. You might want to read draft-dukhovni-opportunistic-security and RFC6698 depending on where you're heading with this. Is the intent to provide an API for application-level awareness/control of network-layer security services? This document addresses the following problems: - self certification and avoiding identity spoofing of a node (for example, a self certified mail server) - Secure authentication - Privacy and data confidentiality - authentication of devices in case of proxy servers - etc. Therefore, the purpose of this document is to define the problem statement and identifies the requirements for a robust easy secure authentication and authorization of nodes using a combination of network layer and application layer security approaches. ... 4. Requirements This section defines the scope of this document and introduces the requirement of an API for this protocol. Still not clear where this is going... -- Viktor. From nobody Mon Aug 18 14:18:03 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140981A6F99; Mon, 18 Aug 2014 14:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpUN_5f1kVRW; Mon, 18 Aug 2014 14:17:58 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62921A6F7A; Mon, 18 Aug 2014 14:17:57 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38652 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XJUJQ-0002dI-HC; Mon, 18 Aug 2014 17:17:56 -0400 Message-ID: <53F26D85.1070703@bbn.com> Date: Mon, 18 Aug 2014 17:17:57 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ietf@ietf.org, saag References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <20140815221806.GA5476@mournblade.imrryr.org> In-Reply-To: <20140815221806.GA5476@mournblade.imrryr.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/jlaajqf-j69bgw-li38Dy0O4T58 Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 21:18:00 -0000 Viktor, > ... > > My response was -03. If you're just resending the comments for > stale versions of the work in progress, I can't really make use of > those I'm afraid. They've already been processed and taken seriously. You ignored/rejected detailed suggestions that would, IMHO, significantly improve the text. Thus most of my comments are still applicable. I'll go through the exercise of reviewing the posted -03 version, and providing feedback, again, late this week. Steve From nobody Mon Aug 18 14:18:25 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50D81A6FAE; Mon, 18 Aug 2014 14:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fxiCzUMFlWY; Mon, 18 Aug 2014 14:18:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612D11A6FA9; Mon, 18 Aug 2014 14:18:05 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:60825 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XJUJj-0006qY-HW; Mon, 18 Aug 2014 17:18:15 -0400 Message-ID: <53F26D8A.1050304@bbn.com> Date: Mon, 18 Aug 2014 17:18:02 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nico Williams References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> In-Reply-To: <20140816200706.GA8110@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FrLsYXBzROY3A3NMFYWOKC7iLJo Cc: ietf@ietf.org, saag Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 21:18:21 -0000 Nico, > ... > Bikeshedding is what this is. > > I'm under no illusions as to having a single dictionary of terminology > in such a large group. In fact, I've no patience for these games; I > recall vividly Stephen Kent trying to school me as to the meaning of > "network authentication", whereupon I had to point him to the very TITLE > of RFC1510 (fun times). I recall spending a lot of effort trying to transform your BTNS text into something useful. I'm generally pleased with the results (vs. what I started with) in terms of the text. I'm sorry to see that the effort was not so successful wrt engendering good writing habits. > It's true that terminology matters, don't get me wrong, but you're > demanding a level of conflict-free terminology that is infeasible, while > at the same time failing to convince anyone that there's a problem here. > Really, "protocol design pattern" is problematic?! yes, it is. it's yet another example where Viktor has chosen to needlessly create a new term, which engenders confusion. When trying to convey new concepts to an audience it's a good idea to use existing terminology whenever possible. This doc is a poster boy for failing in that regard. > The question is not "can you find some past usage of this or that term > that you can use to nitpick?". The question is: is the I-D clear? That's an easy question to answer: NO, it is not clear. > IMO: the I-D is quite clear. Serious arguments otherwise would be nice; > text nice still. Read my comments to Viktor. They provide specific suggestions on how to change the text. The problems are so widespread, and Vicktor has been so unwilling to make changes, that, short of re-writing it for him, I don't see how to fix this mess. > Another question, even more important, is whether OS (the proposed > protocol design pattern, not the term) is on the right path or whether > it is dangerous, or how to improve it. I've yet to see anargument that > Viktor's OS proposal is weak tea, dangerous, or could be improved, only > lots and lots of verbiage about verbiage. In fact, Viktor's prose is needlessly verbose in many places. I provided some examples of how to simplify it. This doc can be much better, and not longer, if it were rewritten to be clear. Steve From nobody Mon Aug 18 14:18:26 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A283F1A6FA1; Mon, 18 Aug 2014 14:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKNoNNXWQ1Rn; Mon, 18 Aug 2014 14:18:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D0D1A6FAA; Mon, 18 Aug 2014 14:18:06 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38654 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XJUJZ-0002da-OJ; Mon, 18 Aug 2014 17:18:05 -0400 Message-ID: <53F26D8F.2080209@bbn.com> Date: Mon, 18 Aug 2014 17:18:07 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ietf@ietf.org, saag References: <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <53EE7214.6010206@qti.qualcomm.com> <53EE9560.9000009@dcrocker.net> <53EE981E.4010504@cs.tcd.ie> <53EE99F3.80809@dcrocker.net> <53EEA229.2080408@cs.tcd.ie> <17924.1408218266@sandelman.ca> <20140816202207.GD8110@localhost> In-Reply-To: <20140816202207.GD8110@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/d4vTWWTDmAC404fDax_KxDHv4Kw Subject: Re: [saag] Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 21:18:22 -0000 Nico, > On Sat, Aug 16, 2014 at 03:44:26PM -0400, Michael Richardson wrote: >> (I think we are boiling the ocean on this document. Publish it) let's not. The doc is very poorly written. It has internal consistency problems, is haphazard in its organization, sloppy in choices of wording, ... > This. > > Either folks find a bug in the concept/text, they propose new text, or > they accept it. So far I see lots of bikeshedding. I have provided concrete suggestions, almost all of which have been ignored. Pride of authorship seems to be getting in the way here. Steve From nobody Mon Aug 18 14:25:54 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7E71A6FA6 for ; Mon, 18 Aug 2014 14:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PS92O2kQv-kp for ; Mon, 18 Aug 2014 14:25:50 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76C91A6F9E for ; Mon, 18 Aug 2014 14:25:49 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id ADC065660137 for ; Mon, 18 Aug 2014 21:25:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDBlbYtq5O_3 for ; Mon, 18 Aug 2014 23:25:17 +0200 (CEST) Received: from kopoli (p5DCC776E.dip0.t-ipconnect.de [93.204.119.110]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 4846F5660136 for ; Mon, 18 Aug 2014 23:25:17 +0200 (CEST) From: "Hosnieh Rafiee" To: References: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A27C5E@lhreml513-mbb.china.huawei.com> <20140818163957.GP14392@mournblade.imrryr.org> In-Reply-To: <20140818163957.GP14392@mournblade.imrryr.org> Date: Mon, 18 Aug 2014 23:25:14 +0200 Message-ID: <006101cfbb2a$e7a6c2c0$b6f44840$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIL9Z4VkYfzQNcTtf996vCIRel8O5teNZ7Q Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/saag/5Pa6LsF0Pca0hI-dfY8P8houhyY Subject: Re: [saag] secauth requirements and usecase scenarios - link X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 21:25:52 -0000 Hi Viktor, Thanks a lot for your comments. Please see my responses inline. > > This is also a link to where you can find the document > > http://editor.rozanak.com/show.aspx?u=AZ6AA4BFD809BB71B2544CTAM > > Just in case you are not aware of the activities of this secauth group. > > < https://www.ietf.org/mailman/listinfo/secauth > I haven't yet > > submitted this document to IETF but would like to receive some comments > before to do so. > > Quick note on wording, what a user or device gets from a CA (i.e. > a "certification authority") is a "certificate". Somehow you've reversed these, > so that in the draft "ceritificate authorities" > (not correct, though not entirely uncommon) issue "certifications" > (definitely not correct). I changed it. I always used the abbreviation. I heard both but I wasn't sure which one to use. It appears that Wikipedia also used both.... < http://en.wikipedia.org/wiki/Certificate_authority > > In terms of content, it seems as yet unclear where this draft is going based on > the current outline. This draft is related to the requirements for an authentication and authorization API (it might be later a protocol but at the moment the focus is on API). We want to use the network layer security approaches and make it available to other layers for a robust authentication. This is because network layer knows about the IP information. Many attacks are initiated on applications using network layer. This is true that there are also some application layer attacks that network layer cannot help to detect them. Such as cross scripting attacks. This is why the aim of this API to provide a means of network layer security and let the application to use this approach easily without the need to have information about node's IP. Of course, there are other purposes here as well like privacy, automation, and try to have this security without the use of any public CA. The reasons are written in the draft. The purpose is to be able to use this approach for authentication of two devices and also a user to device. > You might want to read draft-dukhovni-opportunistic-security and > RFC6698 depending on where you're heading with this. Today before I start finishing this requirement, I was reading this draft. About the RFC, I have read it some time ago. I cannot exactly remember the detail but there are some differences with the approach planned for this API and their approaches. This API might be one of the options for authentication as explained in opportunistic-security. Because the aim is to simplify authentication and authorization processes as much as possible and to be able to support different nodes with different resources. The aim is also automation. This is why the goal is the use of less infrastructure (ideally no infrastructure) to support such API. > Is the intent to provide an API for application-level awareness/control of > network-layer security services? Not exactly, no application is supposed to control network layer but only access to it (a transparent intermediate interface between network layer and application layer) > This document addresses the following problems: > > - self certification and avoiding identity spoofing of a node (for > example, a self certified mail server) > > - Secure authentication > > - Privacy and data confidentiality > > - authentication of devices in case of proxy servers > > - etc. > > Therefore, the purpose of this document is to define the problem > statement and identifies the requirements for a robust easy secure > authentication and authorization of nodes using a combination of > network layer and application layer security approaches. > > ... > > 4. Requirements > > This section defines the scope of this document and introduces the > requirement of an API for this protocol. > At the moment it is only API not protocol. It was typing mistake... I removed it. Thanks again, Best, Hosnieh From nobody Mon Aug 18 14:30:19 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEF81A6F97; Mon, 18 Aug 2014 14:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTTwVuWQaBWF; Mon, 18 Aug 2014 14:30:16 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1BE1A6F7A; Mon, 18 Aug 2014 14:30:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E7BE5BE47; Mon, 18 Aug 2014 22:30:14 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovWgXigplxfl; Mon, 18 Aug 2014 22:30:14 +0100 (IST) Received: from [10.87.48.11] (unknown [86.42.20.223]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EF61DBE20; Mon, 18 Aug 2014 22:30:13 +0100 (IST) Message-ID: <53F27065.9030902@cs.tcd.ie> Date: Mon, 18 Aug 2014 22:30:13 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Stephen Kent References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> <53F26D8A.1050304@bbn.com> In-Reply-To: <53F26D8A.1050304@bbn.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/qoDqStT4i_n10dJ7C3FPgQZEvCw Cc: ietf@ietf.org, saag Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 21:30:18 -0000 Steve, On 18/08/14 22:18, Stephen Kent wrote: > short of re-writing it for him, I don't > see how to fix this mess. I think that's going too far and is disrespectful to Viktor and to those others who have expressed support for the document. That's especially egregious given that you haven't even bothered to compare -03 to the earlier on-list discussion. Please provide a detailed description of how -03 does or does not map to the earlier mailing list discussion. S. From nobody Mon Aug 18 14:39:47 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352081A701B; Mon, 18 Aug 2014 14:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgmDezKv75Ud; Mon, 18 Aug 2014 14:39:40 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BA891A701A; Mon, 18 Aug 2014 14:39:40 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7ILdP9O002597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Aug 2014 14:39:28 -0700 Message-ID: <53F271F8.5020508@dcrocker.net> Date: Mon, 18 Aug 2014 14:36:56 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> <53F26D8A.1050304@bbn.com> <53F27065.9030902@cs.tcd.ie> In-Reply-To: <53F27065.9030902@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 18 Aug 2014 14:39:28 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/9OXNcHHD5SEFuh4ZuaS5qQRvkXw Cc: saag , ietf@ietf.org Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 21:39:45 -0000 On 8/18/2014 2:30 PM, Stephen Farrell wrote: > On 18/08/14 22:18, Stephen Kent wrote: >> short of re-writing it for him, I don't >> see how to fix this mess. > > I think that's going too far and is disrespectful > to Viktor and to those others who have expressed > support for the document. Really, Stephen, Please stop finding ways to discount comments from those of us with serious criticisms of the draft. That's especially egregious > given that you haven't even bothered to compare > -03 to the earlier on-list discussion. This is a prime example of the problem in your perspective. An author should provide detailed responses, to detailed comments. In the current case, the author has repeatedly failed to do that. Instead, we are faced with the rest of us having to guess what changes might pertain to our comments. The kind of "check the latest draft" review that is appropriate for the community is one that comes /after/ detailed discussion, debate and resolution of detailed comments. This predecessor activity -- which comprises acknowledging points of agreement and engaging in detailed, constructive dialogue about points of disagreement -- has been almost completely absent from any phase of this draft, except for the places in which the author (or you or the shepherd) have rejected points or summarily declared them in the rough. > Please provide a detailed description of how -03 > does or does not map to the earlier mailing list > discussion. When someone from the community provides detailed comments, the responsibility rests with the author to /engage/ in actual discussion about them. Not ignore or summarily reject them. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Aug 18 14:43:09 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BFC1A7026; Mon, 18 Aug 2014 14:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur8FJoiZhLqB; Mon, 18 Aug 2014 14:43:04 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6EB1A7021; Mon, 18 Aug 2014 14:43:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9EA16BE47; Mon, 18 Aug 2014 22:43:03 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwLgk2YHPXFu; Mon, 18 Aug 2014 22:43:02 +0100 (IST) Received: from [10.87.48.11] (unknown [86.42.20.223]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8B807BE20; Mon, 18 Aug 2014 22:43:02 +0100 (IST) Message-ID: <53F27366.2080905@cs.tcd.ie> Date: Mon, 18 Aug 2014 22:43:02 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> <53F26D8A.1050304@bbn.com> <53F27065.9030902@cs.tcd.ie> <53F271F8.5020508@dcrocker.net> In-Reply-To: <53F271F8.5020508@dcrocker.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/imkP3M0Xm_ffM2ayZO-q-kWiTkg Cc: saag , ietf@ietf.org Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 21:43:06 -0000 Dave, On 18/08/14 22:36, Dave Crocker wrote: > When someone from the community provides detailed comments, the > responsibility rests with the author to /engage/ in actual discussion > about them. Not ignore or summarily reject them. I realise that that is your take on this discussion. As you know, it is not mine. I do not believe that I've seen anything summarily rejected. I have seen the author engaging in actual discussion. S. From nobody Mon Aug 18 15:11:31 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4E21A86E6; Mon, 18 Aug 2014 15:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFUBTy7PwxkM; Mon, 18 Aug 2014 15:11:24 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA521A86E4; Mon, 18 Aug 2014 15:11:24 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 15E9B5660137; Mon, 18 Aug 2014 22:11:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUXbb2j0A8W1; Tue, 19 Aug 2014 00:10:52 +0200 (CEST) Received: from kopoli (p5DCC776E.dip0.t-ipconnect.de [93.204.119.110]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 6DDB65660136; Tue, 19 Aug 2014 00:10:52 +0200 (CEST) From: "Hosnieh Rafiee" To: References: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A27C5E@lhreml513-mbb.china.huawei.com> <20140818163957.GP14392@mournblade.imrryr.org> <006101cfbb2a$e7a6c2c0$b6f44840$@rozanak.com> In-Reply-To: <006101cfbb2a$e7a6c2c0$b6f44840$@rozanak.com> Date: Tue, 19 Aug 2014 00:10:49 +0200 Message-ID: <006b01cfbb31$45f54fd0$d1dfef70$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIt1pOjsPyzV77MbbdbaklNJbfYwQD2UX1aAgv1nhUBhCJUCZr2gVsg Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/saag/0hYcUkNpSF3ql210eHhIrb4aAM8 Cc: secauth@ietf.org Subject: Re: [saag] secauth requirements and usecase scenarios - link X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 22:11:28 -0000 Follow up, Let me give you an example: Consider a scenario where Client A wants to connect to mail server B. Mail server B needs to authenticate client A and then let it to mail server B to submits its email. both nodes uses TLS to secure this process. If B supports a CA, then A can easily trust it. If not, A has 3 options, 1- stop using B,2- change to plain text or 3-accepts B's certificate as it is. Both 2 and 3 are not quite secure but the latter approach is better than the former one since the attacker only at the beginning of this communication might spoof the identity of B and steal User A's credential. If the hardcopy certification of B is available in node A then, the likelihood of this attacks is almost zero. However in this case A should keep the mapping of IP and keys otherwise other approaches are in use. This API is supposed to help in similar scenarios without having complexity or dependency to any infrastructure. Combination of network layer approaches with other layer above network layer are better handle this secure authentication since it already has an opportunity to authenticate node B in network layer and in case its identity is ok, let the application to process any other authentication such as password based, token based, etc. Please note that this is only an example scenario. The main focus is also on virtualization and authentication in dynamic environment. Best, Hosnieh P.S. we also welcome any contributors :-) From nobody Mon Aug 18 15:46:53 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CB31A86E2 for ; Mon, 18 Aug 2014 15:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4r7-JK-FKDt for ; Mon, 18 Aug 2014 15:46:43 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0F83E1A86E1 for ; Mon, 18 Aug 2014 15:46:43 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id B0A37438072 for ; Mon, 18 Aug 2014 15:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=QwR/N6TkFNFCR2t+pD+t 5Yj2Qs8=; b=xMCzaEnOJeTHfFGC2jjJBjWDj9HQZqY8x3LbtnMOGGw+VcqRpbdN 2SSYkGouc+DCeXnvWXrcA/dJWzt6fz7Auf/4o0e6lsiCMCWJZ6rWQYir+pODqo/3 rLy19iHMGHUdV+PMHVU5ZzRGWln4HxhfeuqO5CjKcMBl9tBQAUonr+o= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 6258243806C for ; Mon, 18 Aug 2014 15:46:42 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so4414501wib.10 for ; Mon, 18 Aug 2014 15:46:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.75.17 with SMTP id y17mr2046931wiv.3.1408402001194; Mon, 18 Aug 2014 15:46:41 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Mon, 18 Aug 2014 15:46:41 -0700 (PDT) In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A27C5E@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A27C5E@lhreml513-mbb.china.huawei.com> Date: Mon, 18 Aug 2014 17:46:41 -0500 Message-ID: From: Nico Williams To: Hosnieh Rafiee Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/fAYTF-7JXjIGdTcbyKfaes27OBU Cc: "saag@ietf.org" Subject: Re: [saag] secauth requirements and usecase scenarios - link X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 22:46:43 -0000 These are requirements and use cases for what protocol work? what WG? Nico -- From nobody Mon Aug 18 16:29:59 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCE41A0027; Mon, 18 Aug 2014 16:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRnJqU_n5Neb; Mon, 18 Aug 2014 16:29:55 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id DE27D1A0016; Mon, 18 Aug 2014 16:29:54 -0700 (PDT) X-AuditID: 12074422-f79be6d000007518-6a-53f28c71914e Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 62.E1.29976.27C82F35; Mon, 18 Aug 2014 19:29:54 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s7INTq47007124; Mon, 18 Aug 2014 19:29:53 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7INToI2014539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Aug 2014 19:29:52 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7INTog2004328; Mon, 18 Aug 2014 19:29:50 -0400 (EDT) Date: Mon, 18 Aug 2014 19:29:50 -0400 (EDT) From: Benjamin Kaduk To: Stephen Kent In-Reply-To: <53F26D85.1070703@bbn.com> Message-ID: References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <20140815221806.GA5476@mournblade.imrryr.org> <53F26D85.1070703@bbn.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUixCmqrVvU8ynYoPkdi8WzjfNZLDbOZrSY 0t/J5MDsMfV8qMeSJT+ZApiiuGxSUnMyy1KL9O0SuDIO/5nBXPCErWLOpD1sDYzHWLsYOTkk BEwkmuZOg7LFJC7cW8/WxcjFISQwm0ni7XmIhJDARkaJKTfyIOxDTBJ3PwtAFDUwSsz50wxW xCKgLXHl3ilGEJtNQEVi5puNbCC2iIC8xLdjW1m6GDk4mAXUJY5f0QPpFRZYyCgx4+kDsHpO oPiitZ1g9bwCjhLnjn+CWnyXUeLoQ14QW1RAR2L1/iksEDWCEidnPgGzmQW0JJZP38YygVFw FpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN9XIzS/RSU0o3MYLCld1FaQfjz4NK hxgFOBiVeHhPfPwYLMSaWFZcmXuIUZKDSUmUd2nnp2AhvqT8lMqMxOKM+KLSnNTiQ4wSHMxK IrwJpkA53pTEyqrUonyYlDQHi5I471trq2AhgfTEktTs1NSC1CKYrAwHh5IEL2M3UKNgUWp6 akVaZk4JQpqJgxNkOA/QcGmQGt7igsTc4sx0iPwpRl2Olqa3vUxCLHn5ealS4rz7u4CKBECK Mkrz4ObA0swrRnGgt4R5f4BU8QBTFNykV0BLmICWbF38EWRJSSJCSqqBUX5OjujvTW0T9Zf2 scyO/Gt50PDGT5Ppl8zeRuaFf3igJeiyc/Lpa3E9b08XzSxmv3e+Vzfhg570nWSVZd89pvNx TH76dm3du4Wcq2YmRPibxz9+viPpYtmxa1ddRApuCOieUOx6mG7w7MmqbxNE5QpCLnf+eVEm d2RBzGerRe/VnK7ZKfJNm6zEUpyRaKjFXFScCAADwzt1DgMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/saag/x6zKHNTCBZYzXsYmcHChpvmXnfY Cc: ietf@ietf.org, saag Subject: Re: [saag] Last Call: (Opportunistic Security: some protection most of the time) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 23:29:58 -0000 On Mon, 18 Aug 2014, Stephen Kent wrote: > Viktor, > > > ... > > > > My response was -03. If you're just resending the comments for > > stale versions of the work in progress, I can't really make use of > > those I'm afraid. They've already been processed and taken seriously. > You ignored/rejected detailed suggestions that would, IMHO, significantly > improve the text. Thus most of my comments are still applicable. It looks like Viktor only showed the commit message of https://github.com/vdukhovni/saag/commit/07e1bd3bd599266b07a162ae56b2e36fa3d4eead in his email http://www.ietf.org/mail-archive/web/saag/current/msg05373.html and not a link to the actual commit itself. That should help you determine which parts (if any) of your feedback were ignored. I, for one, would be interested in seeing which parts (if any) those are. -Ben From nobody Mon Aug 18 17:39:33 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8146C1A8726 for ; Mon, 18 Aug 2014 17:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1z73ik5QMUm for ; Mon, 18 Aug 2014 17:39:29 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948C71A8725 for ; Mon, 18 Aug 2014 17:39:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 732D52AB2B7; Tue, 19 Aug 2014 00:39:27 +0000 (UTC) Date: Tue, 19 Aug 2014 00:39:27 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140819003927.GR14392@mournblade.imrryr.org> References: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A27C5E@lhreml513-mbb.china.huawei.com> <20140818163957.GP14392@mournblade.imrryr.org> <006101cfbb2a$e7a6c2c0$b6f44840$@rozanak.com> <006b01cfbb31$45f54fd0$d1dfef70$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006b01cfbb31$45f54fd0$d1dfef70$@rozanak.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/U5UaM3d-aj9UlhC5aSdnb6B8mcY Subject: Re: [saag] secauth requirements and usecase scenarios - link X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 00:39:31 -0000 On Tue, Aug 19, 2014 at 12:10:49AM +0200, Hosnieh Rafiee wrote: > Consider a scenario where Client A wants to connect to mail server B. Mail > server B needs to authenticate client A and then let it to mail server B to > submits its email. Both nodes uses TLS to secure this process. If B > supports a CA, [ That is, B's certificate is signed by a CA trusted by A. ] > then A can easily trust it. [ Then A can authenticate the security of its TLS-encrypted channel to B. ] > If not, A has 3 options, > > 1-stop using B, > 2- change to plain text or > 3-accepts B's certificate as it is. [ There is also a possibility of B using DANE, and A's MUA (some day) supporting DANE, in which case the need for a mutually trusted CA goes away. ] Option 2 is wrong, and specifically highlighted as such in the opportunistic TLS draft. > Both 2 and 3 are not quite secure but the latter approach is better than the > former one since the attacker only at the beginning of this communication > might spoof the identity of B and steal User A's credential. Indeed, 3 is better than 2. > If the hardcopy certification of B is available in node A then, the > likelihood of this attacks is almost zero. However in this case A should > keep the mapping of IP and keys otherwise other approaches are in use. s/certification/certificate/ Don't see where you're going with the second sentence. > This API is supposed to help in similar scenarios without having complexity > or dependency to any infrastructure. What API? What problem is the new API intended to address? On what foundation is the API supposed to be implemented? > Combination of network layer approaches > with other layer above network layer are better handle this secure > authentication since it already has an opportunity to authenticate node B in > network layer and in case its identity is ok, let the application to process > any other authentication such as password based, token based, etc. Well, in many cases the mapping from B's DNS name in A's configuration to B's IP address is over insecure DNS. Then it does not matter if A can get a secure connection to B's IP address. The MiTM wins by spoofing the DNS replies. You'd need a network-layer security association that is tied to DNS names, and indeed APIs to establish network connections that communicate these name to the network layer. This is a difficult problem. It is unclear what your intentions are in this space. > Please note that this is only an example scenario. The main focus is also on > virtualization and authentication in dynamic environment. You probably need to be a bit more specific than that. -- Viktor. From nobody Mon Aug 18 20:25:53 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8591A01E1; Mon, 18 Aug 2014 20:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BJmSHsRn1QY; Mon, 18 Aug 2014 20:25:47 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040BF1A01D0; Mon, 18 Aug 2014 20:25:45 -0700 (PDT) X-AuditID: 1209190f-f79aa6d000005b45-ee-53f2c3b83ecf Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id D4.F2.23365.8B3C2F35; Mon, 18 Aug 2014 23:25:44 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s7J3PhUt022795; Mon, 18 Aug 2014 23:25:43 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7J3PfDx011344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Aug 2014 23:25:42 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7J3PeaW005246; Mon, 18 Aug 2014 23:25:40 -0400 (EDT) Date: Mon, 18 Aug 2014 23:25:40 -0400 (EDT) From: Benjamin Kaduk To: Stephen Kent In-Reply-To: <53F26D8A.1050304@bbn.com> Message-ID: References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> <53F26D8A.1050304@bbn.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsUixG6nrrvj8Kdgg559vBbPNs5nsdg4m9Fi Sn8nkwOzx9TzoR5LlvxkCmCK4rJJSc3JLEst0rdL4MrYPrG44IBAxbIt95kaGPt4uxg5OSQE TCR+PN3GCGGLSVy4t56ti5GLQ0hgNpPExaYVzBDORkaJl7dnsEI4h5gkDtx+B1XWwCjx5dg/ NpB+FgFtia2br7KC2GwCKhIz32wEi4sIyEt8O7aVpYuRg4NZQF3i+BU9kLCwQKHEzV0dYCWc QOETbZfZQWxeAUeJxpmT2CHmv2aUuL91JwtIQlRAR2L1/iksEEWCEidnPgGzmQW0JJZP38Yy gVFwFpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN9HIzS/RSU0o3MYICllOSfwfj t4NKhxgFOBiVeHhPfPwYLMSaWFZcmXuIUZKDSUmUlwUY7kJ8SfkplRmJxRnxRaU5qcWHGCU4 mJVEeFduAcrxpiRWVqUW5cOkpDlYlMR531pbBQsJpCeWpGanphakFsFkZTg4lCR4/x4CahQs Sk1PrUjLzClBSDNxcIIM5wEazgqymLe4IDG3ODMdIn+KUVFKnPcDSLMASCKjNA+uF5ZQXjGK A70izPsKpIoHmIzgul8BDWYCGrx18UeQwSWJCCmpBsYim6KOv67/rJbFhJW4vm7x37L5+zzF Tfv2Rkfsuq13qVjRfL26/e8Zud6dkx4mnZiZyrZa9eqdqUwuDfppZ0yLtN4xTbGzYrg9x1C7 dab50W1z/9u9+yoqprElMTWPU7+/wONpbbvoa646f5molAXRa5kNRM/zPdXtLvh7bF+p3QeV 0o5XRUosxRmJhlrMRcWJAFC9KaEDAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/saag/u8O_Ew1_asUbllNIE1swkIAohgw Cc: ietf@ietf.org, saag Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 03:25:50 -0000 On Mon, 18 Aug 2014, Stephen Kent wrote: Nico Williams wrote: > > > It's true that terminology matters, don't get me wrong, but you're > > demanding a level of conflict-free terminology that is infeasible, while > > at the same time failing to convince anyone that there's a problem here. > > Really, "protocol design pattern" is problematic?! > yes, it is. it's yet another example where Viktor has chosen to > needlessly create a new term, which engenders confusion. I cannot agree that "protocol design pattern" is "needlessly creat[ing] a new term"; on the contrary, I think it is precisely the right term for this document. > When trying to convey new concepts to an audience it's a good idea to use > existing terminology whenever possible. This doc is a poster boy for failing > in that regard. I confess I do not remember what other cases of not reusing existing terminology you have already pointed out earlier in the thread. Can I trouble you to repeat a few of them? > > The question is not "can you find some past usage of this or that term > > that you can use to nitpick?". The question is: is the I-D clear? > That's an easy question to answer: NO, it is not clear. I am forced to agree (roughly spreaking) -- the document does not *clearly* state the points which are being expressed on the mailing list. (I am working on some changes which help.) One thing in particular which does stand out is "encryption" vs. "security", as Dave Crocker has pointed out. I do not believe that the *only* thing the document covers is encryption, but it does seem that encryption is given more weight than it should for a document claiming to cover the more-generic "security". > In fact, Viktor's prose is needlessly verbose in many places. I provided > some examples of how to simplify it. This doc can be much better, and > not longer, if it were rewritten to be clear. I agree that there are some places which are overly verbose and could be reworked to be more clear. I will follow up with more concrete suggestions when I am happy with them. -Ben From nobody Mon Aug 18 20:28:34 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84781A01A8; Mon, 18 Aug 2014 20:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtqAcLIz1OA2; Mon, 18 Aug 2014 20:28:30 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7271A0177; Mon, 18 Aug 2014 20:28:29 -0700 (PDT) X-AuditID: 1209190d-f79c06d000006f95-db-53f2c45ccbca Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id EE.E2.28565.C54C2F35; Mon, 18 Aug 2014 23:28:28 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s7J3SSQJ023011; Mon, 18 Aug 2014 23:28:28 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7J3SQV4012136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Aug 2014 23:28:27 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7J3SP2f005647; Mon, 18 Aug 2014 23:28:25 -0400 (EDT) Date: Mon, 18 Aug 2014 23:28:25 -0400 (EDT) From: Benjamin Kaduk To: Stephen Kent In-Reply-To: <53F26D8F.2080209@bbn.com> Message-ID: References: <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <53EE7214.6010206@qti.qualcomm.com> <53EE9560.9000009@dcrocker.net> <53EE981E.4010504@cs.tcd.ie> <53EE99F3.80809@dcrocker.net> <53EEA229.2080408@cs.tcd.ie> <17924.1408218266@sandelman.ca> <20140816202207.GD8110@localhost> <53F26D8F.2080209@bbn.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixG6nrhtz5FOwwc19phbPNs5nsdg4m9Fi Sn8nkwOzx9TzoR5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4seUeW8Eb1opZT/tZGxjPsXQxcnJI CJhI7OicwAphi0lcuLeerYuRi0NIYDaTxLKrx1kgnI2MEpNbvzFBOIeYJJafWghV1sAo0b3u PHsXIwcHi4C2xKW7wiCj2ARUJGa+2cgGYosIyEt8O7aVBaSEWUBd4vgVPZCwsIC/xJ+D85lB bE6g8PZ5N8BKeAUcJX48CAEJCwmsYJZYc6kYxBYV0JFYvX8K2NG8AoISJ2c+AbOZBbQklk/f xjKBUXAWktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdI30cjNL9FJTSjcxgoKVU5J3 B+O7g0qHGAU4GJV4eE98/BgsxJpYVlyZe4hRkoNJSZSX5fCnYCG+pPyUyozE4oz4otKc1OJD jBIczEoivCu3AOV4UxIrq1KL8mFS0hwsSuK8b62tgoUE0hNLUrNTUwtSi2CyMhwcShK8fw8B NQoWpaanVqRl5pQgpJk4OEGG8wANZwVZzFtckJhbnJkOkT/FqMvR0vS2l0mIJS8/L1VKnPcD yCABkKKM0jy4ObAk84pRHOgtYd5XIFU8wAQFN+kV0BImoCVbF38EWVKSiJCSamCs63G4/ThY P3m+UqvWQd4fMx5LrdjoGRyzeoFYmEdgy+/HvCIlLrufyn2/JvrWsZ/D9FP3wZzkzbr8p96/ spwd+Kx5+cFJBq1qj75ckJ1tdGdS14KDr6SCOc6f3bkr9egcvkbpnoCWkJbWFR8CQs7afNtf dL5YZ9K1o24JT3SeHWhlsuf3FjijxFKckWioxVxUnAgA6BkGzQ0DAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/saag/G_D3_uiL_WKsRhhEpBHDnhsXVNE Cc: ietf@ietf.org, saag Subject: Re: [saag] Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 03:28:31 -0000 On Mon, 18 Aug 2014, Stephen Kent wrote: > Nico, > > > On Sat, Aug 16, 2014 at 03:44:26PM -0400, Michael Richardson wrote: > > > (I think we are boiling the ocean on this document. Publish it) > let's not. The doc is very poorly written. It has internal consistency > problems, > is haphazard in its organization, sloppy in choices of wording, ... I expect that we've published documents which have much worse quality of writing. (That doesn't necessarily mean that we need to settle for what we've got, here.) I do have a great deal of sympathy for Viktor, trying to keep up with all the traffic being written about this document. It is hard to find the time to keep up with everything and give responses everywhere. -Ben From nobody Mon Aug 18 20:49:14 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295DC1A01E5; Mon, 18 Aug 2014 20:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCwBOsqwqxK8; Mon, 18 Aug 2014 20:49:11 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62AE51A01D0; Mon, 18 Aug 2014 20:49:11 -0700 (PDT) X-AuditID: 1209190d-f79c06d000006f95-52-53f2c936f26d Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id B2.43.28565.639C2F35; Mon, 18 Aug 2014 23:49:10 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s7J3n8mq026199; Mon, 18 Aug 2014 23:49:09 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7J3n6th016948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Aug 2014 23:49:08 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7J3n6AV008204; Mon, 18 Aug 2014 23:49:06 -0400 (EDT) Date: Mon, 18 Aug 2014 23:49:06 -0400 (EDT) From: Benjamin Kaduk To: dcrocker@bbiw.net In-Reply-To: <53F271F8.5020508@dcrocker.net> Message-ID: References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> <53F26D8A.1050304@bbn.com> <53F27065.9030902@cs.tcd.ie> <53F271F8.5020508@dcrocker.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsUixCmqrWt28lOwwZbpoha/P31gs3i2cT6L xZT+TiYHZo9LO0+yeSxZ8pMpgCmKyyYlNSezLLVI3y6BK2NHywuWgp1cFVMvvmNrYNzN0cXI ySEhYCLR2nCZCcIWk7hwbz1bFyMXh5DAbCaJZ/OXsoIkhAQ2Mkpcu2INkTjEJHF9/jwmCKeB UWLxlneMIFUsAtoS76+8YwGx2QRUJGa+2cgGYosIiEr03NsD1MDBwSygLvFwuhdIWFigUOLm rg6wEk4BHYn7mw6CLeMVcJR48vgCO8T8VUwSKzpPgM0XBSpavX8KC0SRoMTJmU/AbGYBLYnl 07exTGAUnIUkNQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdI73czBK91JTSTYzgoJXk 3cH47qDSIUYBDkYlHt4THz8GC7EmlhVX5h5ilORgUhLlZTn8KViILyk/pTIjsTgjvqg0J7X4 EKMEB7OSCO/KLUA53pTEyqrUonyYlDQHi5I471trq2AhgfTEktTs1NSC1CKYrAwHh5IEr/oJ oEbBotT01Iq0zJwShDQTByfIcB6g4Z+PgwwvLkjMLc5Mh8ifYlSUEudVBkkIgCQySvPgemFJ 5RWjONArwryiICt4gAkJrvsV0GAmoMFbF38EGVySiJCSamC8Xn+w2ZQjlv06c39DuSbr1St2 IsulklP9dt9JeOxZtU8tP88q9P/qlckHLhb2xBZ0btwh8/2NBOOKz182aW3jOqnqXqqqXag+ N/Elx7fWDwtts5b/e57zfOFXhuNr8jL38637vfnmBnXP48eeec6auq88PrjS+PfdS6Xfc44d jF6SWTBh2RRTJZbijERDLeai4kQA/2W+qQUDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/saag/gRRmnjaRh5BqUGjssnsREvYlDZc Cc: saag , ietf@ietf.org Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 03:49:13 -0000 On Mon, 18 Aug 2014, Dave Crocker wrote: > In the current case, the author has repeatedly failed to do that. > Instead, we are faced with the rest of us having to guess what changes > might pertain to our comments. You're not, actually; let me give you a link like I did Steve: https://github.com/vdukhovni/saag/commit/20379d90a2d3d781907d1d79c29c41e2112d0169 > This predecessor activity -- which comprises acknowledging points of > agreement and engaging in detailed, constructive dialogue about points > of disagreement -- has been almost completely absent from any phase of > this draft, except for the places in which the author (or you or the > shepherd) have rejected points or summarily declared them in the rough. I fear that the kind of dialogue you desire, on all the topics that have been raised, would require more hours than there are in a day. We're only human, and this isn't the only thing we're working on. > When someone from the community provides detailed comments, the > responsibility rests with the author to /engage/ in actual discussion > about them. Not ignore or summarily reject them. Does "I believe that the latest update of the draft accomodates all the comments that have been made" not qualify? Bear in mind the above comment about realistic time expectations. -Ben From nobody Mon Aug 18 22:11:29 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249581A87D2 for ; Mon, 18 Aug 2014 22:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohrPTVW6XWsL for ; Mon, 18 Aug 2014 22:11:19 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758C21A02BA for ; Mon, 18 Aug 2014 22:11:19 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 622B7566013B; Tue, 19 Aug 2014 05:11:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7AftWPs-Aus; Tue, 19 Aug 2014 07:10:47 +0200 (CEST) Received: from kopoli (p5DCC776E.dip0.t-ipconnect.de [93.204.119.110]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 7DDFF5660137; Tue, 19 Aug 2014 07:10:47 +0200 (CEST) From: "Hosnieh Rafiee" To: "'Nico Williams'" References: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A27C5E@lhreml513-mbb.china.huawei.com> In-Reply-To: Date: Tue, 19 Aug 2014 07:10:45 +0200 Message-ID: <002201cfbb6b$ef7fab10$ce7f0130$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIt1pOjsPyzV77MbbdbaklNJbfYwQD2UX1aARBc552bCvTbkA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/saag/cnt39fkq6De_Kb0Cd4RrpITgCCo Cc: saag@ietf.org Subject: Re: [saag] secauth requirements and usecase scenarios - link X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 05:11:25 -0000 Hi Nikco, > These are requirements and use cases for what protocol work? what WG? > Secauth . it is not yet WG. Best, Hosnieh From nobody Mon Aug 18 22:23:53 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63E41A87CE for ; Mon, 18 Aug 2014 22:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lX928V2DFSQ for ; Mon, 18 Aug 2014 22:23:51 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 18CC81A02D0 for ; Mon, 18 Aug 2014 22:23:51 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id A2E7A3B805C for ; Mon, 18 Aug 2014 22:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=QFcD63PLAZC59ElzvBkx ZGYkqec=; b=Cs+a3Eiv9hsUcL0SPIF5da1NlvXNS/fFCu9ZI5xLFqRDyyjOp77Q clTet9V+M1eOyicavm/QL0f8uvkppS7jVLNB9HeSgFwj5WjK5fSkRnTqq4/GhblC q32YuJ2OEs59ddU+/83/UWB7qYhJMo0sM0+74omeVtK18mJTMxv4Vfo= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 588483B805B for ; Mon, 18 Aug 2014 22:23:50 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so5869069wgh.29 for ; Mon, 18 Aug 2014 22:23:49 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.123.1 with SMTP id lw1mr18245028wjb.4.1408425829035; Mon, 18 Aug 2014 22:23:49 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Mon, 18 Aug 2014 22:23:48 -0700 (PDT) In-Reply-To: <002201cfbb6b$ef7fab10$ce7f0130$@rozanak.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A27C5E@lhreml513-mbb.china.huawei.com> <002201cfbb6b$ef7fab10$ce7f0130$@rozanak.com> Date: Tue, 19 Aug 2014 00:23:48 -0500 Message-ID: From: Nico Williams To: Hosnieh Rafiee Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HiXg2j5Y-hp2IEeBUfLd6d1EWDs Cc: "saag@ietf.org" Subject: Re: [saag] secauth requirements and usecase scenarios - link X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 05:23:51 -0000 On Tue, Aug 19, 2014 at 12:10 AM, Hosnieh Rafiee wrote: > Hi Nikco, >> These are requirements and use cases for what protocol work? what WG? >> > > Secauth . it is not yet WG. Are there any BoF materials? Proceedings? From nobody Mon Aug 18 22:37:56 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1881A87CE; Mon, 18 Aug 2014 22:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvDBw_U1g8px; Mon, 18 Aug 2014 22:37:52 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391301A02D7; Mon, 18 Aug 2014 22:37:52 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 7A23E566013B; Tue, 19 Aug 2014 05:37:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLA-5HxxPQah; Tue, 19 Aug 2014 07:37:21 +0200 (CEST) Received: from kopoli (p5DCC776E.dip0.t-ipconnect.de [93.204.119.110]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id AA0305660137; Tue, 19 Aug 2014 07:37:20 +0200 (CEST) From: "Hosnieh Rafiee" To: References: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A27C5E@lhreml513-mbb.china.huawei.com> <20140818163957.GP14392@mournblade.imrryr.org> <006101cfbb2a$e7a6c2c0$b6f44840$@rozanak.com> <006b01cfbb31$45f54fd0$d1dfef70$@rozanak.com> <20140819003927.GR14392@mournblade.imrryr.org> In-Reply-To: <20140819003927.GR14392@mournblade.imrryr.org> Date: Tue, 19 Aug 2014 07:37:18 +0200 Message-ID: <002301cfbb6f$a51c8f30$ef55ad90$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIt1pOjsPyzV77MbbdbaklNJbfYwQD2UX1aAgv1nhUBhCJUCQHO7VDIAR4E9++a34/wcA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/saag/pZ6cwkdiVi2Ek8a6JZK6DM4u818 Cc: secauth@ietf.org Subject: Re: [saag] secauth requirements and usecase scenarios - link X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 05:37:54 -0000 Thanks again Viktor, please see my responses inline... > > > Consider a scenario where Client A wants to connect to mail server B. > > Mail server B needs to authenticate client A and then let it to mail > > server B to submits its email. Both nodes uses TLS to secure this > > process. If B supports a CA, > > [ That is, B's certificate is signed by a CA trusted by A. ] True > > then A can easily trust it. > > [ Then A can authenticate the security of its TLS-encrypted channel to B. ] True > > If not, A has 3 options, > > > > 1-stop using B, > > 2- change to plain text or > > 3-accepts B's certificate as it is. > > [ There is also a possibility of B using DANE, and A's MUA (some day) > supporting DANE, in which case the need for a mutually trusted CA > goes away. ] Have you ever had a chance to read CGA-TSIG draft (In new version I will remove many unrelated sections)? This is supposed to help for the last miles of Internet or supposed to help DNSSEC in last miles where it is not easy to handle data confidentiality and secure authentication. It supposed to automate this process. (it is of course not about only CGA but other network layer approaches to support both IPv4 and iPv6 enabled network) That draft is an example of what secauth plan to do but, of course, we are not planning to use CGA but some other approaches. DANE uses DNSSEC that is not easy to handle the last miles again and such approaches like secauth can help in this regard where not easily can authenticate a node. In other words, secauth plans to use easier approach or only IP based and then you can combine this approach with TLS or any other approaches above network layer. This is what I meant in the draft. Let me give you another example about SSH. (it is also mentioned in opportunistic TLS) Client A wants to connect to server B via SSH. Server B does not support certificate signed by a CA. So it is vulnerable in first point. Now, supposed a scenario where secauth is in use. A knows the IP address or domain name of B. A and B supports secauth and implemented it. A request for connecting to B. B sends its certificate that is bound to B's IP address. Since A knows the IP address of B, A ensures that this certificate is from B. So an attacker cannot spoof this connection even in first place. Is it clear? > Option 2 is wrong, and specifically highlighted as such in the opportunistic TLS > draft. True Opportunistic TLS highlighted the problem. But secauth is a possible solution to a problem > > Both 2 and 3 are not quite secure but the latter approach is better > > than the former one since the attacker only at the beginning of this > > communication might spoof the identity of B and steal User A's credential. > > Indeed, 3 is better than 2. > > > If the hardcopy certification of B is available in node A then, the > > likelihood of this attacks is almost zero. However in this case A > > should keep the mapping of IP and keys otherwise other approaches are in > use. > > s/certification/certificate/ > > Don't see where you're going with the second sentence. Please see above. > > This API is supposed to help in similar scenarios without having > > complexity or dependency to any infrastructure. > > What API? What problem is the new API intended to address? On what > foundation is the API supposed to be implemented? The authentication and authorization without the need of infrastructure and help other services where not easy to handle the last miles. It can be DANE, DNSSEC, etc. > > Combination of network layer approaches with other layer above network > > layer are better handle this secure authentication since it already > > has an opportunity to authenticate node B in network layer and in case > > its identity is ok, let the application to process any other > > authentication such as password based, token based, etc. > > Well, in many cases the mapping from B's DNS name in A's configuration to B's > IP address is over insecure DNS. Then it does not matter if A can get a secure > connection to B's IP address. The MiTM wins by spoofing the DNS replies. > You'd need a network-layer security association that is tied to DNS names, and > indeed APIs to establish network connections that communicate these name > to the network layer. This is a difficult problem. No, please check CGA-TSIG draft. That is supposed to answer that question. > It is unclear what your intentions are in this space. > > > Please note that this is only an example scenario. The main focus is > > also on virtualization and authentication in dynamic environment. > > You probably need to be a bit more specific than that. I hope that is clear. I am planning to have an online discussion next week. I will be glad to explain to anyone who is interested. http://doodle.com/se3gyys9dnre4nyr If these time doesn't work for anyone, feel free to suggest other times. Best, Hosnieh From nobody Mon Aug 18 22:45:31 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9D41A880E; Mon, 18 Aug 2014 22:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FClkewfvG-cW; Mon, 18 Aug 2014 22:45:28 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B891A87F2; Mon, 18 Aug 2014 22:45:28 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 74D62566013B; Tue, 19 Aug 2014 05:45:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5WWFuYOTTlG; Tue, 19 Aug 2014 07:44:56 +0200 (CEST) Received: from kopoli (p5DCC776E.dip0.t-ipconnect.de [93.204.119.110]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 19E4F5660137; Tue, 19 Aug 2014 07:44:56 +0200 (CEST) From: "Hosnieh Rafiee" To: "'Nico Williams'" References: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A27C5E@lhreml513-mbb.china.huawei.com> <002201cfbb6b$ef7fab10$ce7f0130$@rozanak.com> In-Reply-To: Date: Tue, 19 Aug 2014 07:44:55 +0200 Message-ID: <002401cfbb70$b49ad150$1dd073f0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIt1pOjsPyzV77MbbdbaklNJbfYwQD2UX1aARBc550BhUY//QEdb1DGmvXnhDA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/saag/eaM8mKGB_7cngDiM0mbjeEpmjQo Cc: secauth@ietf.org, saag@ietf.org Subject: Re: [saag] secauth requirements and usecase scenarios - link X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 05:45:30 -0000 >=20 > On Tue, Aug 19, 2014 at 12:10 AM, Hosnieh Rafiee > wrote: > > Hi Nikco, > >> These are requirements and use cases for what protocol work? what = WG? > >> > > > > Secauth . it is not yet WG. >=20 > Are there any BoF materials? Proceedings? There are discussions of mailinglist http://www.ietf.org/mail-archive/web/secauth/current/maillist.html I also summarized last messages discussed on mailinglist. It was not so = active recently because I needed to complete first version of the = requirement draft before I can start any discussion but now I am = following it and will actively answer questions, concerns, plans, etc. You can find the link in " [Secauth] All messages, Hosnieh Rafiee" I plan to have a BoF for the upcoming IETF in Hawaii. Next week also I prepared some slides to explain this approach and = welcome online participation.=20 There is a doodle poll for the times and dates (as I already explained = in my last message to Viktor) http://doodle.com/se3gyys9dnre4nyr=20 Thanks for asking, Best, Hosnieh From nobody Tue Aug 19 05:23:48 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873661A03F6; Tue, 19 Aug 2014 05:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoc6EwHHR0E4; Tue, 19 Aug 2014 05:23:46 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CD01A0411; Tue, 19 Aug 2014 05:23:45 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id j15so5471998qaq.25 for ; Tue, 19 Aug 2014 05:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z1HXbKzZJhmKsOIruqSriJnVFxXUwfyr7krb/2MvhMg=; b=iu1zpo/NNNTrf1oH6MP+LjnmfmYniT+rZ0jB9RGQn8rNKEwAhKQhhhDQTLdzelgxmB OupQtYE1+Gk6IZ3W4KnB1GdcnDfOwNynWcqr0jwPFvNZASTJhbTIf+N8MTzmJ/sPh3We VUhvuHI9/UFTNwW8ub2E31yGxq9lelfg/OcNI/vOCRbPXZVYKRq/mkjMR9rJKB0jMH+B MOGipYUYvBn6UK1bMirLpwGGa+022cQXNpSy5NgmjnEbBI8mZxFOwR9+hao18IvToDZH fq0dr0M2HXgcRSNclDLXcFSpikhKfoDe4LtD8njP31k5PgS5lFjxmq0r5gGcrxwZP1XE kxdg== X-Received: by 10.229.26.10 with SMTP id b10mr66070135qcc.29.1408451024936; Tue, 19 Aug 2014 05:23:44 -0700 (PDT) Received: from [192.168.1.4] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id t3sm34918517qaj.0.2014.08.19.05.23.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 05:23:43 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <002401cfbb70$b49ad150$1dd073f0$@rozanak.com> Date: Tue, 19 Aug 2014 08:23:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A27C5E@lhreml513-mbb.china.huawei.com> <002201cfbb6b$ef7fab10$ce7f0130$@rozanak.com> <002401cfbb70$b49ad150$1dd073f0$@rozanak.com> To: Hosnieh Rafiee Archived-At: http://mailarchive.ietf.org/arch/msg/saag/LTFOKbacL_efAkNlwEJJiecDMWM Cc: "secauth@ietf.org" , "saag@ietf.org" Subject: Re: [saag] secauth requirements and usecase scenarios - link X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 12:23:47 -0000 Hosnieh, I think it would help a lot if you could add more background and context to t= he introduction so folks know if it's relevant to their areas of work. The d= raft jumps right in without that. Viktor's message was helpful if that's what you had intended to cover (last m= ile description he provided). Thanks, Kathleen Sent from my iPhone On Aug 19, 2014, at 1:44 AM, "Hosnieh Rafiee" wrote: >>=20 >> On Tue, Aug 19, 2014 at 12:10 AM, Hosnieh Rafiee >> wrote: >>> Hi Nikco, >>>> These are requirements and use cases for what protocol work? what WG? >>>=20 >>> Secauth . it is not yet WG. >>=20 >> Are there any BoF materials? Proceedings? >=20 > There are discussions of mailinglist > http://www.ietf.org/mail-archive/web/secauth/current/maillist.html >=20 >=20 > I also summarized last messages discussed on mailinglist. It was not so ac= tive recently because I needed to complete first version of the requirement d= raft before I can start any discussion but now I am following it and will ac= tively answer questions, concerns, plans, etc. > You can find the link in " [Secauth] All messages, Hosnieh Rafiee" > I plan to have a BoF for the upcoming IETF in Hawaii. >=20 > Next week also I prepared some slides to explain this approach and welcome= online participation.=20 > There is a doodle poll for the times and dates (as I already explained in m= y last message to Viktor) > http://doodle.com/se3gyys9dnre4nyr=20 >=20 > Thanks for asking, > Best, > Hosnieh >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Tue Aug 19 06:01:15 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747481A0417; Tue, 19 Aug 2014 06:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egmR9cDK2iBV; Tue, 19 Aug 2014 06:01:11 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89D81A0410; Tue, 19 Aug 2014 06:01:11 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7JD18NW018346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Aug 2014 06:01:11 -0700 Message-ID: <53F349FD.8000309@dcrocker.net> Date: Tue, 19 Aug 2014 05:58:37 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> <53F26D8A.1050304@bbn.com> <53F27065.9030902@cs.tcd.ie> <53F271F8.5020508@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 19 Aug 2014 06:01:11 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Aujehm6S4CL1q5XA62e6LghiYWg Cc: saag , ietf@ietf.org Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 13:01:13 -0000 On 8/18/2014 8:49 PM, Benjamin Kaduk wrote: > On Mon, 18 Aug 2014, Dave Crocker wrote: >> When someone from the community provides detailed comments, the >> responsibility rests with the author to /engage/ in actual discussion >> about them. Not ignore or summarily reject them. > > Does "I believe that the latest update of the draft accomodates all the > comments that have been made" not qualify? No. Not even close. That's a phrase that should only come after detailed and meaningful discussion about disagreements and concerns. It should represent a summary of that discussion and not attempt to replace it. The idea that it should qualify as a standalone response underscores a basic disconnect about the nature how work in the IETF is supposed to be done. This is not supposed to be a magical process, where an author mystically decides what to include and what not to include. This is supposed to be a community collaboration, with discussion about disagreements. Claims that such diligent discussion would take too much time are strikingly at odds with the core process that has produced quality work here for 45 years. Thoughtful comments on a document warrant thoughtful responses and meaningful engagement in resolving differences. In simplistic terms, this means that "yes" and "no" are far less interesting than responses such as "I don't understand" and "what about...?" Folks who think otherwise should consider RFC 7282, and especially Sections 2 and 3. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Aug 19 06:01:50 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D541A88E9; Tue, 19 Aug 2014 06:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KND0Mp86REHj; Tue, 19 Aug 2014 06:01:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F8F1A88E7; Tue, 19 Aug 2014 06:01:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLK92453; Tue, 19 Aug 2014 13:01:37 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0158.001; Tue, 19 Aug 2014 14:01:34 +0100 From: Hosnieh Rafiee To: Kathleen Moriarty Thread-Topic: [saag] secauth requirements and usecase scenarios - link Thread-Index: AQHPuzZGdaJ65bndHEiF+QGYm74zNJvXUKyAgAADpQCAAAXngIAAb2sAgAAYzEA= Date: Tue, 19 Aug 2014 13:01:33 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A27EEA@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A27C5E@lhreml513-mbb.china.huawei.com> <002201cfbb6b$ef7fab10$ce7f0130$@rozanak.com> <002401cfbb70$b49ad150$1dd073f0$@rozanak.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/saag/5-vFN53m5rw-R59iCAfXzRLlM1g Cc: "secauth@ietf.org" , "saag@ietf.org" Subject: Re: [saag] secauth requirements and usecase scenarios - link X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 13:01:41 -0000 Hi Kathleen, Thanks for your suggestion. >=20 > I think it would help a lot if you could add more background and > context to the introduction so folks know if it's relevant to their > areas of work. The draft jumps right in without that. >=20 > Viktor's message was helpful if that's what you had intended to cover > (last mile description he provided). Ok, I will add more background text and will also cover the discussion that= I had with Viktor. By his comments, I also noticed that there is missing s= ection in the draft while I thought everything is clear :-|=20 Thanks, Best, Hosnieh From nobody Tue Aug 19 06:10:34 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287C81A88EE; Tue, 19 Aug 2014 06:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWLbH2edbZZL; Tue, 19 Aug 2014 06:10:11 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2110C1A02D2; Tue, 19 Aug 2014 06:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1412; q=dns/txt; s=iport; t=1408453811; x=1409663411; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=g4GDzVH29fnDNFAmB7Pb6uoQ9FIczusX3qHvc1YIeM4=; b=d31hGzkSwzIDnpUBfm04GytTZj3tbn6qP0VYdzq3N8jAqcFhC/tT1G9z K3NAljV3lDE6PZaBXJ85KyYnJO3E/QfKcXsJN1VpgeWgxCwLBPPMItDex ojYn9TOyQyBCXjuvpMexmbrzIFlrbG3zSFNrgOxqh7Txl3jQczaVOp/Yu M=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAHVM81OtJssW/2dsb2JhbABZhzPRRgGBIXeEBAEBBCNVARALGAkWBAcCAgkDAgECAUUGAQwBBwEBiD6sSJUyF49MB4J5gVMBBJMlgUqHU4cqjVmCF4FIO4J+AQEB X-IronPort-AV: E=Sophos;i="5.01,893,1400025600"; d="asc'?scan'208";a="147115485" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 19 Aug 2014 13:09:50 +0000 Received: from [10.61.196.191] ([10.61.196.191]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7JD9nHE008404; Tue, 19 Aug 2014 13:09:49 GMT Message-ID: <53F34C9D.1020908@cisco.com> Date: Tue, 19 Aug 2014 15:09:49 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nico Williams , Paul Wouters References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ukCm8iV5W6oLU2VsRcpTw6jqPejvGQm0x" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/VlQGohThzZ-NinnsJYCNZzfmA4s Cc: saag , "ietf@ietf.org" , Dave Crocker Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 13:10:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ukCm8iV5W6oLU2VsRcpTw6jqPejvGQm0x Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Nico, On 8/18/14, 5:35 PM, Nico Williams wrote: > >> - Follow RFCs as strict as possible to defeat fingerprinting attacks > Agreed, but again: too generic. > >> - If a connection is one-sided authenticated (eg like TLS) ensure your= >> protocol is okay with a role-reversal (eg if it needs to authenticat= e >> the end that was anonymous) > Ditto. Are you saying you want an example of one-sided authentication where role-reversal #FAILs? Eliot --ukCm8iV5W6oLU2VsRcpTw6jqPejvGQm0x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJT80ydAAoJEIe2a0bZ0nozXEUH/iyKaNCbiVEe5nWsTeikh6w1 MvJ/LZAtkfoiwHFYrKUVdaEAT+h0Kw2AQBJbIJNKbuiy0d+BFtKxXnVkGfLK2PBt lYVbmaHJeARnIQRvJFrVd4bNSny+NWcNd802jfCUa28/b8z0ef81nzUqMYoi8BQU g6o4hsBpOQN4yQwfPQrySBf8mw62YqnnJkO6queY0jcgwTaXHz0uOmFR2U/8vmlB o6XDB5t4D8HqmKbXkGg1IExgyKTBs2QkCVEzDYSvjYB3PLyrB0l5nK1wLqpn65Fb oomMND0o3ReawFrImnUQ7VAIKGuTwWNLItJHrCwJDfqhP+445FrFDrqFQuFBTds= =Z7i2 -----END PGP SIGNATURE----- --ukCm8iV5W6oLU2VsRcpTw6jqPejvGQm0x-- From nobody Tue Aug 19 07:39:58 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FB61A8925 for ; Tue, 19 Aug 2014 07:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcYsN_vb4elX for ; Tue, 19 Aug 2014 07:39:51 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40DF1A891F for ; Tue, 19 Aug 2014 07:39:50 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7JEdjtg021401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Aug 2014 07:39:49 -0700 Message-ID: <53F3611B.3060208@dcrocker.net> Date: Tue, 19 Aug 2014 07:37:15 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ianG , saag@ietf.org References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> In-Reply-To: <53F0B39F.90003@iang.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 19 Aug 2014 07:39:49 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/NmtdON6CIx8oDbcPCiUTGNp8wE4 Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:39:56 -0000 On 8/17/2014 6:52 AM, ianG wrote: > On 17/08/2014 14:20 pm, Dave Crocker wrote: >> This is an example of confusion about the meaning of the term design >> pattern. It is, equally, an example of the draft's limitation in >> carefully documenting the concepts it is attempt to teach. > > I am not confused at all about the term 'design pattern', it's a term in > wide-spread usage. The examples I cited were for very different meanings. They undermine the current usage. Since you say it is in common usage -- presumably with a related meaning as that in the draft -- please provide some pointers to examples. >> There is nothing in the document that clarifies the point. >> >> By my reading of the current draft, it discusses the distinction between >> authenticated and unauthenticated encryption. However it does not >> indicate that there is an important difference between one kind of >> authenticated versus another kind of authenticated. > > It should not need to do that. The point is to take auth as > opportunistic in general and not to categorise different ways of doing auth. It very much /does/ need to do that. If the document is to have practical benefit, it needs to define things carefully and to make the use of the term concrete. The alternative is a term that has no meaningful anchor in the real world. The concrete discussion in the document is about encryption. There is no discussion at all about authentication or any other aspect of security, as stand-alone functions. If the document is meant to apply to anything other than encryption, it needs to make the explicit, including discussion of concrete usage, or at least examples. >> In other words, does the term design pattern concern basic functional >> differences (eg, authenticated vs. not authenticated) or does it concern >> specific functional differences (CA-based authenticated vs. DANE-based >> authenticated)? > > The term design pattern can do either. But the use of the term in the > draft is to indicate that any auth method, be it ca or dane, can be seen > as an element in an opportunistic approach. I don't see text that says that, independent of encryption. Worse, the extent to which it is claiming an important, protection-related distinction between a CA-based independent validation mechanism and a DANE-based validation method, it does not explain how that difference is important in security terms. Arguably, in terms of general concerns about protection, they aren't meaningfully different. Consequently, casually citing them doesn't accomplish much. One could imagine a discussion that explores having a single service with the ability to use a variety of different authentication validation methods, but that isn't in this document. > Once you see many auth methods as just more tools in the kit, there is > no point in cataloging them. > >> My own view is that the utility of the term offered in the current draft >> concerns only very basis differences, and such details as which kind of >> exsternal authentication 'anchor' is used is of less import. >> >> Well... perhaps the difference between a TOFU and an "anchored" >> authenticated matter. But I do not see what significant utility is >> achieved by distinguishing between different types of anchored >> (independent, fixed, ...) authentication is used. > > If there is a point, it is to show that we can pick and choose? In > order to illustrate the sense of the design pattern at hand. I could imagine having a paper that explores such choices and then provides a variety of examples. This draft isn't that paper. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Aug 19 07:53:59 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6B71A892C; Tue, 19 Aug 2014 07:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idLpCLgHY_Rg; Tue, 19 Aug 2014 07:53:54 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D821A891A; Tue, 19 Aug 2014 07:53:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 989551A14AC; Tue, 19 Aug 2014 07:53:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-198.clppva.east.verizon.net [70.106.135.198]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id D96421A14AA; Tue, 19 Aug 2014 07:53:53 -0700 (PDT) Message-ID: <53F36502.4070002@joelhalpern.com> Date: Tue, 19 Aug 2014 10:53:54 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Hosnieh Rafiee , saag@ietf.org References: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A27C5E@lhreml513-mbb.china.huawei.com> <20140818163957.GP14392@mournblade.imrryr.org> <006101cfbb2a$e7a6c2c0$b6f44840$@rozanak.com> <006b01cfbb31$45f54fd0$d1dfef70$@rozanak.com> <20140819003927.GR14392@mournblade.imrryr.org> <002301cfbb6f$a51c8f30$ef55ad90$@rozanak.com> In-Reply-To: <002301cfbb6f$a51c8f30$ef55ad90$@rozanak.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/k1BQGNeSKiEzMGlunHpowaMYBqE Cc: secauth@ietf.org Subject: Re: [saag] [Secauth] secauth requirements and usecase scenarios - link X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:53:56 -0000 Trimming... On 8/19/14, 1:37 AM, Hosnieh Rafiee wrote: ... > Let me give you another example about SSH. > > (it is also mentioned in opportunistic TLS) > Client A wants to connect to server B via SSH. Server B does not support > certificate signed by a CA. So it is vulnerable in first point. Now, > supposed a scenario where secauth is in use. A knows the IP address or > domain name of B. A and B supports secauth and implemented it. A request for > connecting to B. B sends its certificate that is bound to B's IP address. > Since A knows the IP address of B, A ensures that this certificate is from > B. > So an attacker cannot spoof this connection even in first place. > > Is it clear? ... As far as I can tell, any solution which assumes A knows the current IP address of B without DNS or any other rendezvous protocol is a non-starter. If it is using DNS, then the DNS needs to be protected, or the structure fails. If DNS is protected, then DANE could be used. With greater flexibility and less modification of existing tools. Yours, Joel From nobody Tue Aug 19 08:20:23 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3901E1A8900; Tue, 19 Aug 2014 08:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqZ6imhXppus; Tue, 19 Aug 2014 08:20:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C561A03E3; Tue, 19 Aug 2014 08:20:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIK34953; Tue, 19 Aug 2014 15:20:05 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.03.0158.001; Tue, 19 Aug 2014 16:20:01 +0100 From: Hosnieh Rafiee To: "Joel M. Halpern" , Hosnieh Rafiee , "saag@ietf.org" Thread-Topic: [Secauth] [saag] secauth requirements and usecase scenarios - link Thread-Index: AQHPu716I2JoxqEXl0yY74cckUnKaJvYCNtg Date: Tue, 19 Aug 2014 15:20:00 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A27FD5@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A27C5E@lhreml513-mbb.china.huawei.com> <20140818163957.GP14392@mournblade.imrryr.org> <006101cfbb2a$e7a6c2c0$b6f44840$@rozanak.com> <006b01cfbb31$45f54fd0$d1dfef70$@rozanak.com> <20140819003927.GR14392@mournblade.imrryr.org> <002301cfbb6f$a51c8f30$ef55ad90$@rozanak.com> <53F36502.4070002@joelhalpern.com> In-Reply-To: <53F36502.4070002@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/saag/PiwCftiKLpgy1W8S9fSHTa7eMrc Cc: "secauth@ietf.org" Subject: Re: [saag] [Secauth] secauth requirements and usecase scenarios - link X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 15:20:19 -0000 Hi Joel, Thanks for your comment. See my response inline.. >=20 > As far as I can tell, any solution which assumes A knows the current IP > address of B without DNS or any other rendezvous protocol is a non- > starter. >=20 > If it is using DNS, then the DNS needs to be protected, or the > structure fails. >=20 > If DNS is protected, then DANE could be used. With greater flexibility > and less modification of existing tools. As far as I understood from DANE document, by knowing only the IP address o= f a node, DANE cannot work because IP spoofing is still possible and there = is no CA to protect this. No bindings of IP address is available. The purpose of secauth is to provide this binding for other mechanisms. For instance, it is possible to use secauth for a part of this authenticati= on and combine it with DANE or any other approaches. Secauth only provides = a transparent API for you to use it in other layers. I am adding some background information but in the meanwhile you can also c= heck CGA-TSIG draft to see how a solution like secauth suppose to work. Best, Hosnieh From nobody Tue Aug 19 08:31:47 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFE31A0472 for ; Tue, 19 Aug 2014 08:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_swCeS0Lj7C for ; Tue, 19 Aug 2014 08:31:38 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A4A1A03A8 for ; Tue, 19 Aug 2014 08:31:38 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C48DB2AB2A4; Tue, 19 Aug 2014 15:31:37 +0000 (UTC) Date: Tue, 19 Aug 2014 15:31:37 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140819153137.GA14392@mournblade.imrryr.org> References: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A27C5E@lhreml513-mbb.china.huawei.com> <20140818163957.GP14392@mournblade.imrryr.org> <006101cfbb2a$e7a6c2c0$b6f44840$@rozanak.com> <006b01cfbb31$45f54fd0$d1dfef70$@rozanak.com> <20140819003927.GR14392@mournblade.imrryr.org> <002301cfbb6f$a51c8f30$ef55ad90$@rozanak.com> <53F36502.4070002@joelhalpern.com> <814D0BFB77D95844A01CA29B44CBF8A7A27FD5@lhreml513-mbb.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A27FD5@lhreml513-mbb.china.huawei.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/6ueqqB4ri3DBbOgRvDinNN6lb2U Subject: Re: [saag] [Secauth] secauth requirements and usecase scenarios - link X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 15:31:43 -0000 On Tue, Aug 19, 2014 at 03:20:00PM +0000, Hosnieh Rafiee wrote: > > If DNS is protected, then DANE could be used. With greater flexibility > > and less modification of existing tools. > > As far as I understood from DANE document, by knowing only the > IP address of a node, DANE cannot work because IP spoofing is still > possible and there is no CA to protect this. No bindings of IP > address is available. This is not a DANE-specific issue. Typically, applications want channel security to a destination that is a domain name, not a network address. Absent a secure mapping from one to the other, there is little that network-layer security, that authenticates only the network endpoint, can do to close the gap. This problem applies equally to DANE, Web PKI, ... > Secauth only provides a transparent API for you to use it in other > layers. The requirements draft is very unclear on this. Is this an attempt to expose the security state of the network layer to applications? Possibly also allow the application layer to in part control the network-layer security association for a particular flow? If so, the draft should probably talk more about what state it intends to expose and what control mechanisms it intends to provide. Or at least what the requirements are for exposing state and controls. -- Viktor. From nobody Tue Aug 19 08:33:33 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB601A03A8; Tue, 19 Aug 2014 08:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.267 X-Spam-Level: X-Spam-Status: No, score=-4.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, MANY_SPAN_IN_TEXT=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGvrDY4ehyrS; Tue, 19 Aug 2014 08:33:18 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E461A0465; Tue, 19 Aug 2014 08:33:09 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:60062 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XJlPH-000FDi-Rm; Tue, 19 Aug 2014 11:33:08 -0400 Message-ID: <53F36E34.7020701@bbn.com> Date: Tue, 19 Aug 2014 11:33:08 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org, "ietf@ietf.org" References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> <53F26D8A.1050304@bbn.com> <53F27065.9030902@cs.tcd.ie> In-Reply-To: <53F27065.9030902@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------020901080302030201070300" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/cx6eBY4KN5rp2YnCtCAre5XRVyw Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 15:33:26 -0000 This is a multi-part message in MIME format. --------------020901080302030201070300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Stephen, > Steve, > > On 18/08/14 22:18, Stephen Kent wrote: >> short of re-writing it for him, I don't >> see how to fix this mess. > I think that's going too far and is disrespectful > to Viktor and to those others who have expressed > support for the document. That's especially egregious > given that you haven't even bothered to compare > -03 to the earlier on-list discussion. You are right that I failed to compare the released -03 version to the pre-release version. When I began to read the released -03 version I noted that almost none of the suggested changes appeared in the abstract or in most of section 1, which promoted my reply. But, I agree that I should have read the rest of the doc before commenting. Now that I have read the whole doc, I see that Viktor did adopt make changes reflecting some of my comments, though not consistently. My apologies for not reading the entirety of the new version before commenting. Still, I stand by my comments that the doc was still badly written, though it was better in several respects. The fact that some others have commented that they find the quality of the writing to be acceptable does not change reality. I also note that several of those expressing support for the writing (not the design per se) have authored very few RFCs. > Please provide a detailed description of how -03 > does or does not map to the earlier mailing list > discussion. I've done better that than. I have re-written the doc with an intent to address all of the issues I raised, retaining the design principles in the latest version, eliminating a lot of redundant text, and using less ambiguous language. The result is much shorter and, in my view, clearer and better organized. Steve ---------- Network Working GroupV. Dukhovni Internet-DraftTwo Sigma Intended status: InformationalAugust 15, 2014 Expires: February 16, 2015 Opportunistic Security: Some Protection Most of the Time draft-dukhovni-opportunistic-security-03 Abstract This memo introduces the concept "Opportunistic Crypto-Security" (OCS). OCS is a set of protocol design principles that attempt to remove barriers to the widespread use of encryption on the Internet. OCS is not a protocol. Protocols that adhere to OCS guidelines may offer additional crypto-security services, e.g., integrity and authentication, if these services are supported by all parties to a communication. The OCS design philosophy departs from the common practice of other Internet security protocols; they commonly require cryptographic protection against both passive and active attacks, or offer no protection at all.OCS protocols strive to offer encryption even if authentication is not available. This document encourages designs in which cryptographic protection against both passive and active attacks can be deployed incrementally, without creating barriers to communication. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts.The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 16, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors.All rights reserved. DukhovniExpires February 16, 2015[Page 1] Internet-DraftOpportunistic SecurityAugust 2014 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document.Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1.Introduction. . . . . . . . . . . . . . . . . . . . . . . .2 2.Terminology . . . . . . . . . . . . . . . . . . . . . . . . .4 3.The Opportunistic Security Design Pattern . . . . . . . . . .5 4.Opportunistic Security Design Principles. . . . . . . . . .7 5.Example: Opportunistic TLS in SMTP . . . . . . . . . . . . .8 6.Security Considerations . . . . . . . . . . . . . . . . . . .9 7.Acknowledgements. . . . . . . . . . . . . . . . . . . . . .9 8.References. . . . . . . . . . . . . . . . . . . . . . . . .9 8.1.Normative References. . . . . . . . . . . . . . . . . .9 8.2.Informative References. . . . . . . . . . . . . . . . .10 Author's Address. . . . . . . . . . . . . . . . . . . . . . . .10 1.Introduction The development of Opportunistic Crypto-Security (OCS) is motivated by the concerns raised in [RFC7258]. Pervasive monitoring (as defined in that RFC) is feasible because of the lack of widespread use of encryption for confidentiality. Although the IETF has developed many security protocols (e.g., TLS, IPsec, SSH, ...) that employ encryption for confidentiality, most of them also require one-way or two-way authentication. Authentication is mandated by the protocols to protect against active attacks. If communicating peers are unable to meet the authentication requirements imposed by these protocols, the result may be no communication, or plaintext communication. The ability to authenticate any potential peer on the Internet requires an authentication mechanism that encompasses all such peers. No IETF standards for authentication meet this criteria. The Public Key Infrastructure (PKI) model employed by browsers to authenticate web servers (often called the "Web PKI" [cite]) imposes cost and management burdens that have limited its use. The trust-on-first-use (TOFU) authentication approach assumes that an unauthenticated public key obtained on first contact (and retained for future use) will be good enough to secure future communication. TOFU-based protocols, e.g., SSH [cite] work well in enterprise environments, but were not designed to scale for Internet-wide use. DNS-Based Authentication of Named Entities (DANE [RFC6698]) defines a way to distribute public keys bound to DNS names. It can provide an alterative to the Web PKI (for other than EV certificates [cite]). DANE should be used in conjunction with DNSSEC [RFC4033]. At time, DNSSEC is not sufficiently widely deployed to allow DANE to satisfy the Internet-wide, any-to-any authentication criteria noted above. Thus protocols that mandate authenticated communication cannot generally do so via DANE (at time). Internet-DraftOpportunistic SecurityAugust 2014 OCS provides a near-term approach to removing barriers to widespread use of encryption, while offering a path to authenticated, encrypted communication in the future. The primary goal of OCS is to counter attacks, consistent with the goals established in [RFC7258]. However, OCS does not preclude offering protection against active attacks, if suitable authentication capabilities are available. OCS is not intended as a substitute for authenticated, encrypted communication when such communication is already available to peers, e.g., based on TLS, IPsec, SSH, etc. To achieve widespread adoption, OCS must support incremental deployment. Incremental deployment implies that security capabilities will vary from peer to peer, perhaps for a very long time. Thus use of an OCS protocol by one peer may yield communication that is unauthenticated but encrypted, authenticated and encrypted, or plaintext. This last outcome will occur if not all parties to a communication support OCS (or if an active attack makes it appear that this is the case). OCS protocolswill attempt to establish authenticated, encrypted communication whenever both parties are capable of such, but will fallback to unauthenticated encrypted communication if authentication is not possible. Fallback to plaintext communication will occur as noted above. OCS protocols do not prohibit the use of local security policies. A security administrator may specify security policies that override opportunistic security. For example, a policy might require authenticated, encrypted communication, in contrast to the default OCS security policy. The remainder of this document provides definitions of critical terms, enumerates the OCS design principles/guidelines, and provides an example of an OSC design, in the context of communication between mail relays. 2.Terminology Perfect Forward Secrecy (PFS):As defined in [RFC4949]. Man-in-the-Middle (MiTM) attack:As defined in [RFC4949]. Trust on First Use (TOFU):In a protocol, TOFU calls for accepting and storing a public key/credential associated with an asserted identity, without authenticating that assertion. Subsequent communication that is authenticated using the cached key/credential is secure against an MiTM attack, if such an attack did not succeed during the (vulnerable) initial communication.The SSH protocol makes use of TOFU.The phrase "leap of faith" (LoF, [RFC4949]) is sometimes used as a synonym. [note that this is still not quite correct. In an enterprise environment it is common for the enterprise to provide an out-of-band means of verifying the asserted identity, e.g., based on the hash of the public key.] One-way and Two-way Authentication DukhovniExpires February 16, 2015[Page 3] Internet-DraftOpportunistic SecurityAugust 2014 3. Opportunistic Crypto-Security Design Principles As noted in Section 1, OCS aims to remove barriers to the widespread use of encryption on the Internet. A secondary goal is protection against active attacks, by enabling incremental deployment of authenticated, encrypted communication. OCS seeks to achieve the best protection possible, based on the capabilities of communicating peers. 1.Determine Peer Security Capabilities: An OCS protocol first determines the capabilities of the peer with which it is attempting to communicate. Peer capabilities may be discovered by out-of-band or in-band means. (Inband determination implies negotiation between peers. Out-of-band mechanism include the use of DANE records or cached keys/credentials acquired via TOFU.) The capability phase determination may indicate that the peer supports authenticated, encrypted communication, unauthenticated encrypted communication, or only plaintext communication. (Note that use of out-of-band capability determine, e.g., DANE or TOFU, is downgrade resistant, and thus preferred over in-band negotiation techniques. The goal of this design principle is to maximize the offered security services on a pairwise, peer basis. 2.Apply Security Policy: Having determined peer security capabilities, an OCS protocol next applies any local security polices in addition to the default OCS policy (see below). Local policies may require security services in addition to encryption, e.g., authentication. A policy might restrict the set of algorithms that are employed (for encryption, authentication, integrity, etc.) The OCS default policy is simple: establish encrypted communication if possible; authenticate the peer if the capability exists; revert to plaintext if encrypted communication is not possible. Reverting to plaintext merely because authentication was not possible is inconsistent with the default policy! However, explicit, local policy overrides the default OCS policy. 3.Employ Perfect Forward Secrecy:OCS protocols SHOULD employ PFS to protect previously recorded encrypted communication from decryption even after a compromise of long-term keys. 4. No misrepresentation of security:Unauthenticated encrypted communication must not be misrepresented to users (or in logs) of non-interactive applications as equivalent to communication over an authenticated encrypted channel. This principle is consistent with the goal of not encouraging use of OCS in lieu of protocols that offer additional security services, when such protocols can be employed successfully. DukhovniExpires February 16, 2015[Page 4] Internet-DraftOpportunistic SecurityAugust 2014 4.Example: Opportunistic TLS in SMTP Many Message Transfer Agents (MTAs, [RFC5598]) support the STARTTLS ([RFC3207]) ESMTP extension.MTAs acting as SMTP clients are generally willing to send email without TLS (and therefore without encryption), but will employ TLS (and therefore encryption) when the SMTP server announces STARTTLS support.Since the initial ESMTP negotiation is not cryptographically protected, the STARTTLS advertisement is vulnerable to MiTM downgrade attacks.Further, MTAs do not generally require peer authentication.Thus the use of STARTTLS for SMTP protects only against passive attacks. MTAs that implement STARTTLS establish either an authenticated, encrypted session or deliver messages over a plaintext channel. Recent reports [cite?] from a number of large providers suggest that the majority of SMTP email transmission on the Internet is now encrypted, and the trend is toward increasing adoption. The STARTTLS advertisement is vulnerable to active attacks and some MTAs that advertise STARTTLS exhibit various interoperability problems in their implementations.As a result, it is common for a pair of STARTTLS-enabled MTAs to fall back to plaintext communication when the TLS handshake fails, or when TLS fails during message transmission.This is a reasonable trade-off, consistent with OCS principles, since STARTTLS protects against only passive attacks; absent an active attack TLS failures are simply interoperability problems. Some MTAs employing STARTTLS abandon the TLS handshake when the peer MTA fails authentication, only to immediately deliver the same message over a plaintext connection.Other MTAs have been observed to tolerate unverified self-signed certificates, but not expired certificates, again falling back to plaintext.These and similar behaviors are NOT consistent with OCS principles, since they revert to plaintext communication when authentication fails, instead of employing unauthenticated, encryption, communication. Protection against active attacks for SMTP is described in [I-D.ietf-dane-smtp-with-dane].That draft introduces the terms "Opportunistic TLS" and "Opportunistic DANE TLS"; this draft is consistent with the OCS design principles defined in this document. DukhovniExpires February 16, 2015[Page 5] Internet-DraftOpportunistic SecurityAugust 2014 6.Security Considerations OCS supports communication that is authenticated and encrypted, unauthenticated and encrypted, or plaintext. The security services offered to communicating peers is not reduced by the use of OCS. This is because the default OCS policy employs the best security services available based on the capabilities of the peers, and because local security policies take precedence over the default OCS policy. OCS is an improvement over the status quo; it provides better security than the alternative of providing no security services when authentication is not possible (and not strictly required) OCS coexists with and is preempted by local, non-OCS security polices. Non-OCS policies may inhibit use of encryption when many peers cannot offer authenticated, encrypted communication. Unless authenticated, encrypted communication is necessary, non-OCS local policies of this sort run counter to the goals established in [RFC7258]. 7.Acknowledgements I would like to thank Steve Kent.Some of the text in this document is based on his earlier draft.I would like to thank Dave Crocker, Peter Duchovni, Paul Hoffman, Scott Kitterman, Martin Thomson, Nico Williams, Paul Wouters and Stephen Farrell for their helpful suggestions and support. 8.References 8.1.Normative References [RFC3207]Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. [RFC4033]Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC5116]McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008. [RFC5246]Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC6125]Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011. DukhovniExpires February 16, 2015[Page 6] Internet-DraftOpportunistic SecurityAugust 2014 [RFC6698]Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012. 8.2.Informative References [I-D.ietf-dane-smtp-with-dane] Dukhovni, V. and W. Hardaker, "SMTP security via opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-11 (work in progress), August 2014. [RFC4949]Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC5598]Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. [RFC7258]Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014. Author's Address Viktor Dukhovni Two Sigma Email: ietf-dane@dukhovni.org DukhovniExpires February 16, 2015[Page 7] --------------020901080302030201070300 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen,

Steve,

On 18/08/14 22:18, Stephen Kent wrote:

short of re-writing it for him, I don't
see how to fix this mess.

I think that's going too far and is disrespectful
to Viktor and to those others who have expressed
support for the document. That's especially egregious
given that you haven't even bothered to compare
-03 to the earlier on-list discussion.
You are right that I failed to compare the released -03 version to
the pre-release version. When I began to read the released -03 version
I noted that almost none of the suggested changes appeared in the
abstract or in most of section 1, which promoted my reply. But, I agree
that I should have read the rest of the doc before commenting.
Now that I have read the whole doc, I see that Viktor did adopt make changes
reflecting some of my comments, though not consistently. My apologies for
not reading the entirety of the new version before commenting.

Still, I stand by my comments that the doc was still badly written, though it
was better in several respects.  The fact that some others have commented that
they find the quality of the  writing to be acceptable does not change reality.
I also note that several of those expressing support for the writing (not the design
per se) have authored very few RFCs.

Please provide a detailed description of how -03
does or does not map to the earlier mailing list
discussion.

I've done better that than. I have re-written the doc with an
intent to address all of the issues I raised, retaining the
design principles in the latest version, eliminating a lot of redundant text,
and using less ambiguous language. The result is much shorter and, in my view,
clearer and better organized.

Steve
----------

 

Network Working Group                                        V. Dukhovni

Internet-Draft                                                 Two Sigma

Intended status: Informational                           August 15, 2014

Expires: February 16, 2015

 

 

        Opportunistic Security: Some Protection Most of the Time

                draft-dukhovni-opportunistic-security-03

 

Abstract

 

   This memo introduces the concept "Opportunistic Crypto-Security"

   (OCS). OCS is a set of protocol design principles that attempt to

   remove  barriers to the widespread use of encryption on the Internet.

   OCS is not a protocol. Protocols that adhere to OCS guidelines may

   offer additional crypto-security services, e.g., integrity and

   authentication, if these services are supported by all parties

   to a communication. The OCS design philosophy departs from the

   common practice of other Internet security protocols; they commonly

   require cryptographic protection against both passive and active

   attacks, or offer no protection at all.  OCS protocols strive to

   offer encryption  even if authentication is not available.  This

   document encourages designs in which cryptographic protection

   against both passive and active attacks can be deployed

   incrementally, without creating barriers to communication.

 

Status of This Memo

 

   This Internet-Draft is submitted in full conformance with the

   provisions of BCP 78 and BCP 79.

 

   Internet-Drafts are working documents of the Internet Engineering

   Task Force (IETF).  Note that other groups may also distribute

   working documents as Internet-Drafts.  The list of current Internet-

   Drafts is at http://datatracker.ietf.org/drafts/current/.

 

   Internet-Drafts are draft documents valid for a maximum of six months

   and may be updated, replaced, or obsoleted by other documents at any

   time.  It is inappropriate to use Internet-Drafts as reference

   material or to cite them other than as "work in progress."

 

   This Internet-Draft will expire on February 16, 2015.

 

Copyright Notice

 

   Copyright (c) 2014 IETF Trust and the persons identified as the

   document authors.  All rights reserved.

 

 

 

Dukhovni                Expires February 16, 2015               [Page 1]

 

Internet-Draft           Opportunistic Security              August 2014

 

 

   This document is subject to BCP 78 and the IETF Trust's Legal

   Provisions Relating to IETF Documents

   (http://trustee.ietf.org/license-info) in effect on the date of

   publication of this document.  Please review these documents

   carefully, as they describe your rights and restrictions with respect

   to this document.

 

Table of Contents

 

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2

   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4

   3.  The Opportunistic Security Design Pattern . . . . . . . . . .   5

   4.  Opportunistic Security Design Principles  . . . . . . . . . .   7

   5.  Example: Opportunistic TLS in SMTP  . . . . . . . . . . . . .   8

   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9

   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9

   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9

     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9

     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10

   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

 

1.  Introduction

 

   The development of Opportunistic Crypto-Security (OCS) is motivated

   by the concerns raised in [RFC7258]. Pervasive monitoring (as defined

   in that RFC) is feasible because of the lack of widespread use of

   encryption for confidentiality. Although the IETF has developed many

   security protocols (e.g., TLS, IPsec, SSH, …) that employ encryption

   for confidentiality, most of them also require one-way or two-way

   authentication. Authentication is mandated by the protocols to protect

   against active attacks. If communicating peers are unable to meet the

   authentication requirements imposed by these protocols, the result may

   be no communication, or plaintext communication.

 

   The ability to authenticate any potential peer on the Internet requires

   an authentication mechanism that encompasses all such peers. No IETF

   standards for authentication meet this criteria. The Public Key

   Infrastructure (PKI) model employed by browsers to authenticate web

   servers (often called the "Web PKI" [cite]) imposes cost and management

   burdens that have limited its use. The trust-on-first-use (TOFU)

   authentication approach assumes that an unauthenticated public key

   obtained on first contact (and retained for future use) will be good

   enough to secure future communication. TOFU-based protocols, e.g., SSH

   [cite] work well in enterprise environments, but were not designed to

   scale for Internet-wide use.

 

   DNS-Based Authentication of Named Entities (DANE [RFC6698]) defines a

   way to distribute public keys bound to DNS names. It can provide an

   alterative to the Web PKI (for other than EV certificates [cite]).

   DANE should be used in conjunction with DNSSEC [RFC4033]. At time,

   DNSSEC is not sufficiently widely deployed to allow DANE to satisfy the

   Internet-wide, any-to-any authentication criteria noted above. Thus

   protocols that mandate authenticated communication cannot generally

   do so via DANE (at time).

Internet-Draft           Opportunistic Security              August 2014

 

 

 

   OCS provides a near-term approach to removing barriers to widespread

   use of encryption, while offering a path to authenticated, encrypted

   communication in the future. The primary goal of OCS is to counter

   attacks, consistent with the goals established in [RFC7258]. However,

   OCS does not preclude offering protection against active attacks, if

   suitable authentication capabilities are available. OCS is not intended

   as a substitute for authenticated, encrypted communication when such

   communication is already available to peers, e.g., based on TLS, IPsec,

   SSH, etc.

 

   To achieve widespread adoption, OCS must support incremental deployment.

   Incremental deployment implies that security capabilities will vary

   from peer to peer, perhaps for a very long time. Thus use of an OCS

   protocol by  one peer may yield communication that is unauthenticated

   but encrypted, authenticated and encrypted, or plaintext. This last

   outcome  will occur if not all parties to a communication support OCS

  (or if an active attack makes it appear that this is the case). OCS

   protocols  will attempt to establish authenticated, encrypted

   communication whenever both parties are capable of such, but will

   fallback to unauthenticated encrypted communication if authentication

   is not possible. Fallback to plaintext communication will occur as

   noted above.

 

   OCS protocols do not prohibit the use of local security policies. A

   security administrator may specify security policies that  override

   opportunistic security. For example, a policy might require authenticated,

   encrypted communication, in contrast to the default OCS security policy.

 

   The remainder of this document provides definitions of critical terms,

   enumerates the OCS design principles/guidelines, and provides an example

   of an OSC design, in the context of communication between mail relays.

 

 

2.  Terminology

 

   Perfect Forward Secrecy (PFS):  As defined in [RFC4949].

 

   Man-in-the-Middle (MiTM) attack:  As defined in [RFC4949].

 

   Trust on First Use (TOFU):  In a protocol, TOFU calls for accepting

      and storing a public key/credential associated with an asserted

      identity, without authenticating that assertion. Subsequent

      communication that is authenticated using the cached key/credential

      is secure against an MiTM attack, if such an attack did not

      succeed during the (vulnerable) initial communication.  The

      SSH protocol makes use of TOFU.  The phrase "leap of faith" (LoF,

      [RFC4949]) is sometimes used as a synonym.

[note that this is still not quite correct. In an enterprise environment it

is common for the enterprise to provide an out-of-band means of verifying the
asserted identity, e.g., based on the hash of the public key.]

 

   One-way and Two-way Authentication <fill in>

 

 

Dukhovni                Expires February 16, 2015               [Page 3]

 

Internet-Draft           Opportunistic Security              August 2014

 

 

 

3. Opportunistic Crypto-Security Design Principles

 

   As noted in Section 1, OCS aims to remove barriers to the

   widespread use of encryption on the Internet. A secondary goal is

   protection against active attacks, by enabling incremental

   deployment of authenticated, encrypted communication. OCS seeks

   to achieve the best protection possible, based on the capabilities

   of communicating peers.

 

1.  Determine Peer Security Capabilities: An OCS protocol first

determines the capabilities of the peer with which it is attempting

       to communicate. Peer capabilities may be discovered by out-of-band

       or in-band means. (Inband determination implies negotiation between

       peers. Out-of-band mechanism include the use  of DANE records or

       cached keys/credentials acquired via TOFU.) The capability phase

       determination may indicate that the  peer supports authenticated,

       encrypted communication, unauthenticated encrypted communication,

       or only plaintext communication. (Note that use of out-of-band

       capability determine, e.g., DANE or TOFU, is downgrade resistant,

       and thus preferred over in-band negotiation techniques. The goal

       of this design principle is to maximize the offered security

       services on a pairwise, peer basis.

  

2.  Apply Security Policy: Having determined peer security

capabilities, an OCS protocol next applies any local security polices

in addition to the default OCS policy (see below). Local policies may
require security services in addition to encryption, e.g., authentication.
A policy might restrict the set of algorithms that are employed (for encryption,
authentication, integrity, etc.) The OCS default policy is simple: establish
encrypted communication if possible; authenticate the peer if the capability
exists; revert to plaintext if encrypted communication is not possible.
Reverting to plaintext merely because authentication was not possible is
inconsistent with the default policy! However, explicit, local policy
overrides the default OCS policy.

 

3.  Employ Perfect Forward Secrecy:  OCS protocols SHOULD employ PFS

to  protect previously recorded encrypted communication from
decryption even after a compromise of long-term keys.

 

   4. No misrepresentation of security:  Unauthenticated encrypted

      communication must not be misrepresented to users (or in

      logs) of non-interactive applications as equivalent to

      communication over an authenticated encrypted channel. This principle

      is consistent with the goal of not encouraging use of OCS in lieu of

      protocols that offer additional security services, when such protocols

      can be employed successfully.

 

 

 

 

 

 

Dukhovni                Expires February 16, 2015               [Page 4]

 

 

Internet-Draft           Opportunistic Security              August 2014

 

 

 

4.  Example: Opportunistic TLS in SMTP

 

   Many Message Transfer Agents (MTAs, [RFC5598]) support the STARTTLS

   ([RFC3207]) ESMTP extension.  MTAs acting as SMTP clients are

   generally willing to send email without TLS (and therefore without

   encryption), but will employ TLS (and therefore encryption) when the

   SMTP server announces STARTTLS support.  Since the initial ESMTP

   negotiation is not cryptographically protected, the STARTTLS

   advertisement is vulnerable to MiTM downgrade attacks.  Further, MTAs

   do not generally require peer authentication.  Thus the use of STARTTLS

   for SMTP protects only against passive attacks.

 

   MTAs that implement STARTTLS establish either an authenticated,

   encrypted session or deliver messages over a plaintext channel.

   Recent reports [cite?] from a number of large providers suggest

   that the  majority of SMTP email transmission on the Internet is now

   encrypted, and the trend is toward increasing adoption.

 

   The STARTTLS advertisement is vulnerable to active attacks and

   some MTAs that advertise STARTTLS exhibit various interoperability

   problems in their implementations.  As a result, it is common for a

   pair of STARTTLS-enabled MTAs to fall back to plaintext

   communication when the TLS handshake fails, or when TLS fails during

   message transmission.  This is a reasonable trade-off, consistent with

   OCS principles, since STARTTLS protects against only passive

   attacks; absent an active attack TLS failures are simply

   interoperability problems.

 

   Some MTAs employing STARTTLS abandon the TLS handshake when the

   peer MTA fails authentication, only to immediately deliver

   the same message over a plaintext connection.  Other MTAs have been

   observed to tolerate unverified self-signed certificates, but not

   expired certificates, again falling back to plaintext.  These and

   similar behaviors are NOT consistent with OCS principles, since

   they revert to plaintext communication when authentication fails,

   instead of employing unauthenticated, encryption, communication.

 

   Protection against active attacks for SMTP is described in

   [I-D.ietf-dane-smtp-with-dane].  That draft introduces the terms

   "Opportunistic TLS" and "Opportunistic DANE TLS"; this draft is

   consistent with the OCS design principles defined in this document.

 

 

 

 

Dukhovni                Expires February 16, 2015               [Page 5]

 

Internet-Draft           Opportunistic Security              August 2014

 

 

6.  Security Considerations

 

   OCS supports communication that is authenticated and encrypted,

   unauthenticated and encrypted, or plaintext. The security services

   offered to communicating peers is not reduced by the use of OCS.

   This is because the default OCS policy employs the best security

   services available based on the capabilities of the peers, and

   because local security policies take precedence over the default

   OCS policy. OCS is an improvement over the status quo; it provides

   better security than the alternative of providing no security services

   when authentication is not possible (and not strictly required)

 

   OCS coexists with and is preempted by local, non-OCS security polices.

   Non-OCS policies may inhibit use of encryption when many peers cannot

   offer authenticated, encrypted communication. Unless authenticated,

   encrypted communication is necessary, non-OCS local policies of this

   sort run counter to the goals established in [RFC7258].

 

7.  Acknowledgements

 

   I would like to thank Steve Kent.  Some of the text in this document

   is based on his earlier draft.  I would like to thank Dave Crocker,

   Peter Duchovni, Paul Hoffman, Scott Kitterman, Martin

   Thomson, Nico Williams, Paul Wouters and Stephen Farrell for their

   helpful suggestions and support.

 

8.  References

 

8.1.  Normative References

 

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over

              Transport Layer Security", RFC 3207, February 2002.

 

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.

              Rose, "DNS Security Introduction and Requirements", RFC

              4033, March 2005.

 

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated

              Encryption", RFC 5116, January 2008.

 

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security

              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

 

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and

              Verification of Domain-Based Application Service Identity

              within Internet Public Key Infrastructure Using X.509

              (PKIX) Certificates in the Context of Transport Layer

              Security (TLS)", RFC 6125, March 2011.

 

 

 

Dukhovni                Expires February 16, 2015               [Page 6]

 

Internet-Draft           Opportunistic Security              August 2014

 

 

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication

              of Named Entities (DANE) Transport Layer Security (TLS)

              Protocol: TLSA", RFC 6698, August 2012.

 

8.2.  Informative References

 

   [I-D.ietf-dane-smtp-with-dane]

              Dukhovni, V. and W. Hardaker, "SMTP security via

              opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-11

              (work in progress), August 2014.

 

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2", RFC

              4949, August 2007.

 

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598, July

              2009.

 

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an

              Attack", BCP 188, RFC 7258, May 2014.

 

Author's Address

 

   Viktor Dukhovni

   Two Sigma

 

   Email: ietf-dane@dukhovni.org

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Dukhovni                Expires February 16, 2015              [Page 7]

 


--------------020901080302030201070300-- From nobody Tue Aug 19 08:39:35 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B8F1A03C8; Tue, 19 Aug 2014 08:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnH6EWPTkmCs; Tue, 19 Aug 2014 08:39:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DCC861A03BD; Tue, 19 Aug 2014 08:39:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D4045BE87; Tue, 19 Aug 2014 16:39:29 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx-9cgtBaLg1; Tue, 19 Aug 2014 16:39:29 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B12CBBE10; Tue, 19 Aug 2014 16:39:29 +0100 (IST) Message-ID: <53F36FB1.4020008@cs.tcd.ie> Date: Tue, 19 Aug 2014 16:39:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Stephen Kent , saag@ietf.org, "ietf@ietf.org" References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> <53F26D8A.1050304@bbn.com> <53F27065.9030902@cs.tcd.ie> <53F36E34.7020701@bbn.com> In-Reply-To: <53F36E34.7020701@bbn.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/SHX-oxot63ovv0VZG4uGqjd8jcw Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 15:39:32 -0000 Hiya, On 19/08/14 16:33, Stephen Kent wrote: > You are right that I failed to compare the released -03 version to > the pre-release version. When I began to read the released -03 version > I noted that almost none of the suggested changes appeared in the > abstract or in most of section 1, which promoted my reply. But, I agree > that I should have read the rest of the doc before commenting. > Now that I have read the whole doc, I see that Viktor did adopt make > changes > reflecting some of my comments, though not consistently. My apologies for > not reading the entirety of the new version before commenting. Thanks. And thanks for the substantial suggested text. I'm sure Viktor will process that as soon he can. (I'll also do a diff of this vs. -03, if you have text in an easier to diff form that'd be great to send to Viktor, Paul and I or whack up on a web site somewhere.) Cheers, S. From nobody Tue Aug 19 08:45:55 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B380A1A0402; Tue, 19 Aug 2014 08:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnbYx8FroBW8; Tue, 19 Aug 2014 08:45:51 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD0E11A0439; Tue, 19 Aug 2014 08:45:49 -0700 (PDT) X-AuditID: 12074424-f79346d000004923-e5-53f3712c0f2c Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 90.EB.18723.C2173F35; Tue, 19 Aug 2014 11:45:48 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s7JFjlgE019173; Tue, 19 Aug 2014 11:45:47 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7JFjjix031063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Aug 2014 11:45:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7JFjip0007177; Tue, 19 Aug 2014 11:45:44 -0400 (EDT) Date: Tue, 19 Aug 2014 11:45:44 -0400 (EDT) From: Benjamin Kaduk To: Stephen Kent In-Reply-To: <53F36FB1.4020008@cs.tcd.ie> Message-ID: References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> <53F26D8A.1050304@bbn.com> <53F27065.9030902@cs.tcd.ie> <53F36E34.7020701@bbn.com> <53F36FB1.4020008@cs.tcd.ie> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUixCmqratT+DnY4MoCNYtnG+ezWGyczWgx pb+TyYHZY+r5UI8lS34yBTBFcdmkpOZklqUW6dslcGX0bH/FWLCRuWLjygbmBsYTTF2MnBwS AiYS++5dY4GwxSQu3FvP1sXIxSEkMJtJ4uuqR4wQzkZGiQtzL0A5h5gkNtydwArhNDBKHNky jRGkn0VAW2LV3hY2EJtNQEVi5puNYLaIgLzEt2NbwXYwCxhJfO+aBLZbWKBQ4uauDrAaTgFN iVXzO8Hm8Ao4ShxtnY+wbe6vyWBFogI6Eqv3T2GBKBKUODnzCdRQLYnl07exTGAUnIUkNQtJ agEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdc73czBK91JTSTYygoGV3UdnB2HxI6RCjAAej Eg+vQvbnYCHWxLLiytxDjJIcTEqivJ05QCG+pPyUyozE4oz4otKc1OJDjBIczEoivJf9gHK8 KYmVValF+TApaQ4WJXHet9ZWwUIC6YklqdmpqQWpRTBZGQ4OJQne1/lAjYJFqempFWmZOSUI aSYOTpDhPEDDxQtAhhcXJOYWZ6ZD5E8x6nK0NL3tZRJiycvPS5US580GKRIAKcoozYObA0s2 rxjFgd4S5n0Eso4HmKjgJr0CWsIEtGTr4o8gS0oSEVJSDYz6vnE7JOaYZb94b69U61Ululrp 8Km1Ep+m12dHMEaIccRlJkt6vpaP29Tqm8Lk/+9LxpPGuqNzEn7befTbvOj+d+3U4aDEQkdn XY6un0lvPG35XIQFnjCaGM5heBK5baFfts1SpahNcQevX2Ntajj8++aT2SevGzfrPHbLXXSa f4/Yx5raV0osxRmJhlrMRcWJAJGn/fgRAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/saag/tWkNA1dp374X2YWfM9PvNHQbWEU Cc: saag@ietf.org, "ietf@ietf.org" Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 15:45:52 -0000 On Tue, 19 Aug 2014, Stephen Farrell wrote: > > I'm sure Viktor will process that as soon he can. (I'll > also do a diff of this vs. -03, if you have text in an > easier to diff form that'd be great to send to Viktor, > Paul and I or whack up on a web site somewhere.) Yes, can you please post this somewhere? The formatting got very badly mandled in the email processing and it is quite hard to read. Thanks, Ben From nobody Tue Aug 19 08:51:29 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4376F1A048E; Tue, 19 Aug 2014 08:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_HTML_ATTACH=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMetJVYUnZOE; Tue, 19 Aug 2014 08:51:19 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C901A0457; Tue, 19 Aug 2014 08:51:18 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7JFowjl023169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Aug 2014 08:51:01 -0700 Message-ID: <53F371CC.7020106@dcrocker.net> Date: Tue, 19 Aug 2014 08:48:28 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , Stephen Kent , saag@ietf.org, "ietf@ietf.org" References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> <53F26D8A.1050304@bbn.com> <53F27065.9030902@cs.tcd.ie> <53F36E34.7020701@bbn.com> <53F36FB1.4020008@cs.tcd.ie> In-Reply-To: <53F36FB1.4020008@cs.tcd.ie> Content-Type: multipart/mixed; boundary="------------020000040301070601090501" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 19 Aug 2014 08:51:02 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/iyclhe5DLwDlBTjejMjRjZGk8ho Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 15:51:24 -0000 This is a multi-part message in MIME format. --------------020000040301070601090501 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 8/19/2014 8:39 AM, Stephen Farrell wrote: > also do a diff of this vs. -03, attached -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------020000040301070601090501 Content-Type: text/html; charset=ISO-8859-1; name="Diff draft-dukhovni-opportunistic-security-03.txt - draft-dukhovni-opportunistic-security-03-kent.txt.htm" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename*0="Diff draft-dukhovni-opportunistic-security-03.txt - draft-d"; filename*1="ukhovni-opportunistic-security-03-kent.txt.htm" Diff: draft-dukhovni-opportunistic-security-03.txt - draft-dukhovni-opportunistic-security-03-kent.txt
< draft-dukhovni-opportunistic-security-03.txt   draft-dukhovni-opportunistic-security-03-kent.txt >
Network Working Group V. Dukhovni Network Working Group V. Dukhovni
Internet-Draft Two Sigma Internet-Draft Two Sigma
Intended status: Informational August 15, 2014 Intended status: Informational August 15, 2014
Expires: February 16, 2015 Expires: February 16, 2015
Opportunistic Security: Some Protection Most of the Time Opportunistic Security: Some Protection Most of the Time
draft-dukhovni-opportunistic-security-03 draft-dukhovni-opportunistic-security-03
Abstract Abstract
This memo introduces the "Opportunistic Security" (OS) protocol This memo introduces the concept "Opportunistic Crypto-Security"
design pattern. Protocol designs based on OS depart from the (OCS). OCS is a set of protocol design principles that attempt to
established practice of employing cryptographic protection against remove barriers to the widespread use of encryption on the Internet.
both passive and active attacks, or no protection at all. As a OCS is not a protocol. Protocols that adhere to OCS guidelines may
result, with OS at least some cryptographic protection should be offer additional crypto-security services, e.g., integrity and
provided most of the time. For example, the majority of Internet authentication, if these services are supported by all parties
SMTP traffic is now opportunistically encrypted. OS designs remove to a communication. The OCS design philosophy departs from the
barriers to the widespread use of encryption on the Internet. The common practice of other Internet security protocols; they commonly
actual protection provided by opportunistic security depends on the require cryptographic protection against both passive and active
advertised security capabilities of the communicating peers. attacks, or offer no protection at all. OCS protocols strive to
offer encryption even if authentication is not available. This
This document promotes designs in which cryptographic protection document encourages designs in which cryptographic protection
against both passive and active attacks can be rolled out against both passive and active attacks can be deployed
incrementally as new systems are deployed, without creating barriers incrementally, without creating barriers to communication.
to communication.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 2, line 28 skipping to change at page 3, line ?
5. Example: Opportunistic TLS in SMTP . . . . . . . . . . . . . 8 5. Example: Opportunistic TLS in SMTP . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Historically, Internet security protocols have emphasized The development of Opportunistic Crypto-Security (OCS) is motivated
comprehensive "all or nothing" cryptographic protection against both by the concerns raised in [RFC7258]. Pervasive monitoring (as defined
passive and active attacks. With each peer, such a protocol achieves in that RFC) is feasible because of the lack of widespread use of
either full protection or else total failure to communicate (hard encryption for confidentiality. Although the IETF has developed many
fail). As a result, operators often disable these security protocols security protocols (e.g., TLS, IPsec, SSH, …) that employ encryption
at the first sign of trouble, degrading all communications to for confidentiality, most of them also require one-way or two-way
cleartext transmission. Protection against active attacks requires authentication. Authentication is mandated by the protocols to protect
authentication. The ability to authenticate any potential peer on against active attacks. If communicating peers are unable to meet the
the Internet requires a key management approach that works for all. authentication requirements imposed by these protocols, the result may
be no communication, or plaintext communication.
Designing and deploying a key management for the whole Internet is
for now an unsolved problem. For example, the Public Key
Infrastructure (PKI) used by the web (often called the "Web PKI") is
based on broadly trusted public certification authorities (CAs). The
Web PKI has too many trusted authorities and imposes burdens that not
all peers are willing to bear. Web PKI authentication is vulnerable
to MiTM attacks when the peer reference identifier ([RFC6125]) is
obtained indirectly over an insecure channel, perhaps via an MX or
SRV lookup. With so many certification authorities, which not
everyone is willing to trust, the communicating parties don't always
agree on a mutually trusted CA. Without a mutually trusted CA,
authentication fails, leading to communications failure. The above
issues are compounded by operational difficulties. For example, a
common problem is for site operators to forget to perform timely
renewal of expiring certificates. In interactive applications,
security warnings are all too frequent, and end-users learn to
actively ignore security problems.
DNS Security (DNSSEC [RFC4033]) can be used to leverage the global
DNS infrastructure as a distributed authentication system. DNS-Based
Authentication of Named Entities (DANE [RFC6698]) provides the
guidelines and DNS records to use the DNS as an alternative to the
Web PKI. However, at this time, DNSSEC is not sufficiently widely
adopted to allow DANE to play the role of an Internet-wide any-to-any
authentication system. Therefore, protocols that mandate
authentication for all peers cannot generally do so via DANE.
Opportunistic security protocols on the other hand, can begin to use
DANE immediately, without waiting for universal adoption.
Other authentication mechanisms have been designed that do not rely
on trusted third parties. The trust-on-first-use (TOFU)
authentication approach makes a leap of faith (LoF, [RFC4949]) by
assuming that unauthenticated public keys obtained on first contact
will likely be good enough to secure future communication. TOFU is
employed in SSH and in various certificate pinning designs. TOFU
does not protect against an attacker who can hijack the first contact
communication and requires more care from the end-user when systems
update their cryptographic keys. TOFU can make it difficult to
distinguish routine system administration from a malicious attack.
The lack of a global key management system means that for many
protocols only a minority of communications sessions can be
authenticated. When protocols only offer the choice between an
authenticated encrypted channel or no protection, the result is that
most traffic is sent in cleartext. The fact that most traffic is not
encrypted makes pervasive monitoring easier by making it cost-
effective, or at least not cost-prohibitive; see [RFC7258] for more
detail.
To reach broad adoption, it must be possible to roll out support for The ability to authenticate any potential peer on the Internet requires
unauthenticated encryption or authentication incrementally. an authentication mechanism that encompasses all such peers. No IETF
Incremental rollout on the scale of the Internet means that for some standards for authentication meet this criteria. The Public Key
considerable time security capabilities vary from peer to peer, and Infrastructure (PKI) model employed by browsers to authenticate web
therefore protection against passive and active attacks needs to be servers (often called the "Web PKI" [cite]) imposes cost and management
applied selectively peer by peer. burdens that have limited its use. The trust-on-first-use (TOFU)
authentication approach assumes that an unauthenticated public key
obtained on first contact (and retained for future use) will be good
enough to secure future communication. TOFU-based protocols, e.g., SSH
[cite] work well in enterprise environments, but were not designed to
scale for Internet-wide use.
We will use the phrase "opportunistically employed" to mean that the DNS-Based Authentication of Named Entities (DANE [RFC6698]) defines a
use of a type of protection or a security mechanism was tailored to way to distribute public keys bound to DNS names. It can provide an
the advertised capabilities of the peer. Both opportunistically alterative to the Web PKI (for other than EV certificates [cite]).
employed encryption and opportunistically employed authentication DANE should be used in conjunction with DNSSEC [RFC4033]. At time,
need to avoid deployment roadblocks and need to be designed with care DNSSEC is not sufficiently widely deployed to allow DANE to satisfy the
to "just work". Internet-wide, any-to-any authentication criteria noted above. Thus
protocols that mandate authenticated communication cannot generally
do so via DANE (at time).
To enable broader use of encryption, it must be possible to OCS provides a near-term approach to removing barriers to widespread
opportunistically employ encryption with peers that support it use of encryption, while offering a path to authenticated, encrypted
without always demanding authentication. This defends against communication in the future. The primary goal of OCS is to counter
pervasive monitoring and other passive attacks, as even attacks, consistent with the goals established in [RFC7258]. However,
unauthenticated encryption (see definition in Section 2) is OCS does not preclude offering protection against active attacks, if
preferable to cleartext. suitable authentication capabilities are available. OCS is not intended
as a substitute for authenticated, encrypted communication when such
communication is already available to peers, e.g., based on TLS, IPsec,
SSH, etc.
The opportunistic security design pattern involves stepping up from a To achieve widespread adoption, OCS must support incremental deployment.
baseline security policy compatible with all relevant peers to the Incremental deployment implies that security capabilities will vary
most secure policy compatible with the capabilities of a given peer. from peer to peer, perhaps for a very long time. Thus use of an OCS
Note, this is rather different from setting a high standard and protocol by one peer may yield communication that is unauthenticated
attempting to determine (perhaps by asking the user) whether an but encrypted, authenticated and encrypted, or plaintext. This last
exception can be made. outcome will occur if not all parties to a communication support OCS
(or if an active attack makes it appear that this is the case). OCS
protocols will attempt to establish authenticated, encrypted
communication whenever both parties are capable of such, but will
fallback to unauthenticated encrypted communication if authentication
is not possible. Fallback to plaintext communication will occur as
noted above.
The risk of active attacks should not be ignored. The opportunistic OCS protocols do not prohibit the use of local security policies. A
security design pattern recommends that protocols employ multiple security administrator may specify security policies that override
cryptographic protection levels, with encrypted transmission opportunistic security. For example, a policy might require authenticated,
accessible to most if not all peers. Protocol designers are encrypted communication, in contrast to the default OCS security policy.
encouraged to produce protocols that can securely determine which
peers support authentication, and can then establish authenticated
communication channels resistant to active attacks with those peers.
Operators must be able specify explicit security policies that The remainder of this document provides definitions of critical terms,
override opportunistic security where appropriate. enumerates the OCS design principles/guidelines, and provides an example
of an OSC design, in the context of communication between mail relays.
2. Terminology 2. Terminology
Perfect Forward Secrecy (PFS): As defined in [RFC4949]. Perfect Forward Secrecy (PFS): As defined in [RFC4949].
Man-in-the-Middle (MiTM) attack: As defined in [RFC4949]. Man-in-the-Middle (MiTM) attack: As defined in [RFC4949].
Trust on First Use (TOFU): In a protocol, TOFU typically consists of Trust on First Use (TOFU): In a protocol, TOFU calls for accepting
accepting and storing an asserted identity, without authenticating and storing a public key/credential associated with an asserted
that assertion. Subsequent communication using the cached key/ identity, without authenticating that assertion. Subsequent
credential is secure against an MiTM attack, if such an attack did communication that is authenticated using the cached key/credential
not succeed during the (vulnerable) initial communication. The is secure against an MiTM attack, if such an attack did not
succeed during the (vulnerable) initial communication. The
SSH protocol makes use of TOFU. The phrase "leap of faith" (LoF, SSH protocol makes use of TOFU. The phrase "leap of faith" (LoF,
[RFC4949]) is sometimes used as a synonym. [RFC4949]) is sometimes used as a synonym.
[note that this is still not quite correct. In an enterprise environment it
is common for the enterprise to provide an out-of-band means of verifying the
asserted identity, e.g., based on the hash of the public key.]
Authenticated encryption: Encryption using a session establishment One-way and Two-way Authentication <fill in>
method in which at least the initiator (client) authenticates the
identity of the acceptor (server). This is required to protect
against both passive and active attacks. Authenticated encryption
can be one-sided, where only the client authenticates the server.
One-sided authentication of the server by the client is the most
common deployment used with Transport Layer Security (TLS,
[RFC5246]) for "secure browsing" in which client authentication is
typically performed at another layer in the protocol.
Authenticated encryption can also be two-sided or "mutual".
Mutual authentication plays a role in mitigating active attacks
when the client and server roles change in the course of a single
session. Authenticated encryption is not synonymous with use of
AEAD [RFC5116]. AEAD algorithms can be used with either
authenticated or unauthenticated peers.
Unauthenticated Encryption: Encryption using a session establishment
method that does not authenticate the identities of the peers. In
typical usage, this means that the initiator (client) has not
verified the identity of the target (server), making MiTM attacks
possible. Unauthenticated encryption is not synonymous with non-
use of AEAD [RFC5116].
3. The Opportunistic Security Design Pattern
Opportunistic Security is a protocol design pattern that aims to
remove barriers to the widespread use of encryption on the Internet.
A related goal is broader adoption of protection against active
attacks, by enabling incremental deployment of authenticated
encryption.
The opportunistic security design pattern supports multiple
protection levels, while seeking the best protection possible.
The determination of which security mechanisms to use can vary from
case to case and depends on the properties of the protocol in which
OS is applied. In many cases, OS will result in negotiating channels
with one of the following security properties:
o No encryption (cleartext), which provides no protection against
passive or active attacks.
o Unauthenticated encryption (definition in Section 2), which
protects only against passive attacks.
o Authenticated encryption, (definition in Section 2) which protects
against both passive and active attacks.
An opportunistic security protocol first determines the capabilities
of a peer. This might include whether that peer supports
authenticated encryption, unauthenticated encryption or perhaps only
cleartext. After each peer has determined the capabilities of the
other, the most preferred common security capabilities are activated.
Peer capabilities can be advertised out-of-band or (negotiated) in-
band.
An OS protocol may elect to apply more stringent security settings
for authenticated encryption than for unauthenticated encryption.
For example, the set of enabled TLS cipher-suites might be more
restrictive when authentication is required.
Security services that "just work" are more likely to be deployed and
enabled by default. It is vital that the capabilities advertised for
an OS-compatible peer match the deployed reality. Otherwise, OS
systems will detect such a broken deployment as an active attack and
communication may fail.
This might mean that peer capabilities are further filtered to
consider only those capabilities that are sufficiently operationally
reliable, and any that work only "some of the time" are treated by an
opportunistic security protocol as "not present" or "undefined".
Opportunistic security does not start with an over-estimate of peer
capabilities only to settle for lesser protection when a peer fails
to deliver. Rather, opportunistic security sets a minimum protection
level expected of all peers, which is raised for peers that are
capable of more.
Opportunistic security protocols should provide a means to enforce
authentication for those peers for which authentication can be
expected to succeed based on information advertised by the peer via
DANE, TOFU or other means. With DANE, the advertisement that a peer
supports authentication is downgrade-resistant. What is
"opportunistic" here is the selective use of authentication for
certain peers; much in the same way as unauthenticated encryption may
be used "opportunistically" with peers capable of more than
cleartext.
Enforcement of authentication is not incompatible with opportunistic
security. If an OS-enabled peer (A) makes available authenticated
key material, e.g., via DANE, to peer (B), then B should make use of
this material to authenticate A, if B is OS-enabled and supports
DANE.
With a peer that does not advertise authentication support, to which
transmission even in cleartext is permissible, authentication (or the
lack thereof) must never downgrade encrypted communication to
cleartext. When employing opportunistic unauthenticated encryption,
any enabled by default authentication checks need to be disabled or
configured to soft-fail, allowing the unauthenticated encrypted
session to proceed.
Cleartext support is for backwards compatibility with already
deployed systems. Even when cleartext needs to be supported,
protocol designs based on opportunistic security prefer to encrypt,
employing cleartext only with peers that do not appear to be
encryption capable.
4. Opportunistic Security Design Principles 3. Opportunistic Crypto-Security Design Principles
Coexist with explicit policy: Explicit security policy preempts As noted in Section 1, OCS aims to remove barriers to the
opportunistic security. Administrators or users can elect to widespread use of encryption on the Internet. A secondary goal is
disable opportunistic security for some or all peers and set a protection against active attacks, by enabling incremental
fixed security policy not based on capabilities advertised or deployment of authenticated, encrypted communication. OCS seeks
published by the peer. Alternatively, opportunistic security to achieve the best protection possible, based on the capabilities
might be enabled only for specified peers, rather than by default. of communicating peers.
Opportunistic security never displaces or preempts explicit
policy. Some applications or data may be too sensitive to employ
opportunistic security, and more traditional security designs can
be more appropriate in such cases.
Emphasize enabling communication: The primary goal of opportunistic 1. Determine Peer Security Capabilities: An OCS protocol first
security is to enable secure communication and maximize determines the capabilities of the peer with which it is attempting
deployment. If potential peers are only capable of cleartext, to communicate. Peer capabilities may be discovered by out-of-band
then it may be acceptable to employ cleartext when encryption is or in-band means. (Inband determination implies negotiation between
not possible. If authentication is only possible for some peers, peers. Out-of-band mechanism include the use of DANE records or
then it is likely best to require authentication for only those cached keys/credentials acquired via TOFU.) The capability phase
peers and not the rest. Opportunistic security needs to be determination may indicate that the peer supports authenticated,
deployable incrementally, with each peer configured independently encrypted communication, unauthenticated encrypted communication,
by its administrator or user. Opportunistic security must not get or only plaintext communication. (Note that use of out-of-band
in the way of two peers communicating when neither advertises or capability determine, e.g., DANE or TOFU, is downgrade resistant,
negotiates security services that are not in fact available or and thus preferred over in-band negotiation techniques. The goal
that don't function correctly. of this design principle is to maximize the offered security
services on a pairwise, peer basis.
Maximize security peer by peer: Opportunistic security strives to 2. Apply Security Policy: Having determined peer security
maximize security based on the capabilities of the peers. capabilities, an OCS protocol next applies any local security polices
Communications traffic should generally be at least encrypted. in addition to the default OCS policy (see below). Local policies may
Opportunistic security protocols may refuse to communicate with require security services in addition to encryption, e.g., authentication.
peers for which higher security is expected, but for some reason A policy might restrict the set of algorithms that are employed (for encryption,
is not achieved. Advertised capabilities must match reality to authentication, integrity, etc.) The OCS default policy is simple: establish
ensure that the only condition under which there is a failure of encrypted communication if possible; authenticate the peer if the capability
communication is when one or both peers are under an active exists; revert to plaintext if encrypted communication is not possible.
attack. Reverting to plaintext merely because authentication was not possible is
inconsistent with the default policy! However, explicit, local policy
overrides the default OCS policy.
Employ PFS: Opportunistic Security should employ Perfect Forward 3. Employ Perfect Forward Secrecy: OCS protocols SHOULD employ PFS
Secrecy (PFS) to protect previously recorded encrypted to protect previously recorded encrypted communication from
communication from decryption even after a compromise of long-term decryption even after a compromise of long-term keys.
keys.
No misrepresentation of security: Unauthenticated encrypted 4. No misrepresentation of security: Unauthenticated encrypted
communication must not be misrepresented to users or in communication must not be misrepresented to users (or in
application logs of non-interactive applications as equivalent to logs) of non-interactive applications as equivalent to
communication over an authenticated encrypted channel. communication over an authenticated encrypted channel. This principle
is consistent with the goal of not encouraging use of OCS in lieu of
protocols that offer additional security services, when such protocols
can be employed successfully.
5. Example: Opportunistic TLS in SMTP 4. Example: Opportunistic TLS in SMTP
Many Message Transfer Agents (MTAs, [RFC5598]) support the STARTTLS Many Message Transfer Agents (MTAs, [RFC5598]) support the STARTTLS
([RFC3207]) ESMTP extension. MTAs acting as SMTP clients are ([RFC3207]) ESMTP extension. MTAs acting as SMTP clients are
generally willing to send email without TLS (and therefore without generally willing to send email without TLS (and therefore without
encryption), but will employ TLS (and therefore encryption) when the encryption), but will employ TLS (and therefore encryption) when the
SMTP server announces STARTTLS support. Since the initial ESMTP SMTP server announces STARTTLS support. Since the initial ESMTP
negotiation is not cryptographically protected, the STARTTLS negotiation is not cryptographically protected, the STARTTLS
advertisement is vulnerable to MiTM downgrade attacks. Further, MTAs advertisement is vulnerable to MiTM downgrade attacks. Further, MTAs
do not generally require peer authentication. Thus opportunistic TLS do not generally require peer authentication. Thus the use of STARTTLS
for SMTP only protects against passive attacks. for SMTP protects only against passive attacks.
Therefore, MTAs that implement opportunistic TLS either employ MTAs that implement STARTTLS establish either an authenticated,
unauthenticated encryption or deliver over a cleartext channel. encrypted session or deliver messages over a plaintext channel.
Recent reports from a number of large providers suggest that the Recent reports [cite?] from a number of large providers suggest
majority of SMTP email transmission on the Internet is now encrypted, that the majority of SMTP email transmission on the Internet is now
and the trend is toward increasing adoption. encrypted, and the trend is toward increasing adoption.
Not only is the STARTTLS advertisement vulnerable to active attacks, The STARTTLS advertisement is vulnerable to active attacks and
but also at present some MTAs that advertise STARTTLS exhibit various some MTAs that advertise STARTTLS exhibit various interoperability
interoperability problems in their implementations. As a result, it problems in their implementations. As a result, it is common for a
is common practice to fall back to cleartext transmission not only pair of STARTTLS-enabled MTAs to fall back to plaintext
when STARTTLS is not offered, but also when the TLS handshake fails, communication when the TLS handshake fails, or when TLS fails during
or even when TLS fails during message transmission. This is a message transmission. This is a reasonable trade-off, consistent with
reasonable trade-off, since STARTTLS protects only against passive OCS principles, since STARTTLS protects against only passive
attacks, and absent an active attack TLS failures are simply attacks; absent an active attack TLS failures are simply
interoperability problems. interoperability problems.
Some MTAs employing STARTTLS ([RFC3207]) abandon the TLS handshake Some MTAs employing STARTTLS abandon the TLS handshake when the
when the server MTA fails authentication, only to immediately deliver peer MTA fails authentication, only to immediately deliver
the same message over a cleartext connection. Other MTAs have been the same message over a plaintext connection. Other MTAs have been
observed to tolerate unverified self-signed certificates, but not observed to tolerate unverified self-signed certificates, but not
expired certificates, again falling back to cleartext. These and expired certificates, again falling back to plaintext. These and
similar implementation errors must be avoided. In either case, had similar behaviors are NOT consistent with OCS principles, since
these MTAs instead used the OS design pattern, the communication they revert to plaintext communication when authentication fails,
would still have been encrypted and therefore protected against instead of employing unauthenticated, encryption, communication.
passive attacks.
Protection against active attacks for SMTP is proposed in Protection against active attacks for SMTP is described in
[I-D.ietf-dane-smtp-with-dane]. That draft introduces the terms [I-D.ietf-dane-smtp-with-dane]. That draft introduces the terms
"Opportunistic TLS" and "Opportunistic DANE TLS", which are for now "Opportunistic TLS" and "Opportunistic DANE TLS"; this draft is
informal. consistent with the OCS design principles defined in this document.
6. Security Considerations 6. Security Considerations
Though opportunistic security potentially supports transmission in OCS supports communication that is authenticated and encrypted,
cleartext, unauthenticated encryption, or other cryptographic unauthenticated and encrypted, or plaintext. The security services
protection levels short of the strongest potentially applicable, the offered to communicating peers is not reduced by the use of OCS.
effective security for peers is not reduced. If a cryptographic This is because the default OCS policy employs the best security
capability is neither required by policy nor supported by the peer, services available based on the capabilities of the peers, and
nothing is lost by going without. Opportunistic security is strictly because local security policies take precedence over the default
stronger than the alternative of providing no security services when OCS policy. OCS is an improvement over the status quo; it provides
maximal security is not applicable. better security than the alternative of providing no security services
when authentication is not possible (and not strictly required)
Opportunistic security coexists with and is preempted by any OCS coexists with and is preempted by local, non-OCS security polices.
applicable non-opportunistic security policy. However, such non- Non-OCS policies may inhibit use of encryption when many peers cannot
opportunistic policy can be counter-productive when it demands more offer authenticated, encrypted communication. Unless authenticated,
than many peers can in fact deliver. Non-opportunistic policy should encrypted communication is necessary, non-OCS local policies of this
be used with care, lest users find it too restrictive and act to sort run counter to the goals established in [RFC7258].
disable security entirely.
7. Acknowledgements 7. Acknowledgements
I would like to thank Steve Kent. Some of the text in this document I would like to thank Steve Kent. Some of the text in this document
is based on his earlier draft. I would like to thank Dave Crocker, is based on his earlier draft. I would like to thank Dave Crocker,
Peter Duchovni, Paul Hoffman, Steve Kent, Scott Kitterman, Martin Peter Duchovni, Paul Hoffman, Scott Kitterman, Martin
Thomson, Nico Williams, Paul Wouters and Stephen Farrell for their Thomson, Nico Williams, Paul Wouters and Stephen Farrell for their
helpful suggestions and support. helpful suggestions and support.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002. Transport Layer Security", RFC 3207, February 2002.
 End of changes. 30 change blocks. 
302 lines changed or deleted 164 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35 --------------020000040301070601090501-- From nobody Tue Aug 19 09:09:07 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00CC1A04AA; Tue, 19 Aug 2014 09:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVGRTRyIGPMy; Tue, 19 Aug 2014 09:09:03 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 790EF1A048D; Tue, 19 Aug 2014 09:09:03 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37312 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XJly9-000CF4-AA; Tue, 19 Aug 2014 12:09:10 -0400 Message-ID: <53F37696.8080000@bbn.com> Date: Tue, 19 Aug 2014 12:08:54 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> <53F26D8A.1050304@bbn.com> <53F27065.9030902@cs.tcd.ie> <53F36E34.7020701@bbn.com> <53F36FB1.4020008@cs.tcd.ie> In-Reply-To: Content-Type: multipart/mixed; boundary="------------030103090407050108050200" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/LSoBoiz6s5OwYvI31va5Py9zyew Cc: saag@ietf.org, "ietf@ietf.org" Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 16:09:05 -0000 This is a multi-part message in MIME format. --------------030103090407050108050200 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Sorry that the doc was mangled by some MTAs. I have attached a PDF of the doc, which I edited in MS Word, based on the .txt file as an input. Steve --------------030103090407050108050200 Content-Type: application/pdf; name="draft-dukhovni-opportunistic-security-03.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-dukhovni-opportunistic-security-03.pdf" JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHVXEuT2zYSvutXoHySqxyaIMBX9pQ4zpa3Kq+y anOIc+BIHA3XEqmQ1Njz7/cDCZICJECQRpOq7G5lJsm60ex3f93AX+Q38heJPT+J4v4HfoZp 7CWB+Aex/KXOye+kJG/fNZQsG+J3/22W+KO+F/D+78UvIfco/iAncZB4acrYbLkl3y8IZ93/ R/5YbMnbxYISShb3ZE5ek8X/yPtFx4mJHI09Ht+OnB96Mb0ZuSjFZ6eM3+hjoyTwouljfc+n fkQWS5sU/yDzn/P2S1V/Jr/jL0W5Jv+uq/0Owo24kPGs/yH/7pk//vnE/uuRH/afH6rHsnhN /iSL/5w2QJ5Qj/EwJJpOnmvPUex76WSATiqefyjbvC7z1uwv1OdeyHhKNPo2dr+xkKO+l7BI p+bELQzyhzq7b0cDVE3un29Bhg/7mz5z8aUiH4v1NrNabxx6LGV0VCA5EY1nl0fjKEwFXSbJ jfYws9gZ7EHYb7nKV6Rps3bffEs+lPdVvc3aoiqzjS7Pf5SFfLdf75uW0PANCXzKrUpJUi/l jJNBirfKGhy5Oh6T0KgUW9aYv/+6K+ocqvgxv6v3Wf1EaNR9QiiiwuxkUg6Qi1NEGVh6f+Ip qyK6Vc3O5viIRR4LR6sy29LMqWSIAsTCyUhPkpu5VyARZZ4P8cqP/QbyDVl4lJV1byL9f8wx Nk1RN8GZiHZAr7+ZPevPf9ntqrrdl0XTFkvyMV/u66J9+pZ8rLY5+bWu2nwpvIv8VME6q3vS PuRkUWzz10Z18DDwqE+P+Dkpv66Cc1SHT71w0u6F8pNiRIwwmRHl3GMRRayTB0m3cvODlUhV FuIIpEkUBTpxs1DI3JZXUeBRVHg6OUdex7rFJIuABV4Yi6pFlcWV7AYsQWSJjsi5sVsdmqhZ xCzwvThJkxvxzAL0NKl/RM6N50Y6koVddEY8RaF1EwmzhHlXsuozC5Np5HE/OPIJmx1YXGxs 7kKksPh2zV0YJ15wYb8z/+6uaetsaXPaoRjW6D/766PIi5H/bpS3Q4j1oFM2BUY9oRKLomLq +TyMEqLRdjP+xUPRkG2+rUhRtnW12i/zpkscwtAMJQG6/RAN9XigXhmeLkJk+l1W5TLfiU7B GNBgIWmchkb6tspz/krNkuZjWMzg1GifrpLbu/pp11Zm6pyil/SpTtxmjpYcwlGFRcK3r+J1 qBReWYTOYxSqoX8kDRvDFnJT9OCQ8uTuzgZvlmwUIsxFvoCfFNJXcjq5j0rOzX0+zX8xc4o4 j6oZ+NgFnL6zkBOtBFKzTs6N04+fXptJUx81RIgEegGnno0caoiQXkTOYkyUhh4NA9jmNSr6 5d1HghiXkSbvquIdCuVqWW3IKm+KdUl2dVEui90Gcc9cKLMkQoURTSycjXmzA9CzfchsAW/y bvl9OnFrwMvaNt8ioLaVRYQc/AdhoEvwSp+ZvJtR0R0OwK+zd1s4nfxRpe1m5TUy2WPuYpkq 9SsFQSlHDqFIVbchh7KYMrQ1Gjm3b7/L6rrIa6TvqsvgXwpY+K7OsxXZN7loCPNyKdKW6BHx P9EeDiijZzb9EJUVTxkGBfIbpXWaRWbvEQEzAgtF9eBA7oKWPYTsuKDbo14mUzxu2c3GMpmi SrtXx9luvY87ZdUi9gxBx+v6dBF+RJUlo8LpMotBUDzhCPenTj/CIoaSUYosWz3kmOPYShQW xWKQgSitHqAoVpeXWVpTPeVOzpI8GQoSFIGIuO7kLMlzCuDu5D5aPjYNAIrGF3FnCXosTbwI Dab2raPfWxPAeg9H3xQlEtg2e7KcwsE0UJnxlFv1ND6Yv6LEs3A6eZ5KexTI6RZDzhir+/u8 JtlqVUiwuYt6Q7E+EzNQdfIYoMBAcodk5HFnQ5xEfE57bhAEaHH9I3JnuJeeO8ARqFfqxwLt 2BuSe2vvjWjQ8rVA/EhWrizC4/BrxhNYkyo8xa+HcHHBWJZjUEynVtgUYXXKTr2rRvuMpCTT 2R4prAQW2g0VIKAO8myG9H9K0YNmhvMcFN1J2qRo2Qlr5M6wPyq61y/JEKgtoWbIAycPOZeF mn2HyGEOcwe72WzM5wwd63DM86LDWNNq5M6IRmp2l9VtIQpyI0gwGrlG/9lGnoRehDJCfv1t jVyl7SYKFHMZWVbbLXD/3tC9SSwzPZJR+KgvsGsuz5IGfvasmVjOWKAiFO1S3xmZhR+AeJD4 oX6KInz3yiFIMS1IUEWbmLamv91DsamaavfwBL6F4VjNRsIyw0lSzWfF0+2u3NfVVlTNZsHw iHqxn07if6YTDZFcY1eRsx5vzdyNbRsAmcPp4W2NXKXtJllh31Vp5pwik3WAgsb5lYIYAQWN nBuzO4FEIzFPbnhUUFAUMEkEvO6qA9CpVTCzeuzODk+aaaXL6IpS7q4OD4uezcdaY+hPmn8J A3/qAk5Vbp7MKkFL6AWYw+mfeKVKJtuMUFm/EKTAVdpu6q7zv/YYmx/qQCsfaUA9HrKUXEW/ L07XdYZAtuwaRTnGzdZZUTatuTNnAabUYpVvOPdsNWPtzFmARY8kPiJnEJMW3+9gsmSXNU3x mHcFqnAS/GqxoAFyHth/XrCcLCgUi0wvlMJV2gbRaCEZCF22/GwWxBTdrqGO/qCqLWKmPPKi MCH8GuJ9K2VhPQE4FHEEOpW6LQrY4nyKuXAEnFIj5yZnGwAa+AwbA/F1lLHOJALk4JcAdDYb UYXJZUvzRiHDqMyPMGMavsfuoV0RZsNEmFh7iJyoySbDBolw34tE9JCqs/EmqdkQEZhZiink BdQsRosM4AWA2zVqBjvQQtGYzLB7VosYZIfGMW6MguTIMmwmbOF8CkMsFTtEL9NJqLQNYtHC UOfLFlceZkBYUDpk/Eo5TEFNJefG64RUWxgeiyz1hGsZxpJH6FP4w23IYfpHOUV9pJJz/P7H vBR4hgpxiDlWhyc/ZsUmu9vkCELm3S64dxLArOX5Nvfu2m5rccDh3uhuJulIcobP0Tyy2zIw axJDUgzLw0lWp3jVSDq5IPaCTq6hWRtKrJ+ZWR2RSS5pX9RBrqrlfgvIynIABd04FCnjmgPg N9W+ztZ5Y/4EOiZZ9YRr/WaEHFRyBsvQglIPNTQAN8kX1L8PxFgOWywdXbePBYZRZKfMRznX aupTBKcY+r7QSImrtHthnQPzZEdATLV2X2g2ZJmV5A6ltzE2jKOfk2ycmi0djrMBs2yqJ0CK ZhvjaE0CYIBEO0CxsWs8Wqx5YXwoNTwhF7fwaEn7Io/G7gBmznBplIRPb8iXon2o9i2sOAco jXs5w1DWoouxi1O/TRGVu/VOXZxKzuCOmg5QKalYo0XF2OAO/RClvyo3M99ut78YplTYuBvq pmeTw6WeYOoGDWJQ5EvmH7s7C2Jk3mWun7BVcCAIDYKhAnlBD0uYPOps+JkEcWJGMYYfFmEC Otn6WUGcnlFM5MJuk//YdU7P0mTF75YMmUrbIGTN1jrRDgsIB+LV0RXsqIs5sHqG1d8tm3QU t1mC6JDYDDcWDQxrVtFfcUIN1uzvtgXWblYibd3vNxs4TX+7BbuNXQzoYGJj+MUdM+ywoeVQ v+m0Is7XZpOKRZH2QgmLqbR7iZ1LWOjEHosG+yaN8KXv3/1K4qQDh7pf08MVMs2pglhci0xC op171gtwtc/qVGihxV08Vx8951QI3mImepSPTuvyMqdSaRtsVHMqB38a0EoBHx7wrkhWo2pz qKFe1ciN7Fo9tXMpLOcBXxXXWUXGHGrkzmQARk8o+PtyjS2HHPt6a3M65QlQDRowovGjfJ7i 2G7FINayusHgGU1rgnMMnyptJ98CJrXIms/kx6pGzPk0//B+8eOn1xMq1YFTPwO06veM+oHC WtwS7tdEsk1TkRWuEtXF3b7FHSEzisUjH8AwroRoMjCItEOxLLXhFK58rIJNvjgVc6rzXCdS lbaTSOfHJpg1o/mZM1QAsCpGz0aYPNQByLZ4VABx+zGwRY3c6FGqeBRbJsNN3EazhAUcaQNt iziMe2O1aELHWGHTPWazSUqRMVWB2nRv+TaORSeaigTsQG6IlmbJj6YUJNjEwKX8l/BOjbab KcnAJhaPW/LQtrtv375dZSgrMTz8nNdekbf3XlWv33aX0Zq3UidvLYuYnGH05wNr1xgyqKIb 8Lm4YRBH3bzElhIvUQUW9Bl9IVWotN1UMZq5cZlkHOAFkv7zHHiEcDRyTg7cX6TvU2JnGwcJ 8THbFCuCa9RYCdlmX4utJQ1iO2M4Xir2zPFSxfutCBFN8ZVgIt8+WHAkNH9eQhGntHMUe9SD t4svi3A63eWd0oK1knDLtF2oni6znRHJsGeGdTuxWQlIZb+DE+erN6QGBpItxW/QRnXXVJtc 9ANYsuoz7VTFwP+z8smiKVwKDimyx8CbzQ8vaAYCHrwYeqXRdvJDZKYWl5G1vPShFaB2UWY7 9Aq4igHpinGNWFgf/daSnpiciGkMKSaoJMiZ7aoukxMxjZrBSjTTHkrZBraB/VMgsdZFIVlS DUc5RBynWI4cIfAxSW7yHVvNMHf0HZW2QSqKtMkcDz6gYMeDD3ATAS4VXUGaI8h0Gy7YgS8J iqxX3WM26KZhBWu8UdB4ryweMyBPgeToVh5D+2eMbOQuSYR+3CFPkpxJF5oZOepCpe3kgFjv g6uNXmXOhhJwCeQZDqZpqfgk4KIRczOezqWApwBgybu3K8S1lTGDHC0/jnuEw2FS8mcP6zqW o0cxDtEJDZPiIruqKlBCjq7TkeejTbGxgqVp/0rVKeO7hhwWM3C5Y8A5RhFYc+i7avdUF+uH lqBxxIabmW3kK/GuCV71kuc4GMmkOYsUOthnjF+KULXI4kQOrdTBy0smF9QpOw0AqUp7lLA1 0k4S/jRffnrdvR9DROtOFrV4U0Zs9gvMY4d7XAI1w80OLLjfFygtECXxbyxRMcKuCcWtg4Gx U5akfKkb8EG58v6PSYa6jbrJUKXdy/AMqIg6YiiuuvF4Veu97neIF50Zi1QsblHkK7RVZnyD 4foH8PuUaJ9qsD5nfIOy80/mXJBP8NbeIVyic3c4oXPyDdxdND2ZoyvTHAim+IUFK7Huosdc W8ARYIV83wQcn3+z7oavRMm3kI6fQvrbHs/741eM6Qn90/58FEoIcc0Mfn2DnZxRWQB10KKz 8HlRmwowR7wceR253/4PAY3pAAplbmRzdHJlYW0KZW5kb2JqCjUgMCBvYmoKMzg4MwplbmRv YmoKMiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNiAw IFIgL0NvbnRlbnRzIDQgMCBSIC9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCj4+CmVuZG9iago2 IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEg NyAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA4IDAgUgo+PiA+PgplbmRvYmoKOSAwIG9iago8PCAv TGVuZ3RoIDEwIDAgUiAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PgpzdHJlYW0KeAGdlndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKG hCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZ Z+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz 9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi 48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjAShXJgl4GejfAdlvVRJmgDl9yjT0/ic TAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHimZ+SKBIlJYqYR15hp5ejIZvrx s1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW5mj5v9nfHn5T/T3IevtV 8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC03pzzHoZsXpLE4gwn C4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TMzAwOl89k/fcQ /+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRodV8AfYU5 ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9kciWi LBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2 g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5 Q0FQOBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA 2bA7HAhHwsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREh a5EipAKpRZqQDqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5 gqVi1bGmWCesP3YJNhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA 68MN4SbxeLwq3hTvgg/Bc/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQR wjRRgahPdCKGEHnEXGIpsY7YQbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZ QF5PriSfIF8lD5I/UJQoJhRPShxFQtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mz l/OX48mtk6uRa5Xrl3slT5TXl3eXXy6fJ18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqi lWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIlpSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0 H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyTjLuMj/M05rnP48/bNq9pXv+8KZX5Km4q fJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uuq43Pp893ns+dXzT/5PyH6rC6iXq4 +mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoLtQRa5VrntV4wlZnuzFRmJbOL OaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0svWC9fr1HvoT5Rn62fpL9H v1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+41smsImdSZJJjclN U9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIudFt0WXyztLFMt 6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtOu8/2DvYi +yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX1C0Y ctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrP C16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegK pARGBFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+ eHcELWJFREPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7 JHZyqffS3UuH4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXfl BNeTu4f7kufGK+eN8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykz qdGpzWmEtPi000IlYYqwK10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJsl g1kLs2qy3mdHZZ/KUcwR5vTkmuRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tndd wbrh9b7rj20gbUjZ8MtGy41lG99uit7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3Waz rWrblyJe0fViy+KK4k8l3JLr31l9V/ndzPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t 5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqvakfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/T AY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/Z39ff0TtSPGRz0eFR6XHwo911TvU1zeo N5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4H++eDDzZeYp9qukn/Z/2ttBailqh 1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HOFZybOZ93fvJCxoXxi4kXhzpX dD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9jdYeu56WX+x+aem17229 6XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3RB6kPXj/Mejj9aP1j 7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0RupHrUfPjPmM 3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk03dp76an it6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/sKZW5kc3RyZWFtCmVuZG9i agoxMCAwIG9iagoyNjEyCmVuZG9iago3IDAgb2JqClsgL0lDQ0Jhc2VkIDkgMCBSIF0KZW5k b2JqCjEyIDAgb2JqCjw8IC9MZW5ndGggMTMgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ CnN0cmVhbQp4AbVdy3bbNhre6ylwuhnlHJfh/dKdm6RnMu0kbq2ZLuouKImy2UqkSlJ2/Yjz VvOBJEACJiBIlk8WthXnB/Bfvv8K5C/yM/mLRJYdh1H3BV+DJLJil34Q9d9UGfmVFOT9h9oh q5rY7Z96hX9qW67f/Uy/CXzLwT/0SeTGVpJ43my1I98v8Fu2Y4dksSK+1/52/2WxI+8XC4c4 ZLEh889Fk1VF1rwjiz/Ip0W7NZG+Y/tW4PmJTF9H9VsNOce2Yi+UqRnt9jcy/1ilm4a8I6FP 5vKX2dSHk785/vDrfl9W78jvZPGvaQa4XmDFMTh9DoOx5eZQ5HWTr8httjpUefM83vfsxSnG exv/5svzir85Pv314f5QN8S1HV93Mj9xLDcMHX4y0qrOTCdabEmlKYMmOpHlR54HcjNo4qvJ 2YEVOVyxX0suTGAxief3dvItVC/wgmOGQojm5JFj2X4QxkSibaTV88VDXpN1uTrssqIh+L4+ LP/IVg1pSvL9hxsSxSQt1qR5yMjnT4sfyKKCcP9Rk5+y+3T7bqYShx8Elm/HLt9UJ12NOFpl VJHj0g1j1wo76VKcUfFvJgKNIf9E2h3/Zkcw7KYqH/M6L4ua/JJt0yYv7inrWl597Nla92o7 o9grApwHgHMoJEkHO6pns0m8HPgU2VYCte3ZruIT6fk06wDZkE8ibYWeSSK4mz80zf679+8b qkBZZuVZs7HK6v79Nl9lRZ2pTduNqMzjgIT9wr3x6HikcQJuBFcVJS/IKc7BWNT7rLzYlHfv SF6QbLOhdlIWrXGs0yYj5UZjEWFMnaLHT3EpiwgSy4PnPSJpSRyGkhZpG1kEnM7+sIRQYQvg TbkBe0YQY43dymx+s83SOiNV9phnT5SR+IGhEcxG7Rh9P7Ki2PdJ2O/RQCk0IDoYDujG0RsB tEjbTOFWaZVtDtvt8xVJa8qhZ7LO6lWVLzPyXB4qUuX3D03donSV1U2Vryjja/KUNw9gbL2H lqrVMoB/ix0EL2G/uUuppRdaXvBGainSNlLLOUBZVEQ14DhACCf0HBL2C11Kt1xEs0OQrMMv I1V1PMseVNVMnRbpckuBinwoEX0XDfNNU8F3iAjN9+HDxYVevW/bsQKoxoW4GsSJFQ1cPebq ehw3A0CJthGLAYCOgHJtolOV60NrmOTdOFi2yGl/pOSjJeXqcDIAs50Y0SE7isK+Z6O8zET5 AtiI+0aBmETbzL5dS23QsWcB3pCmMsq96hnripo04vnEjeDWJdKmqrLIql1elNvy/vlEVaCK I+hS71m1WVdgu1ZgJyHf7pQ6yLGC+vTcbQZhaEXI1F9EIfp8ziivYbR7oZly1pOMcIEUps23 X+bEH7M6vy/ITdrQgsSkHKY4HegNj3FaZI2AnudwGjynlZY34XRP+0RO+xKnj3C5yotVvt9m tai+U0AowV1bdIj0XGdwJx5F4LoU0hvBne+1VYVTgUNDm+ftgUjbVL8Dieuf/k534Op3kpIv frql2crtvxc34Lc6oPYc34ptJ0BNrzvqFDIMnJvRAp7mdJ5rW77vuDI5xelEQ4ALndKG7rMp nYhHOjGTc+zBBRqdrC1Ntic7kmMHnmMlx0NcxrOTcmyJtinXQkkneNUP0V6dr7OqTcrqSYR7 yfEpzEtGnH5RzRi8i8gawfpEUet0aPAuVJm8N8K8nvaJmBdJnL5e/VmUT9tsfZ/RSpoBtr3k t0q/Z/MjXGeYJ7JJ4LqshSY+3Y7frNYWiLQ7/T5SawMqxBLXf8k2WZUVK+pLxhVpFW/Vn5+h 64zr4lEErp+h6z6aMc45kZQulkJl03P9JCaMeq/twmaZivQZEjBVVY6NoRhuaDsyOQVMiYQp uMsJ0pey2gGaHjMUUQeJnpooCSrQK0RvOdNQ7ieJFaP2wbiid3m9Y1DWvDlc+XFghVNw9aL8 LWRdSEk1DnUQoUid81wXabem40rG8xmlzCm2w5B4Z0htMOxvBKY7tt492FbgBuB3fwQDLdRw ZOB35L1ZzQ6tpDFtzu0Xohw1NsHt60PzUFbok1yv16jBCfA00wQ3jKviVxWPJxoKge1ZTmQn hG3cSKdh6dMWMvA4BIQMwY4OOBBmqoBjIBfQTiz36Gq2jiwEbJVxAx1kXljRaR4AFYhlQ/P6 dS+leV5CS3CXKmX5bjSujBmXJzRGwrMMibaa4yNFRncQ5fjsMduW+7Y/iLrh1z33Cy8ibRfK 54WRS9hivfIdXazNJtAK56n5h+p535R8pReRpueg3hAHobySoJeS99X0hDwXpVQ6EqHauA5c 5zzKvpt//XBLu0M12ZVwZ+gJrTWygUO2YgqHotiFM4i+0yha9sEbG7bV6/hltUikfVSwrc9c PtO+BVmVCNQqdCaqNK/BGGSlv/3yw4fIDeLfLXKTVY9pTUOAXVnkTYkqwT25m6Pnsc42eZGt NajCehjs5Ecxz6zZ7NPpk+NNVEnNtF58MEeRdsfIIwHwHBxrHtKGgGudlm3QPctpQX+ZrdID emdtuy0j23T1J/3+CTlfva+ydE36v1Vz0Y9Dyw1gu+LO1NpoxkQvcWll8GW9SvSgZzFRom3G RKQLFFxocxLxD9XKDbhUNHm6xXyMRa63cN2H+4dWZ9s+/kOrhC0KZhr+oV0Cx+uSyV1NjXiM fNt8TXZp8awGPBqqBg7AQqIuiEdmopocd8RejCbP4IgHsNAinpmOM9o9EJmBRT0MKqmiCAd4 GQWYCjtrgX1VNuWq3NKYTLlCYltRCGOQVhC4LUHz3VxHDyN3YfiCnhlLMuveutLs1vVQuotc T96tGXUUCK/I5xvw/Yrc3v7zivwP2NLCDD3PdFhIldDDEAVf0czR9yWwDHXK8pmMDFHNOdqf doLAkVbSa6eGHBtY9EJ0DTtsp2Nig96LsCTJ2FDve9on6T2wSL1ttDgTP45Cwrb9uvg1AdIj 54X4ztmphJhX6m07qGV0ai+uozMjnZ6z8PKsbe9KTCV2/nFH0m1dYjjir0OOUdey0MC6B7eI htnAK4PgQhdpcssZFFAzMSsh+lP6TOCzmidNaMxH7xiXug1rLUazYZ+7tWHD1GLMwAUbVquH H9tW6FDcuoh6DD4tiNrC/KkBsHqnIZ1mDJE/eiLpMxWZR4ESOTOepqgt0Hilm7BSb9rBZJQL yBC3bLYGLRUpnSO2H4cuIPkcyrQyMuy+TZUwYNpmSn2eMDhozOzQH/QDTI5rOU4U8N0Y2Kfm cIMS+eF0z0F0EJKBGjoIkXYnkmPBf3qf5gUgLMUYCbIk9KoR5Nc6QbmuixkNzCZ4/XonOaTP G8TGux0GyKmiIRnbZ1mFOTMA5qFop4ggHk04zCaA2eJHQ4RxOLzLMowgP2imQvngmkRfMElZ OmqlDhzHwhQ1lFqUzbnkeJyB2GxyEFeLx4Zq1NM+SawiejAf2PWs8t2+pJn58lktVw93KPzY B66IJxMYJYRN2jyRF3IkcgqYkgQKDUHSywHjqs3ZUG89bBvkU/SygwrEAlwTiIII8haZqD6G tt09wAYqSbR9c6rv0Wx18BYibQWLBN6TOcZEi3JsyWVxRWOI/RZw0mR/N+LfAU+U1VsvSizH 8wG1/UYuBbWwvVG/ZFIErHuukSg3OduGR3ijioNI2wy5Fyh+pcuclhfo3YCRBeLz4pns4eLa +kMLsQhH9SLA7DqiUXEjkzxrG3l66+PBrUhOoVovrY+wO1wMSHRZdYD5VzuIYXP9ar2RqDdv ZnMu+pGYq30Tm5No67aaqnUT9+rgV4A2EjkFnyUTLsYqQ+tWu2z1kOJi146uOJ2huz7a0xgO 5isetVXKa6Xpu5gO9yOM27MDnOTNaTVBzRx+v0OiLfBaUj0NXPL7HRI5zmut50VRotzt07rG SEG63eI61Oqhi3zUB8CMNEanUN1hKxrotWZa1fcBsza6KCeQ0/CD54MSOc4PMaCVdO+LLtNk V1okyoLgJHq6jUa+5QG45XObbbSt1KplxOtIl9kr9/duFLaNzLfw9xJtMz7UDU2nqnXdVrdH voYCh8bA0SGNUFQlbNGTDLwP19H3wsUUzNDmqUa/PbTU/QTlW7aUgblo1IZGJa1LPIHcQq0o vN4jkTPjPjz9TXv7ifyY6Sof3HJE9TnbcuiAe3Ipjg7KjbqHh4jvTZRbpG3GXoysVCnuOOEq xQF56N385sfPqFb30pwYh+Adabdf7qhat+3vPtrcletsS7pydZsWkWVVPtU0DZbjuKdsqdYp P/Es16HeUzz0meIe5EON9o2uvrgibTP5gDWPlDt383KDmJas4ELBOKRp5JtfsyWBuL4hv60A Eb/TBqYajjycMUicmLBtHJWbUD2gaSywiFZ86e1ltNbSbi5TLaPAiS3fwS1TtuLrUGmQEYKD t+rGuyJtMxktDxXanfQqITrJDylKSdt8B4mgIY+xVbSJdSmgi1v7iODBpX7pk+RCEyG1BHgp QEVbG7i194o1xH3cV0psKJTIM50Jaqrig36K5MxEgAxPWZjA/Ax9IeBiG+XO9pyNbvKq1kTu vj0ogoG5aPjpowTgYaBUko4ZO+low9188fWH/9y9UzMW6UsfXoqc0GmARlsHA/cw1Yhyw5s4 SZG2GTukmC/doz6WIovpWTPlJVmh2O3XO2rVYy+JZAmvR+gS/yHDU9DXWzYFKrVc+RMKbPO9 IAyZVdBq9tCTAAx219fJn7hprXZQPvp4uMRK2KI9x9TKpK3DDMoELzR5u0tM0uRsWDc4zMuH rki748+xrkO5bFAnBFfouAxFA3jVAp0HDSq4eAsIlVXwpl/QABo08uXTDRI5M/liggwBQJX1 p6ATP5tDGzwCNWjoqCx5+ChyJjZugbN1jxrFOAR5ylE8QO31vix1I4BDWioIR2sPGl4NemRH bKzn4uMNbk/7JDvLim6mqiR0wEdtzX3T8qw1kBH0sh01rrivncC9AToGdmma8ayU0WcHFqEu R30UDyW4JE4iPIXEhUGpCxghWbLGRXo8ghHJcTvQKs0Sz2wA2tjs0xXphoow8KNTJ9YkYSd4 nSVz7XQS4VGliw7fSLQ5d0S2M1H2d126lIQ8ldWf5CmD5dL3XejrZPsKo6r49jGvyqJtkl2R 5aHBL0HZirKhb3Hg6jBYi2llJZTwXiXb3IW8hROj5zF1F1g8rKRjZs1FibaZt6iR8MEIAbKs L6A2D7qAH/p4DK4/hYFyaczDYSN7EjkzBaCDsn3uo4zMaWLoOP4p+9XZFmtXOe3zRjx+FNBB UlMjcmH38pMBN3XkUFMLQy8hjkjO2FTVcufxiETaTFAfv9yqSfMxOYm0jqcaleJjchI5s51+ TxFXvVc+xCoR1+1VIzBU6dBbQ2NQIme21+shAKZlYkzJfUl3ALVPaEs2OWL7u/nH6y+f2nn9 MExiWr1Rwx1vYLC9nBQ5deP+mndpeDVNIi9wTsY8tSD4ZPUJ5DStvgHre8uZwnrz3Q0+E12h yXe+tG7fEOt72idFdHQWEVXQNd6XxGNUBzx/NiRONVmWB/psYElgsKSAMmFS6TOSh7SgQcgj hdtU0+ceZCweW5CxgI5m+ZXjdc979UJRwZksH6P8SqLdWd6x/CrdIsrorr6CWWot7eNitsZJ kkL5VUOYPXYlkVZzWtuUH7x6z+mTdtrXiNW75bnlZXbLc0uJnBlq3s1ppFOCvRjJRUOefPov wQ2nJt/QkTmgJqt06yqqrJDAdjAFF+couhu+2RAMnvwd0zZT9NZ/1LhZs8V8mU4fu6lVtsbr whgH/RYM9SHG7Ld8kjaiQtDeUkPF449D0b3e1b6qB0y7/fRB4wF5EZete5IHpLfifPQMcCvu WlNnGdysIA+9P1CbFp8TGO3ZfNC7yXeZ7o4KV3NREGeizOAV8WrN6Ek9FZ4LBgT8MsNzkbYZ JvSqgU44zQ7rwwZYkCOV3D63l/G2mslKPriCJKM91OugwMUlezdGhV4ipziH5PLWGb2jo9YW fmN2kvoxr9fly8pMi3dXGPHXoYCHSCxO3Jhz4iQUQAuzfCItfGk99GCO5+hNjRig3rQXZdVM 5z3Ky/BlsCJcrBldY7+sFYm0FdonGahB9cCl89o0QRXp6wBFk+oN2ZhIzmy7tHqA51l19zeH uEhc4Nz98mqHSM5sv7qb9Xxi4jKMde3ECvG4tSwns43S6dhRc4bmpmzAiOIrYCRdlo/oWC8e DrUmIWXzF+xMr0NWbjdohmM8Bu+3d//rgcpuJGg18z4S7Y5fx3CV13e77j7mHujNGjWgcOmw 1V4HtK4TWLgq5xGJnKGwhyIEBPuihD8958rHtdiSR0WrnXPlF1slcuoTjJs+yG6p17/PCuR0 eLJZk8+xtx9G69BgSwcHGmpcI9tZOFxp6OWo0kgJbs00UqKtZsn4BZE1Gj4leczTzoOiHYd7 PYgV7961E4LTQuVZHlvylUJFhbVtSBqTE4oJP/8ffagWkQplbmRzdHJlYW0KZW5kb2JqCjEz IDAgb2JqCjQ4MzIKZW5kb2JqCjExIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAw IFIgL1Jlc291cmNlcyAxNCAwIFIgL0NvbnRlbnRzIDEyIDAgUiAvTWVkaWFCb3gKWzAgMCA2 MTIgNzkyXSA+PgplbmRvYmoKMTQgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0g L0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBSCj4+ID4+ CmVuZG9iagoxNiAwIG9iago8PCAvTGVuZ3RoIDE3IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAG1XFtz47YVftevwPRJO+MyBAneOp3OpEl3mk4ySbvq9CGbB5qibSYS qYiUHf/7fociSAIiIOqy2QfLjv3h4NxwbsDv7N/sdxY5bhxGxy/4GiSRE3v0g6j7sM/Z/1jJ vvqm5iyrmdv+qzP8qet44vg9fQiEw/GHgkVe7CSJ7y+yLfv7Cr/lcjdkq4wJv/3t7stqy75a rTjjbPXElt+VTb4v8+YDW/3K/rFqSVPxuSucwBeJjm9D/bMFjrtO7Ic62ixqf2bLb/fpU8M+ sFCwpf5lMfXDyd8c//DH3a7aN4eyqJsiY5/y7LAvmnf2YRrtF7b61zSf/DBwgiD2+52xoxz+ jK0FfrA4IwjW/2fmnfC4kwQi7pe4SNRfH54PdcM8lwvLEgl3vDDk+hI2aUMOJuUZlJNHjoh6 5bwZzg2ciN8NLkxgRIkvOn7eSl0Ye044bLbTgHOmCAUwMzLijiuCMGYa9iy7Wf74zSe221ev xTqvWcrKPN2PllpoBp+4ThQGXr9Up8g2rkiDX5Br0+Hg6sLwBO4M5Yujf4J32rJ0B+LT7IU1 FdvnW+yjfGaP6X5f5PuafvhGG9vt83RtYWEAneFBwPt93Uvakeskgy7eV9oq9hmedT79UOes emJ5me3fd01RlQ9jrhil3S3VSXvOUovl20uxocWe8j3JJGW7tGnFlB6al7yER02bfP0gacnX I7XT9EQkiRPwQLBQ3bNN7cb70uB6zxMGieMPx+J9xaNiz+EZW2bVdovjBpyBaFhRMnCKPR2a wz532Aqfd/tim+7f2XOVbkiQZL1Fq+dZdaDzGoeTyeGKxMMp5DO567O2u6Bj1IQ2MFEgKol8 oZ5pJx5toQYXMz2ain1k4rnjMm2aNPutfmBZVZrp5yJ0wgBOs1viovOyRkQAFYZzIZWGXEge NcvrJn3cFPVLvibh/fyfj99EXhD/4rB/Vm/5a75/MEuHXFDMEaZIgu4lHj90/MD3v4h4VOx5 4iGVXVc4bMqqgT7n2eawHvkJuPMmz1r9T5/TokRYkuLb15z1cjUzUcRh629ZOEXZiU6y1XYx CniLJ7O6DC5IRVZckK7jZrjBejyE0HBBJ+JZKMigdByaz7SeDvsy1T4UpMS5mXaOUFMEfsJC Fd9KsA0ucqIASYQGN89jjg4TcpnmZTzPc7zIhftTqZ63TJbu0sdiUzQFRUnIv8wL+R4OlTiK rlsofU2LDfHfkb6dzKSAay/X8Cpm1Q+wLTeIEcJ0+7uX/+C+434p965iz/MfKYWp9eEROVlz aHA8Vns20gIlpMARYOaYH0YU2eMImCLjnLMYH9RviGdAUvZi1orBf3SL3SvCdDkd6jKznx3C mClFrirc0MVBpEJfad5DdqLCzbQ7NSCC6DcUyr935E/kFIOdd+udtYO2WrD6dTFZ4vBQOQmQ Tvbc6ODOkN+lKL01W/yFh7QadhsYV7CeBMhwdjlSHcTRzrPzgNSnhpuAJ1x9/+mBffdTnWej EH+hZ2CD17gLt/pjLYgTJ5o61qYrTh275h1rGrZBEtpZ/OnTP8GiJnPMis+97iDSFlAUX4O1 yHXgRRTj5Ln8iDdT2pto0EHfyZkEYYijuK91zHYmFi705q9hG6SmxTmrygINFUtEHIXsKmjU DAqE5BZ8LlxEzqi/qlyZR/lQdjCL0XN9B4eQp6+gKJzGEQu9nps4IWpAOtw8gtN1dVoQ0BJn L6LiVRxctwIF/lsqM9aHtq6KqCZDyQZ5FHLZdb7bVO/0jfnADnjsCD5a/qxrXywt9k6+L+LJ sBsbnPRQZmkO9o5PVGzv4ExWpHuSWSW+QMU+ivZcQvzdiM9m+mVCLJe4KGsYic9YMRj0s9vE bV7L44GThInPriK42O42iOXN7PBCMDdCPq7BX2uccCJ+hFaMBjfPOJuXlDobplqMRx0itIh0 cButlq37aOtwasRcRavskigpU0/7SQQikE+j9sH7xeYFWIwvqEf1Vmw2FsaIMKZW16AjdnDN JF+p0tZTflK9FknsxChKSi5NuQ8N0YI2uA/ht+2QE/dhjQNnhk4d9kW2/bSvtm2QSeV0CjZH ASX73VQzDtRtzNHzxXKX71/SXW1hkye4wykdnYev8b/NFRkKce9sU6Eo3RTbtrB6qFlXGU/L Nu+eIXWVlTZTs2xnkLpP/bvL8zgL9hB6qdhzRMGWVIersspmXUPAfM0CjzKJm2osy9BLBb6S yVzgpEhC+LP7wAXcQX0RTkWFm8fXqkQVH0ZkEZznxo4vAgQm1yywTd/Ze5FvbP0uD7rhBxTb XrOC2qVozyb0IDqTmUjJBQLTJEL7W65m98Iy4u1CrkOpVHfMlhng2BKJP2zqRoeMaQS07k6o VpRQ8y+SCRMqPVi65zqCcJUZAJSb7uHfO+yL/PvjwTLiMSRZKrTCBSmxrslo4UISYi4liRIW qHDzbKdrW9pahTzw4EevxH9QC4ksLUdGdBK5eEi+sRWYqSrRs3tpI5d+Lw8MBczdBq2OJv+j oTYfjGmTIk8yq3ofeqhcvFIog2rC8Xyp4YRAxT7LpHYEqTo0cDbWJB0ciBIPQlDxr2QFxqVg nB5yaBVuHrltNFplGBNixVPb30oRnu7Sfds2QPSUoiA9LhzLTNic84oYo0MJhrUkQWd957ij RSm3WYuC3sN1m73RYcppMxg4pikmOsJnPJyZ0r7gJaEvcnCfl7AwCASxndJKZNv0N7RzCnQY dzvMvaCTizSrIfujnjrauhmqqZ8/OJa2C2UYYcRDJim7VD7mTaO2hdKziHRoRbWvOIBIpcIv dABJ7Evkg9E9GWxSFDGa1GvtCW3ffLuDXKqhv6766dEMCSRlHsMTGMlAP54zSeWUvg9nWeum bebT63vkf7EJCAzGjbGPfuhcwUdxMmYFk2elXKMTmqJfAztah2xhBwd3UYLQwGY6TjTQaD6C PVYYqJAOk/qsbRWhnSOiBpvFT3JEtC5Eq/LLvJfF0tatw0hi6HoncIbdaEaILsyBZkPspQmM KniYpFMJtntIsyj7I1yEnhz3WGDS11R81MU6q/gosS8x7uUTjsBHzOOQ/Wqh/DD6pR2L5KuH ITH09c1y78dmJHF2m4YSz5tqEgHNIk9E6WoDS5P8vCqMhj3PpnEitQMzVV0X7XjAxxFj+/BR Y+QoIElrMxP7sRmNMpv1WDzBoIx+QrMDp6nOPZioYs9jIjiI7mj6WL3a5lu64oPoVrhI3REr GMu05G9RqoWPVJHNbO5a09NT5QOb0bgczQDcDMdDx4Xqd/u+rwtRsQ3+VPNOFMUOEcK66ibH qpfisbC0i7zAdyJMFjHRLXqba+gbAhqcYQ+aZ6BosisxbqoMDS805o+3CXbVpsjQinDY1xbd kRmfXPy2s3pQHbrB8YUGlIWKbeCTJuueLel6W9DFi33aIHqnola9y7Pi6d3sxjwEtl7sBkyu fKPA5WCGBmfYiCbwfiNSvm12YXYOwsdsvCsQcqhsu9KahY9xUoHhpjvBoewuYqR0GpyBF5pQ 4W4xkL+2+FwBXscJpVF32X2v3z5mnjHRcLEvM8upT0U16Cvl1BfpNbiZjFUuKEmVc9hHmEz+ R4oeZ46altlifFQARCxCJle/zWJ8OFqMB5zAGTajWUxrKLaGm4+WbJx4sU7tEf5cUrQtnl8s hU7igE+VScmK2zysj+ZgmJygGTih2cs+//1QIPkZBcEYa+x0cqLAHviR43uwHkn7WTFaZ94G 64lx4+t8ECyplzMSlmNssB4VWreecRHLAjdYjwpnYLOmcH0JVo2aH2h2H3cHcPSgCNtUZl8w 6Hu3/I0642HUlm5++iqcYTeS7V3VnSKMdf6UHjZN28KU3qBl3/Rwo4hdJ+Se3y/Y6c2ZBTs5 H+11zoCN3M+UWmoysQh7UMsQdRwELfeCC6K29XojHGgKQ0zFY2RsDDeEz/bc3rLxQcs76E7N zoip04sV9AJjVugvrFFgwZ2htsC5rrKDfdqqj3e1DemmOtxLsGbWuDl6HIDR4Ayb0NQC4f/x hiI0HGEhXQ+paS9m2xSyhCPXu4hpGS764hrWhtElw1q63qm2HvcczqOgF/ttLmDQcVxPoi7h jXC9Ut4FbvDed4Eb9FqFM6iE5u/yEgqM7AAVfHJ97bWivC6eS7okV2YFYp/6q+cDws5NUeYY kKZuXq9H6AV0AZKluB8gJveDxGN+R+CUi1DIsprAIFwfE4KDAxtcxB3qIr6KfeTludgIlkSD L5++wQlCLGyPQOIqHYPoSpKpKUVl9pg3bzluPcCvbOBeNul77ZjjzKC3EpW6K33JwEicmKNO 0yScjErMrmKAQxF51BnR4WYGJQOciwmCQcwGtVY9HZohHtWQRl2QFVxQUVab6hkTM+buBsdF Rp8ngvndsje6Dtnd8GLcgLjfBXgvCtvCakedSfcVq0K0OqtArWEbGK5Cg+E/5fsnXDmkrOkt 3a/poQdcS3xnn5c/ffz0+cNf4CFG4vi6pjALLgUXls3SIDP0MXIkSZryHKrkbZdtfZQkQwSG Glq/QWto0d1EFYlIfrFEawIX5IIYs5JykXvpD04Nn/eXCnSjGsKHecXOtqr3he5sa9g9e1W3 rOrP8oe0NLuWfnxGg7ZxQT6YMBFt9OMzGtw8SgsLoRwjADEG7JmGfCWhHMPZKHcnOtw8QnHy mFkKVcJFR4z43InSrtqvoc0iFL7jh2K9RnvyMz6sfvj8obukDJcBD94GA+Q5Bpchr4VLYzQ7 ECrg8RiP+GiE2QRiCYf7Q8kT3ri6fzMcQqQvVUD2VOy5Ilnt6ZIJrsB9LPb48F88efF5ufrx 439PXPl3GAjpOwsPjH4HLDTLxMf9Fx6hLXwNZUukE3gjACPIZt0WuG0Yx7htqC1wpZQGHbqC k8s0y3JcCcKYtIVgjPpgqtO7E8GDluKqz+jBqvlRgjVQwEBNEgpM7noq/CzNWlL+UKMZ0b1m csBLDxn7LX//CtHCmh40QbqY1nWVFfSwyfFtCJwN5vc4IGxMmklapiIE7aixpCoCXjEgzex2 1qGZdzYOZkF1vieabYKGnYcxzgd1AUUz5wc0g6DdaLrEaA1pIOWZgu7gu1jGzI5xGIKUEdJs 3h9aGWIGcVSINYvTCxHx0bUvT92Sec2xCMjOzNz3EEfgGTgcBir2ldz3EjSHkvgErifVyvx2 Su6oMijD2BrePuKViONRMkn2RWL4hDv+KIRDFja9pOgST6boSyicOTEjY4u+10vcCxy/InZv B6TB94y3RppqBm7WFo4Ui6OTcdUicpxf6T1IAUz0HnwunNjF9XW52lnP05qaHO6vyZu2lQZc yIUH0vypeZN4DwrdfUSYct07pSs8RuJ7TX4xzyFp8PMEj9mftpqPjpB8EqdkFHB24SbKNU/t +xPtiGv7/BFbF2uzr5KnhaTm7NljrWsJhNAxTjINzbA37ZCgoSazlIU0bw1bMW8N0QI3mHd7 k7lvIQzmbfV87aljge/jCwSJ40F6AydUt4RkAhOOWQ4jWGMypDOLz8vXw6ZEnRMzX0gv2to3 4gzFFdB88qhAsaLsyRzEigC3qF00fSSRU8K/hqXozk4WNe/E0g7+kiMELMW7D32E3817d2M4 FO2fco7tXtD2y9mfNnm6o7LnU4o3vv6EDOL76iP6ABa+UnLu4nY6VylVVFUVua3kM6iquPKR upkOSYWfpapLetmsTWFJJeGccEeDrlK2tygxX9e+0PNeVuX71lIU9jEOF7p4KIl3JEwposIw qxcaGIZu+OhBOsOONA3/mUYD2xGdY3+MdtXQBC/5J3Tj8T+zao+yIG7oUNqI9gE9t4dWA5Ql L1+LfVVSPw23CcxuN8DtEjxBFTKukmhWkZk7Bu6lheYldkheBHky3YqlI3i0I7rpe2y50VYR AptdtI+LsEmExifdnSEqZhzElhKXj8FbL8JzYBqcQYyKfrBlZXnCzcdoNL3LpQGbmc+WNjrR hOZRrKPNI/ORcsltbqscCg8xeozHQTRy5y3QNkcxdYV5OXmSjCSo3dkeLAex3OgxujlLLZZ9 8jikTdpTRKRbL2n9cmw+4/prnzqPy9EaUZhdw2gSnnfgKlE2ccmjeSJMHfaIR1dGM8ln4aYn J3o4zK2huO0Hne8aAonpSF42o2a1MzRsgzg0R/Zjaamd9uVoDVrhggZosYG+HK3B9ZRaj/43 zHSSHazeLCM2HAFgEHLO5BK3eReOnnMcok6iwfUUT4utG6Ugir9WLiawvz7RIVGUfzN7fV+g zpO4cb/mnc65CM19JCry4VVFhtItSn0bGb/2pk+vybjIRq9USU3W4cbFCmlnEx2KHi5on5Lq 4QwMVnUN8dq3h99eqteywBKjkHbWd+MYeNYfjFf4xx87TNzV7GP+uD/Qux88fEBNAXmtEltf jKv/gZnIn39Kn3Pm/2KNMZFh4AYBrjd33J1hDaBAvhvz7/8DQadf9QplbmRzdHJlYW0KZW5k b2JqCjE3IDAgb2JqCjQ4MzQKZW5kb2JqCjE1IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJl bnQgMyAwIFIgL1Jlc291cmNlcyAxOCAwIFIgL0NvbnRlbnRzIDE2IDAgUiAvTWVkaWFCb3gK WzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKMTggMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9U ZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQxIDggMCBS Cj4+ID4+CmVuZG9iagoyMCAwIG9iago8PCAvTGVuZ3RoIDIxIDAgUiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PgpzdHJlYW0KeAG1XVmT3DaSfu9fgX2TInpoggAvz5PGssOzMWFp1u3Yh/E8 sKvZ3RzXZbJKrd5fv1/yAAlUAUSxWp6J0BFSIpl3fpmA/mT/ZH+yNAizJO1+wI9xngZZRL+R 9j+pS/a/bMu++6HhbNWwsP1fs8JfDYNIdr+mn8Qy4PiLkqVRFuS5EDerDfvbHZOi/TP9D3cb 9t3dHWec3T2yd+w9u/sP+/Gu5cRGjqeBTBW5MAh5mLC7lZPw37eHst6WBzt9HsogFjJnqU7f xe5fHOR4GGQiMal5cfsv9u5jXTweII1EtkLRfrjRfnX2j5z5zU/7/a4+HLdVc6hW7Ndydayr wyt7b1D7N7v77/MKEHEe5DyDJfQCYp0+/4JvikUMDdy4ZMXG/+xSkxEP8lhm6ozeZrzE9u7D 8enYHFgUcuk4IudBlCTcPMLJu53caOVhHKRcmeW15JIc7pML+UZOk2RRkIxOczV3aQhbUB/r px4RMN0I7VLlCZQkZcSSJQf9UL/uDzsH9TyHyYbCpO6SisPVI2hexPyEnJ9UlCd+LJvqaeuI gCJMAp6kqcm23zmf62q7qvbrsrELRiR5wNPMPMAlFwe/yjUSRA7xdgkgkchEqXKNMf44MwDC j/3DUx6EMk7w5TptP9F+aNh2dygfWLWlwHqodlvGb9mnH35tj7w5m88iySFrIdWRfTidOfKm S5RFtWmYy8ajLA6iLIxN8poub7yzb4SoGWf8hJzi1hn763Kz+1Ky+6Kuq7ImxtnhuXToQ4o4 yKQ40YfGPfPmfrREkcBVVdx6W9PRaSvJOK3ypXoom31dFg/s2JRs98jK7YrCF9kQ/k9iGmqX 4P2NrTgS+MIYyZklPRO9MdnldeOqtUSC4iWPTshZvskwow8OxYpUBDJHlWUwqig77agpV7vt Q1G/sqddsWaVI5TJLAwSHiEo62qxS8Sv+kwikvQ3siCdtpKJ04L2NUJPF3OKp6LaogAq8Msv JUU7S+hBQR6jVmHDx8xaC8nGanyRkIjHJOqe/9lIdjMp+YvDoVj90dyy+1fYfnG/ruxhWsgs iPIQdjmedIOWwk9S2ycE6BViUbk9wHrsx6DwCLhEFToc81ZFGBdB+K0Sl07bTyIP5X69eyV5 UOQpjog2W3QHBXKZw3pU4uqPnFV32+H1iet2CHBIl6vdZoOGBOch2gUOfVAaGw8jjS90Y8l5 IEKuqF3UXlA+b8ryD1fUSTJqR+EKujoWsjvmrRDp91vlLZ22n+Uggxer56pEVndncp7EQZxw iHzJMfclwtkkwu13TVPdr9vYhi71hgALHSYQPAnSLE7UeRda533RwDL7zLsq9sV9ta4Olatq llnSNkPqyDcKF3GWB+k3SjUGbT+lI0ZMXBbhdF+imhsc94wyIh4HeZILNhznlWiseUu5Q5wi D6Cb9SJnzVtoLQmgAncJbAbYz6ypTPMWH777DFaFZhugFxopg7IWBvqqKZqHvmAHHZJmkFNa cxZNH0tAX5tqOzjNGX65RLkNsGqgf50B8xjpUwA67MV6UZD9DJMa0akfDAc8X8+I1swmJ3rY xff2ekZEERAiOX7ALDl3MU3VVhKfkFPa05OZWUw7EQF0qzLJTuysI30zg4kin9lzroDyRMpz U4uaCft3YCIl/Ck6IWcRgkGYMsButVuzx6pGQrBzLcF1HCUnxyzkenQ8hJ4JhO3H9cPgeGh4 n13eB2RdoDJhsX7KQqZ5JoIEQKpJzo9pv5QXAdGJYgmQ/01YjqhIwH8mOT+WkZaoBqFkxF6q wzN7ea5Wz6w6oEFkaC/KDdrp7ZPd4WNUhRFgZ3X8dQ4/pimJZndMUza0wfD4Hie3G3kO/YYS 3Xms0++kNef1qNzGJF4GDmfigKBlFCJw9edcHsin1jQ96cYo2kIgeiKHyZ77Ivds5+bdpni1 C0tEyO0yikzSZ52r71GmnJrlpUALJ8UJOYulGqq9d2FegJCDXCYoR84JYU6tD1WzAsZWo3i9 d4hDgv8szpHqdZ2eFcd8ZSIlaqgE4zeDnEUcRljfHR3zOIkQEyaU1P05dYD0EiFGtEldJ+fJ 6aPdwiTCd54AO34jRjOJ6oNqxyWM3hfbB4f5xqiUOOcn+lqo/jHSCZrbLUDFKNjZRTtGOp2+ p9JqB2nOoyAOMZ2Ol5CutnameQQZh/kJZZeMHYbLwZ/EcHoZo609bMpi2wTs93d2piPgFSIC 4L5IHH/ftucMBU+L57Bqs1+jb2bb8ml3qLrfuy8PL2WJktbalMWYAEt0O4qRt8rFURgg+A0t 49vnYp1+Z6FzQbvrn11WKlIMlTF2iXvyHp3ZJ7uWAWoCnopOyPn5kyta8zgB3C5PKC81+iQC pAIUx/huP0Z3jmjNU5SaPD2hvJTRjAcZz07I+THae+fqucBaxobQ6fXxoUPUMA2yO4kAdJFh jKLEc52TiDQJZIamSbdhi0huZhZ1BNAPDvTDJGcRiVEioZj/+OGXH1mNUU/94IJawXRCHcjI 9DXAMJjOZYwKVHc0C9NmIePKNDGAT1gIQqtO2iJe7z2oOMymKx22iGawekF3odP3k8QKqDBK UEcIUhFtCfk/ytfmOwdx7C9EPIE3LiGO0dADzT+KdeP4AKylYCGOvGXJGcXqz2NFRfqXqrB/ hyBLQRY0z1hoMmMPtITlu08//eZgVXUtOm0Xqw7kVMRAdtEzX/Llv793sJdgXCuzi+g5lD8G Xv1r/ZzjDiiF6ohdTZpqffRTXDJ1MD22Pjo5P6b3z5iI2AUs8yTIkvzEHRbyqjoKib1TDky+ L3guim52bjNq1ajHNsgv5Fb1JwY5P8nq5TJQDBQAD+30FXhWcegGa9ZCWXBMh9I8U59yZQ2A rkUC8THJWT7FyNot9mYXu0B1mEcyOU98rkpuju3qqqsWAH4kBBAxQw8L1SrRDCUCzZBBziIL I8NqY/Rbh1+i/UTZhU7fOGYh16PrYPUL7A/71he5joPd0dh1+n5S6deakPlG9BFT/1t23GoC cxS9GFIlMobv9udfafBD4jLIWT7HMHj1OXajlxRtCdQ2DtDUa5B1iF9yjCAwRzLJKX6dQ0BD 6HauqarJOBYuBq49Ok4H16NRYvFr0dKmJ0KEmmFKX0lFH64ZrrqrMelfOzIxxphd/22Q13Ro EHVIQ/XfBjk/bvdrrHcdyq8H3YWGaurc/D3HEiimeGw4b9Zl+iU4y5yVVjhEdkJuhv0eVf/9 3S/YVOtSW7/r6AaAB6h6wvxch+fA0RRUPZC7aJrhghQk5t1pEqVKyh4u42J0qP4WMToDAKPN D/IwhXvr/rLQoEf3BmCzaLHW1711+jMW1w8uxlqbDbVWif2z4Cm47UAG+D91N7c0KHzYvWyf 6gLwS41F/OZQbA9I3tbya4yTPWezruVcEhgFGdO9oW+HU0qdfifIuQqMhgqH52ODVazysayp f6VZE+pVeyKJYlQ3IszZcOJ1XhElIkhR85rk/Cyh9YopEI2V2edt9eexxPqSVcdjyNCFZncW p46lBMyWcMQJnZzlE4zSgJpH2nq2S1y1YgZ9jV2DqiNZjSYpMIk7N8Z2Vhz+QJPs6V8YkGGR 5LbdrZn9cLuFXBkj7k3xtdpU/9dhqQjeVh0LbEsA90Pfo3+lRSnI9dMlMDgDfAFr6f1lOuvt RRoSihArBvoxbgnaVT3qJkrbxVBEH8qNb1/r9/Qv0k1T1l+qFUY/WKMs2L6o6peqQeRtu0Qs WFYupxOoc7nEjq4cP819bdTpdGqFR2IxNFwSWO1awL1TujYEh9ZpL3Q4tY8o6Soqbtf1KUWZ otNaoqEOPLPfp/YRB8qOWHzJPqJBTjHqLLo/7Pfr13HF7/NuXa3GEvzGXOiNaCBICN5w2Gyi Ze++J52dr2EjWFUqsZJ6ATlHGUB3H9qrhAY5uyim4ePn4gsWk8bi5KFzEZ94ggtSYYQLP8O5 Do16XK5WXiJy1LLjIN/+GdNb26rOwrj3lhXb9uab2tnbUsdSQOk0DC62r2y9W+H6hfrIPRkA 9qutITqO0NrlqFkH5mYtwC8ioJNBd3TqZrr1GgkTV/yKhwdshNOKOF1jc4QHQKPtJdbhoIuC aAmzeCyO60MnzRkvUTurw1mzMnJ3esPOqkFuxh5Up4drEuy+XO9enNg8PS2A66xnz5grSV2L a1iXwN5drghfJPd/kHXalYqxTJBnuJk8cH2d4yGy4ZpmfEJuRtB9g9O6DrnVxs6wWm40GPY7 AaC0nfQYNTB3m9x99yNdl+0obAwEqmwwfGy8EXlrDxKUgtMMZQPdYSZeZh3AGSQkYk6YYSfX IGf5NCNIdC3mBNek+01egkTTNNmjspxmAE4fWGsHr2xTPT0fqH091NWqmx80ZXe1a/20w3MP z3RpmEYLBR7xwFosLn+hfP393SMaYbtoRzVTAzMbMI0SeaK96Q2zFvslOOuJnqFAV35YBc5g Meyji56J6/xO7aMb5PwkTr0Y3QYbInQv/95TzgBxMawzx4InG46btU5neB41gvKD3mHoyc1w 34dndEgNLWeV3zOYCt24bJ7P3cqzOz621eklgoyJ/vyLImybO6tHWG13meuvU7vAhqy9EKBb 4Qhj6thZKTp9fJQinJ1mjW4pGj6uVs7xJfRzVQThGutX4EfNXx0OD1wkSBJsuWHnbjrmnFFg H/ZrXLurHauzYrgWYlDX+hIjiLiYjQG9JJg0GuT8mEWRNALXkJWanLQnni/SR81gM59GWW7N DJ/S27c26yA8AI8zKGNzheEIq7cyzlBo9sdeZNb/02qFLhpYUYDRb/QDlipG6Vknt0AxGwAZ 6Mruy1VB2LzdB0fVhFj99gk904ZHT4nspdCVQ8rCEtxuSwAs3Upur3OQd+mR9r/s/MW4u52F mF8JnT+7iP1iRJThFhfe43FbohEjft69kFEgu31F+2O3Cz7cAJqcQnCOnyJXFZDqrqnqExGB szW9LNFGpkF2lLG6P+DCPHNMLek7J6y8BfwSYV1vgmufVUfvv45QpCASujEk+IXqED4QiUFZ Y7RX7yUQiUFOadSJ5fzYlmbsc1k/4mkH9tOufinq9kr++ae5FKgxnHZdcaRADYOcYl7vkIfw 22UnPF72a4lVutXr91Bk/1SZelXsFN7BiDIVKCWGs9wONp7VrqG2Jt1fDnTshwj4VxJjn844 5JxyPdASwozzGHeKDHJKPk7l/vrzp9/+8dEeDOgNtDQG4DVQv06ZuCgGhAqLPQY5xaxLme+6 JoF9/ql7yui8+dHgIQ2BqRlHaOIdNTe34apSTESFx3gB3o9j1Bt22XJaFEoyCEMnvZBT5L8g RJt4Cbm9gzusdKEyPCHn9+HdOzA0ovtS7Y4Nsnm3Q40OT9Vc9rxJjQnHhtYgmN4N7YJxpk2B kbiUWDwwyFm+xEibegH3WO82yP/qVSS7/EbDQRFAWP9F9RsyNbC9R1yWx9ACLADA3GBsQS+j rHeu66OqbIz6Yz1k55j/44Eb+D+u6Bnk/GRHd/3tElI35Q3ampoNbTjcSaGOBjnFqjMQ0jK3 IyNjnaBrOwbi18XB0ThE2E5XriOnJnAA4adXw/0ncHYtqdfoDNpKrM6QLV0tDqSQY+cQxqWz 7Uf6FwxWq6YuEWMalOf2L+DUSSUS/r/gGFQQ3W0xeN4wJRhrifa90t/0pcFJgGOq1Dh5GoYe B0gyzBEMpjTj909TowUgqdAcoTcofwvAiNwuQrWqjBvYU/J+mtJD6IaeRaUuGBeQpwpEakC6 RMOHN/nsqUGGyHI8zvGwaseJR3xz3TWUAD/wTM8JPcuXGeEIUKVr7YR2NjIqzRy8GhQdSlA6 5lSmjt2uZjIXkAM0nSQiZwa50WScAbNdqfCwmIH6RelvvXtyVNBU6XA4j+LcI3q64FyOUkcS pmTwqgnW3xfpzm2a4mE4g5zFpAzCiDPbnWOViWP3KAYCZlJ3MetI8DB9zL0W8kqQed098NcN VbvX0zBZbRgNVL4UawJO8DSoFUaljgAeMohq1pudj/+NHoKQjweLB6huNOmTZDUFhLotIR+b 1sl3ip0bEupRsF1Zw3R6AkJNa2NG1zC35doFjvSS03lxmYErrAI7x21nRrlyIji7yU7ldke7 T+PSk12AMVgWyHn6Ke4w46AGVts33Xn7nk+r7Yv3juzkVc4byF8UwSCRc9Bhf9yZqUwkgBVm GVxh/BrCuuwqmL5k2D5B2oaOA9Ufu2NdPNE2R7/bTNAEBpnYejiihbB/M42GpMBF1oEJj8jq lbHwhuvkiW6HP05XOfz9USc/I7JhXj1ANd0UcveI/Tm1TjHdCRlGwbd4ywddWXPEez7DQolz UwSbinjlg+FNkulczO6hzi52jG2ye8C6D5U2WZqFgHe+1sl7xjZEMpRzaooLGWGLpnk8rtev jq4qAoSKt+UF4/2h15mb6qropsTkfodd4v1g8zySpPBdRJl2unAdd6MCsVQ4ebV3IXcjOaqI 3+41fbytDSxbxG/0sSmqTCTi4erktR+LJ03prcWBOy9Pp3/B4vjH8+7LtkKsMv+9itbpzN9s 7eLS3zT+8Qr66z9+3eOCdcN+Ku/rY1G/dzSEuMWN5Rs89LfwE18RZ27pn5uIv9FH9r3smdQl UfAm9CrMwPpMaBoq3mHE4sggEg9mZxnwJ4O0RfFG0PvX5+KpZK5/fwMPc+c5PbXf29W5+tMg +m97+gSYgbfbsOx1ATnHxysXx41V2oOMPbibkPvn/wM5PMSrCmVuZHN0cmVhbQplbmRvYmoK MjEgMCBvYmoKNTA0MAplbmRvYmoKMTkgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAz IDAgUiAvUmVzb3VyY2VzIDIyIDAgUiAvQ29udGVudHMgMjAgMCBSIC9NZWRpYUJveApbMCAw IDYxMiA3OTJdID4+CmVuZG9iagoyMiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQg XSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDEgOCAwIFIKL1RU MiAyMyAwIFIgPj4gPj4KZW5kb2JqCjI1IDAgb2JqCjw8IC9MZW5ndGggMjYgMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AbVcXY/bthJ9968g+uQFtqq+P24fLnKbFOjF TdN2DdyHJA9aW7ur1pZcSU6y/76HEkmJXJOmbS1aIOk2GZIzwzMzZ4b6m/xO/iaJ46ZxMvyC X6MscVKf/iBhv2kK8n9SkR9+aj2ybonb/9Ou8Vddxw+H/6a/iULHw18MSeKnTpYFwWK9I/9Z kTDo/wz7ZbUjP6xWHvHI6oEsyQ1Z/Unerfqd6MR5iRMmQpzruJ4bk9XaKPiXqiuaquj08j03 dKIgzEgiyzdt93uDOM910iBWpVnt9iNZvm3yhw7aiMNeKdIvC+m/jv6RIz/8sN/XTXeoyrYr 1+SuWB+asnsmN5dJs9/am8Pjoe2I73rhDflMVv89bt4w8xw/jj1VYSb1W3mLGzmJJ7zlWnFx Bq/OgnAmX45T34lHX756d4nrZHaHhTF0Ny12ndBPkpjEsjhb33Vk53j3Ld/tt8W/iOyBq//d kbIid+9Xv90s9H7hZz7AxM/EZogRRRa2KBJHmRMAlEziFvagFIdAxyQImbjvoasoiF6g0kKB O2Jw4cRz3DCKU9xlSfZghsUJwHufV8/kfdG2+WNBVk1etQ9FQ948FlXXkk/L96s37S35+MfP P0VRln7+dEPaQw8QpHsqyN3qzR8rGOhmofORMAsc3wtDdXN6D15YgXscxE4QCbPMq0dZtpUe AcWfllRNge8mVE3vqMOS4ltXVG1ZV5KvL3q1knzdldUjydveucl6WxqBzw0AAYlP5KMvrG7b sjdn3hT62xwiDrtpBEux488FXT7i5RjVdZYiF3m8LNtOFXDtosm322fytdxuqQW6mrRFtSHF Li+3+Gn3VB86QoHn0zLHz+HqTfFQI6Fh/8/g72ncIyuJ2dZMuNEnM5b+7gWO+1q4Icu28nc4 1Lp53ndw7U83t+Qe+qLahAr32/r5qO6mf4N8fSoqqleDJrPMiTzqj/L2rkYO13Oi10IOWbaV JoEcPVS0RfMFyJtXVX2o1gVAgYErR1xAyDQHuyvxp3oULquyK/PtADlGCEl8J0vTiMRsnzNd 8SjNnOSVrrgi2+6KV8VjDZVQ7yRlS6q6I7231o9Nvn8q1/lW73d+Gjl+6kaEr8xusH7lxaQw Aarsm7or1l2xuZVjpDaPCsPM8VwgO19xLrMkqeOPSeOsyBvJsvXKmVRt8PR8Ax/vyrbYISBR 03w5bCka32/hyjV5X67ek039tYKdNgXJuy5f/9Uqjv/zoaGAfEtobmJy9wiVGvIP1KZss4Ml F3oEsSssozh2EpSAELdAnTqvXpls5gK2et3UvZOPoa0p/j6UCFj7gmLKAQqrUM71N0JR5+rp 0CK71GfWASr7IInhnuO5aX0+7O1UfomVyaEtSP0wAJohAclSlEx+LNY5RwdLmoVqb1iEUt3N IniCrN6rPQE504SxmNcTZNlWnrBEkjIkkwyEqGVFao5Uccq7eCmuRxx6JGIrnQS68S4vlnUF qJsIV0gd34ucLM4CS+FKvZM/5mUFMmCft235ZQQC/XpBnNB6OxXrzYWhYTAlka52mMBzMiQf V+4O4TaOg4xEsjhr/9PrURSTimg796OIjKCXA9ppKd+DvFhroRJ/HoDFjSmwsGPYOmBfvPP0 SMh/QSz6qIfDBLWnIl8youJ5JpeOAidJkJAq4oRqjIGlaDtEubJ90u83ABUYpiEAUDartF+1 TjKJQ5hKoxfixH6NRGiBKqhPRw0aCRKa90Uv/NBuhUlUKjb6Y4Sx5yRuNnrJWWHh1rB9kMNO HGYvtn+hvoGiA48d+bBjIC659a00bHW8lrJsO02zyqvYoMwFoNaVXtseUiUvDhAU5IUu1MkY Y2RxdvtGMNsUWwSAxqAaX1zLS5bYDcyXFCeVUDZey0sWqPuizrD/AH4TZR4i1yXi91tEyg40 k96koec5gTuXRUOkUrHrvxBnZ9H1E+rbYusYdhuntFGDxEFWx4UOOF5KN50y6PNeSlm2nSr+ KNa0BmoK2m4x+Z8XR04Ue9D4Jct8XJdd8e/PBgccU7VL5D809Y7kpDrs7nFNkeVv8wZMMvLP L+WmaFqwF4+PCH4gL0QiqlywEYfZBlgeoDe5HWcWIr/whjqN1is6k6sZgBXXrsgeTH66FkJm hLCq937P95wwQmbH5V+XKHo+rXvQX5hJXOA74BN8VZydw+/yP+u+lUhLwZ4c7+nWDj0HqpDF 0W5u4PpOGrupWNIuR2QdmXZX9vGOgAeihSjv7g6k0Fe9HUJei86jOIFCIcil+JVSA0W2/vaQ pcED0b0PwjjxiCLOzsYDKQzqS69aL0CfAc0kdQHTfg3o5YUuGkGJKs1uu4zcJ11D6X/QUV39 NW/wO5yjyNu+O7Ope5bbMeAXD4lcZdfhV+ijZYYwK45kEndG65HC7KT1qOp7ymIa9D26cuy/ WgculGXboevKBKxgqLMwRa+ai74OWLMYJsoSODHb6VlFCS9diUyHsjuzoNM1MlUDd3A82v3h y52FgvBr/XX00cV3E0yK2IlWguWUvtWvEQRAvTSFR0t2tWxd1n2jdGSB0CKxKRf5WtcZenT3 iM7piKJOvT0jNWbmkDlzE8ridLmJWu0bDClKREW0HRK29a7oCfWBvhGOOXahim9P5X3ZkS95 U9aHVg+HghXgGzHh1+kWaICOqgsqkSjiNOdSHJQWR029py2GctvPMY18qHLJQkyQoDEo1pnL cYKMdm455WdtaStTy7I1KpGdCF0YJOdouOxaOleDtKhsRrqu7xCoHReQejkKlfaw7W5JiVLT 1CzANEoSIUVkW4PxaZPkwvsieg9c3Fk4C+Bb17udHphC4GqYUly9QJGgwA02CoGrcF2k3peI pjx+bpKO0gYs4ajmuZwVBQNtjjNx8zqrLNvKWZf7HN7Je0fGHo8HAExjEBOYSZueweR5prlM ToQp4uy2XVS0pbkZEFXvf2Pwlfdstwgapg+YYyH3aJLS7ql+nQDOmGY+qqhL1rHimBgrpCxg Ur5hv2PU9QD+Y9Sd1x9l2XY6p3iC2dihk6pXuBdh0oLWOPIaF6rDwwwi+qJnCDOUtoJOUsTZ nZ+N7fQDPuDyNu1T/lcBNyy37a0hJQDOZmmGBJDp48qUIMRgQ0ZJAVmc5ghKSgBo7aeP6HxX v3GywYgzxsD05owwHOxFEbBlFnuO7k1nycc53HndW5at0c2L3IAR4iiJMQrK6BNMDLBB8X4A afWEwIp/c1Mi4AOOg4gW5mwfx0yuWMZgAcwZO3GE5wWKOHEsY/ONFvN1D8n0XBsD/REA9lEo w9Ky+kw31xBFAvTYkyREnJbFiW0bE6P64cHYv4Iz+pi7ukz4usZgaovxVDq51xnakhHakkkW jqqfKdcIkG9jjOZVcg1Ftp26P/x0B94a3E+J3jWmnvV4IHKNi9YBr4TJPUECiFENPvVgwFFQ OGGGtyd8XXap9OebsjonRjZCzLzZyVWuLZvS0KtLDLgp4qVLpQg1aF/AZ5DiLQiyA6aFET6N YECsCH4u+6yCgw2s/ahXhSD4FfmSKmRQNs3DU4IfIwlwCKaK87Z7j7HnDnyKzLD0wZ1GxgNq PoKhcdLScY5nvV9SyjJzgZp8G8fAXjqVXQcniMGXID6+MLAMm6rr2BlYlj1coVMdnBd0Ai+l DR1NH4R3mvgB4aeZCz+jZI5ZIj61ANb/oqkFva+jbxm6sRsSRfSFvi4ILkWcHvympNydILiG EXWa8HEI1ju2GCHia17n2GJWQRGnOYLi1/k9Em7WyaLJq8i/9SbgvX++3nWuJ3r/ijjN9qUL T5Z85N+A7KITrCxwoceMgQJXcPLebQwUMo4oG7YMFLJsO130Y7mYlmMFyGQUCtM5hkJKEAYB W/VKf8Q4bID8lCjiNIdQ/LHPJ8A7lLtdscG0fbHVO6IghflKZwWqZz4HpF8gxKsllGkIQbI9 rnYdhDY6RMD2O6/ryLI1Wle8kvax2xxsPa/U5AmjY90jH08jE4zUBGw95jQn1mOtRQv2x0fR hGYY0kd5AUn3ivMYUEC8wFDEif2a0jvQ26hsKjzAwE0aC9e+fv0A3TUDJ/eUo6F0XxSV6U0p fWucZl5sPNdoHus3pQEmsugUwKukNbLsQWen0poaiSBeH+GlW41/t+iWdJjarzC6Vj6U/djg 9oFdvWP+BTI6xdt/opxLMv+opv4Bf18z60Y+kJLQJ/GKOGH+46DNRz7Kxwo7XtNnJg+Up6OV HH2ehkdABvRIXSf2aI7G1HddoBwDj+s63isRPIEs+4R62IcTim97PAtR9dNXnj2ZTNMiwSdr J7YCTsDxPZxElGkdaoEofS3KzqfKPnH7lTuPqQC8PulbxvquVYhBZj/N4HKyTk0ebAAwYX4/ Tenb11cJHopsO/OjkCsxoGfYuyhQL5J/XwBYyxpjf7Rs/PXDCg24gWaid+/4fRdwz1dUDW68 74y+Iip5M5AshhvPh7/5qjPdeD+Jp3MCs+YLimw7kyPmPaN5S9/dUXgXl69vjYpWxkCJy3ko o/VNk5vozfto9vKNMcvpr41d2e+jcgwwJ8bE6XSoZhRWZb8ie9DhqfhIHyMV+YY2Isfq8VBN 1EVfe44PnG9l5Zpmx5IQR/UCouzrahXSqfj5PluBL2v0fbhXsYgs284ivw2PbOkDX06b0s8p TKaExFM4Ov6kj2S8M6qcUH+3ppFsU7Trprw3Pl/hw4HKApKBVU82wBYy7J5pU8SJ/Zqi47I0 vPwQBRSXPBcgBu6r9bh8WbZQwvGIwVKgj7/o1ZvSF0G0IFYkS9Y6lsoe/1iRmDpUxNlt9K1T Fh3Pu4986UqQv4r0CzcrBnMVcXab3eSVoa3GOtiK5Es3yh9EKOLsNtruur3eAbwMza6YhjTZ tS7dKn/ieIY4Q+/exzdg8NL1xe7sTm7s8vmcJDhjp4bGp49vuUWg7lU9Wu0UNTx1p88vUnk8 n9j0HzwDD9/UmwP9TAblQzDjt8NEoinBZ1++4KczZyrWlbzvDZ+se5W4KMseNHcqU/lO/XiW wdX5hBM/BAN8KxMt776jRRVR1nv75td3tH303Y+wCwIvs5YpAgvOl2/DbBqwB5ZJpJscbw7K wUENvXZJpCzbzjS8EuIVC3VcWrUgiQBnMek84ycPJSUx+vFMqsV6faBvqXEftIkMfbFCv96E z09Nj63HLTstetnwWTyTUc54g0Dfg+KZPme+1N1NcytDjSrqaw8ftKGfxTu2O9Ww+oswikMy SNsEc4nDd10mn44T98qUogH63h7+eqq/VCUUcPoDjtMvAln9Bb3Mdz011JKfi/vmkDcmOAVX Ar4EIyGe5oimO4YjPhMvvqWfeozO3HPvtKe1ohzSEBfQNUgp8cMPchYGfvyNfjQv0ntWCFox y/BpPkW86vfTRuVnkzjcbfrq5AxxVtcoGD4ceF3G79E3c/QLsN5F4n7/B/z/AaMKZW5kc3Ry ZWFtCmVuZG9iagoyNiAwIG9iago0MDcxCmVuZG9iagoyNCAwIG9iago8PCAvVHlwZSAvUGFn ZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMjcgMCBSIC9Db250ZW50cyAyNSAwIFIgL01l ZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjI3IDAgb2JqCjw8IC9Qcm9jU2V0IFsg L1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RU MSA4IDAgUgo+PiA+PgplbmRvYmoKMjkgMCBvYmoKPDwgL0xlbmd0aCAzMCAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBtVzZctw2Fn3vr0D5SapSGILgWvOkWPaMk9hR pM4kVbYfKIqSOGaTbZJtW38/B2huYDfQ6EVJqrSkfQGeu5270F/Jn+QrCSw79IP1F3z1osAK Hf6LoP2mSsnfpCA/v64pSWpii3/rBH/Uthx3/TP/xnMtij/oksAJrShibJYsyC9zfMqmtk/m CXGZ+HT7Zb4gP8/nlFAyfyBn74omrYq0OSfz/5E3c3E1WT61XctjbjSVr5P6k0Ycta2Q+VNp Rrf9SM6uqvihIefEd8nZ9Mts2y+3fnL8yz+Wy7JqVkVWN1lCbtNkVWXNMzk/TNr0Tu1JW4Rd rh5XdUMcm7rn5DOZ/7odfjeiluP7dAqYDn5cQqXNwVpoYLlBby1Hi7M9K6AnE+dHsOqIufvY MqzDt2T8e22+Los6u0+ruMnw3flMjbfjOFbEaEC6K5C1OykAmnEnMsHbDx3LB946cbO1TxqJ C2wrAt4KcbORi+vERVbg+ywivizuJ7ijx7yN4DGTgwfRiA6oZbueH05F944+UyAqwtIfr2/V NhxGVuSGgd+Lbq1EJ1Bz08hHGI2CAYR9jO6sXon4UWsOoB5MyjtQflIuFghOibBc0jzFDcnq HpvZNBs4oWc5oe312CgMZJwDxNVnW4O/g+jjhXRDXK/F7cmlNeR41TylBcJq3KT3JC7uSVok 1fMSP130j7CR0Fw/5KmL9Y9wnHr7iOd7kcWG/KiycTK1cY1mByOXZe+Ap829q0IHECkrsszj DAn6R2OR+VNK6i451Wn1LUtSGN1MFejdyLE8DyC2N9tpBzOzMOaCngTMbcWpQNwIFEYgyrLX IM52EJjy4SGtYF1NSUauUjySZZpWNXyFFGVD8IlVgk/dPcOFUrKqU1I+EEQZJAw1hAECjWfD ceWLqeOMIYbMt5jXx+7TYijLNsNw/gSY8N9dmsQcGg7RffoQr/KGY0SWZZ4lzyRdLPPyuRb/ +y4Fd+nt0QRD+WJHY+iAlcKZX8QOZdlmGPYuGX+Lszy+y1NyF9cwubIQgCXxMr7L8qzJ4Law PY6xMNELERg1CPqBxdwQVihf62gEKbPsl/JkWbYZgp315WUS54NtCePjoDXxF0BWpfBjpBE4 8LdUjRpD+GMiqW+7ygaxQdAfU6ZKcgFNquojhHSKltpoIuGQqmyk3XWEmKGUU0WIw1JVK3sv ljNEAUtEBASLuCDZYllBCwvkeK6NNWp1Ezermnxdlf8iWQOFld/AvMG5lZkq9NdU1h+emhew xxq4B54YvFCImMg2NfAGxfZg2Wq7oiAWoe9Q0p2zl7JAEtcxJ855cQ/m+E2ku7UqMuTGohxu 0QcutYY81IqBFwzXORGZ8ILQcoaaSGXmB5GJiWwzDX0HXVVrpS8UOtnHEVNqc4Zmh2Qibn3V bSFqTNpH1BElbcdzlmVdZzz3fDrjdJtTn7qpsqTJn8GBvq4yEKFP52pN99y7u9OpNO37sKCe Nm517T2qXw+Rkre6XiL7T2SbGY5ZvdqJPs5uBjNsUdgrOCRl+gOtrpp8z5onQT0Qy3ub36wn 0VSE5zPS3b2FfKeRisYIsjVIIy/+QLz7QzYqPoaeoBu6/vZDdlUAgi9c6MQDJy+icLRDACtK TUhgAbPcCM3RieitBt6WfZrmKAOfCHirYCJuJ9pd02QI64I2pbXVo76hWo86FqWB1x+209fb Ttf2VgGwXfehPReYDFFdB4Wm+ELZum5NTcSpksSEwRm1piaipZtOks6HHscN60XDnrk+z47y g/dK09JBnXX1ja5OskHg0FjXEDjai+4VOHoKyLn4In4mWfGU3YHhtcV029rhyUikUSXf66l5 91Q77U5bVrMotPwILqNAX+aRE7Uu4uK57RQkscbP3Y6jjk7hzLzXsXzKhJjzNKy2H49SC53S wX4MtKwT1/sho2hf9C15jeOMeQUx8xxZthkMolVDRsQFbcChIzhu38Ap1ObjgjRGnDa1d9iZ kcaVnUX+KvK0Rvky7k3qsocL+wo9zNnkR5aCxUTfRtpxkPPYC2lHlm2mnb41KyuCM0tuu9uD vuNSi/ImgtceuVMZwtZaqleglq/ruHpWO4fD56IYjCoP0AbXCzBgjVczBx3hMMD0VQZMp1tN fGXMs/ww3BBnhj+Pr5zKqLFgCEJ25CPUydc1k5+v23g8equPcD3Pcu3QOewI0dYaTSc2UqUb RZZHuTPJT6ADXHPbgXLYyAHDMPO0oU6WbQZ2jZGy5uJD6XeI8GpVwEdXfHLP2968k/hYxnlN 0JNF4zGrn0C4s4J8vHn7OnC88LOljqYuSnvf5p2G9ibHJeNeIxioWfR0BZ+LsZaPaKkPL3Jy xzw4mMyDL5MvRfk9T+8fRdMKczT1IJiiORE6rke6s0+UlkGNxQTlVOJ8NDpfKMu7smwj0wfq 78j3cpXfkzxDw1YYaFx8IbdNijbUb+gV8pnLaFXjtlyI9hS3Yz7r4qbb8InEfZmseG9RpyWe nWmE/DC567ERxfX4msrLpOeJbFNYgUg/UeDwpHGVZwgB93wlZoLpdhVcxdDA66pMvqQVBrBq 2+dLJ2FEgaoMw9GosojPHLoVpZPGaVeWbYTq2XXKg+jVKnkqvxXZBbnGzIv8B0QVhcEFuU3K piG/ZbxtK37xPq6aTMNNXQzeu3vsDKS8mlay3CGQOkE3CuBNcQ1kY5prxuJdWXYPmZZTzZ/K RV0CnQ9ZUpK/szzP4kXdQvd3uQJWfDhwzx1+iX4qeRtXVZrn5AEDbfh4Vqmfui+zJjdT2522 NBxApGBOQ/pQgSjnjzNDEGXZaxB39aye0nz5AFOrV4+PyNp8KUlg1m6TDF0b8nUmr+M5Ad8j CmFn8rlqiIb9pBlfPJTFDRDxNT/1QpFUIqrrgV4cL/LR8N2RsLu6aV0PIHWEk4R9k/LpPqZ9 +lSNKsSmISPdqSfKrSzE7t2QBEwg3rJAOWDio6c17Mj17qbrHQhM6ASVDyXCkZjqjPDR7bTB VHyGZVDW3kAfm4x32pgXiA6DTtweXX100URJ3Io7qZdOZBt5KbDnFJo5dvAZZH5EWfoMcW1d kFe37+fXWBwVKznkzY8mxa6hbsUQdA0rnRHZeqdtc59xZEd7jQdSsdmYEnE0H71qSrqOIXXH nco5GGYwgzWrtNW5eNv8Rkwd/aO+NQRjQRo9eyYfY+Q0Z/MqLmq+1kt+j5+R4Ls90FcXBAol XKMX5G16V63QfMAKLiZxmqQEB3aZS/ur6MxdPKZZUmIOO2WJxNBGHJVIKn0clOMmsvfxHhd5 d+I9l4jo92AMN3CeS+xApxnYBP/h97gSzOI9vn8f13X6fEGu8L1gE9CQhrCiPvQiHuFkFBQh 2zzC2TZmJH0aMwd1TyMfjjHvKt+UdYroc/XhtrdvgnX+qsSqG2cUArab9dCXl1H12vo1ho7p k8/Q/GHDdU6xiOGEmCFimXvvuL4fiKNjzEHk5smNrUqe1MHIQXzA5igl3RHHhVCHt1oiBJSJ OLPYhmjljfnhhNA5Liw2ipypcIUniMGhplPVkxcn8McF8dHifM9itF/wVznWZvZQa6lfxnVk 2Uawtrkesxh/Eq3eJ/+u0u/rQPTqsuAullYPMRbQeFi6zB9LvC/ytKhFWr4cTxV0AcsD3XYj FpDusvqkYhywHHCLg5ae9vS14RhzX3uzXv5GaGrzMEf7gvwaF10aDjVpmGEijCE+EBvOPkl0 cp1xbbjVsPcgsQ6zx3WUyrAPSsMT2fukYc9xp4Z9hebRF6ThuSUs+Y1FbtI6Kas8RlaZoxmn YlE6u+77cZO7boWVUHO7puuX2146hwzHmNv1p7P577efzsl1VTZlUubkv2iB8ASM6rGzdMCv TrwM21EOjWDaw/HctNWRa1wRcBLVvkqGxKKOj27HY+VTtM0eo8xgB6JKhmo4ZgpNGycaGklv kqkc6KDMMJGtxnfU7mgzg08db5IZbvnLGTpnoHirygNxIN25BkFeM1+kPAW7tjsVp3iMSYi5 LO4r8MXrtbf/aqHNiTEI/P/VTYo9rRoMcf2OEdKa3ohsPg7vHuk4KtTTCxqKF/727wzvl7cm xyiQm9gW3Dl76N7AwozzqlxA8y1GW3pqDphIYMMPutP0aheeIdSumLFjEAXOB8hbjFpxOy7f 5qxfYv4SwuVyiVc41vrtOhXvsEbf4FVXjbLRxAOfdPqTT6Vs0cM8YAywp7LlY3bg1TYo+Fok BlCC5eG9aHK9wkQ1wdzqGb97qGKs06K8WuHt7L9qvkr9j4U3hNShHYthYBdY7qHtZXbaglnz gPrS+5+qKDmJASP88K1a8X33ZXTMPvnw+rd3/yAhvk4xLhGeg6WDrD9uYxORc2BeiJHRcfr8 18ZnQR/Wu+54w1cMD+GfE97Sn7vR/B6U06J5Kvt2D3zTcKQf9a0H5cjHmNl31wrDhrhgLS1B 4emtrYP5K+lUR8RhydjfCAltzz+VSTPp1cKtPGIPIo5l1HHrZipuzKA0njAkKCq9cCaJm3qZ WneDOFu8fbUxH9GxMTCRq9UXManEjUftaMVP4yG74iMGUsRH3vxY4tWBuuuZ6kiPg61VJ3QD gld4xbBXn65k7PCIz4gCF9wGvT3vLALnblS2PPLH6/gxJX4/Ed+S090Q8TbC6+yTp5LsYMIb PnM72J7T8fo6lhjxzvke4kymxZjbo6uCN/e1f2kBGIc2y1A+MuB/GYmJuE2X/PP/MjYsRApl bmRzdHJlYW0KZW5kb2JqCjMwIDAgb2JqCjM1MzcKZW5kb2JqCjI4IDAgb2JqCjw8IC9UeXBl IC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAzMSAwIFIgL0NvbnRlbnRzIDI5IDAg UiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKMzEgMCBvYmoKPDwgL1Byb2NT ZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8 PCAvVFQxIDggMCBSCj4+ID4+CmVuZG9iagozMyAwIG9iago8PCAvTGVuZ3RoIDM0IDAgUiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAG1Wl1z27YSfdev2MnLtWdUlPggQPbp OrHTJNPkurUmfYjzwCtTNmubdEkqqf99FxQpkpCAwBbdPsjxyAeLxdndswv8Db/D36BIEEm1 +cDPMFYkYvoXqv2hTOFPyOHnNxWFZQVB83+1xD8NCBObf+sfQkEo/qEAxSISx5zPlvfweoHf CmggYbEEwZtvtx+Le/h5saBAYbGCo/d5nZZ5Wh/D4i84WzSmjfFpIEjIRWziu1B/csDRgERc mmhe1n6Bo9MyWdVwDFLAkfkx2/fLvd8c/vJ/Dw9FWa/zrKqzJVyky3WZ1Y9w/Dw006Z2pT1g J+vrdVUDC6g4hq+w+LDf/SKmhElJTYe53I9G2E6zZwtVRKgtWw6GC0Ki6GRwMkZWx1y0XP4J 6RHy8EdkBnDsXFESiFBGYGD7Mu/LH2/fSBlHX8dH/K5Yre6TfA7nBJL8Cj4QuFje3D1iWM3h 1eImhdNPF8cz+wFzxQhVjG7tgk38Wk5kpqPWEV9cRfpcd+As25yN08HrpEqv4GRd36Q5hkNS Z0XuIBOmBhFztTW9PS6L6U3CcZzQlpsyYkT23PQ/fSRA95/damQp5l6KRBgvY/EQjD1UrOBT co9OOkMH1VlaweXR6cmns0tcsEzySicT+C15TMs+l1weLX67uDw+ntmiUqiYSB6xrUluDqAj Zzr72eB6R6qAxLjfFs7mSIMEnQs3n/Zlekf2y8y8K895WdTFsrj7BdA5J6/mgPEFOsDmyL8u NTJid5pmesT0OfbL68JnZ5+n08KYcKyjrjOYbaqn1xkILOiKixbOwrLxEWChiwgj40zzPl8V 5T2G5LcU/khXaZnmy7Ry1Q7GYsI4w/hsbZgqPrkkPJwu2TNUGL1wsbHUCERkp52afbIfY1u8 b0B/eW9HjjhBb6LckmNkO+uc6TqKSSwiJU04P0NPSZbWK7uxlCmiQtRu0xhLucA6HO7A+Rl7 leSpw1SMOrbjhmd6lcqQhJJiERwfkp+h1X394DA0DoiSIebqMfZzTUXhH0i5A+dn6vesvrGb yhgjTAV8IlMZNhghijwTzs9UffxfHbZKhFGo4J/gVkcC6EsgxWqP6ffJSnJQBe1W9yVwvIyf S07XtzfFtzybw+eNePyTwLukvEpuG/F48XFxDlXXkHzLEnstFBwJr0Vfa4ardjWdn2cpDCgJ MdG/tH7ol/HXD8Wob9MSTAsJ1BFXukXURzbb289yDApKWQiyX9UtG3QCt0o3jkEhKDa0Bpyd AbNB++1O31hjiaQK67fD1LFycLYGmGJjGu3AbU2duXKYO33zKMQxBEMx1prqITVcXQx2vYLx HbitqQ6VB0fuBC6oJJIprGKTmCqQTzHbQfOz1J2/hYgIZhgM62ksxaQouNiB8zPVff59BzON qUinmMdYFcdwfqZSas/YIsYihgFrIruo71NnQlRy6jki9ml1xljGzx+XR9+L8hayHB7K4rpM q+ryeNhlCVeXhZpPUSGhW3mi0hJi98awx3fBPaHLCqVEpbvtsmw9hJEs/XoIA3vj85l7sIod nB4YiVjExsDo4iYr00dsdwnOh7rxaz8r+PWuqKqkxC98TssKxy/AXs1d8yOBO5eRCsEw00Lo Zn7kILTAcVQcRTtwFqYZDsUtu0KPkiimSKXxYY0sNQAdlm4lXog/6cH3jkpx1rNB3DlpsJV4 3TJtZbM4xGglNQEGoRYoMvDPbDxpZ0KSMEC53q3kio12ft/5Z6bvFMZwvX8Eb0a9vnD7dVMP xymJfywKO0d0QezVrqOGHWJbfDzmSBtq2Jeas9k3ZbFspPTpKNY+JtkdnJTLm6xOl/W6TNvh k0aYw4f13aMz3rCA0BhbVcPWEYu7zQP9Ubz1bmUBVuc9LB5LnfHej57O4n4Zf63NgiAeEtdg GpU4wIlkDGEL7iH+OuLuuXHqXRJEwzmwxcPeY2WBrTbFGvHkVnAQssbOt3MmA9tC3J4W2uiW uIqFJnHfJmWZ3t3N4WLTF74jsKiWN8UqzbNrLBvnafktqfQg8GORZ3VRZvk1vK/wAsLF3LAb 13fGuhOCN3MFijX58swdLOPP3JO6Tpa3GOCv35wDjTC+9ZhZu3wOH5PH5vrNpX6wUjEaKxgs 7m4W/RprvKEZDoX3MrtLnHb2bQNFSNYMZNsDtbDPSB36lqco/1PBydWV1oT2dSguFAvsQ7p1 JopvEeq74MnmyILHetTTXYDbNOA4CHUGte+8j+8xtsXDBvTn7BZjE7oxj32Z7bzS2MJeXhiV 35VABc5/9fzmRTLeGNvPI4vvBVxk1/eJwxfdzNow/mBfYNsfTEg2/SwCteGLuHaM7efas3uU Nb+Ae6JERYCJAtPZeAWXbx1TGmwLiQwjE83PXj1P+O9VOwElRXltpwTDOZjCewxzIZfZjqDe pk0cMOimsTvDg+EifKoxHcO4xIlCz7CDrQtVI60nyt0cz17L1angcMygb6qngmN8KPUO9h2l jcKZyrogwBH0ZJtlEY60+scyh26WKTllVWZ4F8fx5nAi3zW5oJ+zHbxZwaasCowHw6pwsHV0 9KTvYDgcP0yYoGg86ZsvGjVvvqZKAfimasrmkeL95IQJiorNI5OJooLyzSOTqeCYnDJBUTp6 4HEojWnQXOl2RPGSG9hrdzIclYH5ULRp2sxf7j4w3fm73a/seeh59s8DTnwreJv+v1wnpfPB Dl4isEgoeOYWH4HKue5pw5ff5Jfz5DoF5dqOUJj6Q8W229k3cDC6UscTAYH6CuXmk+B8ZCDe NWKBwuelex5eGtYN4H7/F7mqoWMKZW5kc3RyZWFtCmVuZG9iagozNCAwIG9iagoyMDk2CmVu ZG9iagozMiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMg MzUgMCBSIC9Db250ZW50cyAzMyAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5k b2JqCjM1IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8 IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA4IDAgUgo+PiA+PgplbmRvYmoKMyAwIG9i ago8PCAvVHlwZSAvUGFnZXMgL01lZGlhQm94IFswIDAgNjEyIDc5Ml0gL0NvdW50IDcgL0tp ZHMgWyAyIDAgUiAxMSAwIFIgMTUgMCBSCjE5IDAgUiAyNCAwIFIgMjggMCBSIDMyIDAgUiBd ID4+CmVuZG9iagozNiAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIgPj4K ZW5kb2JqCjIzIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFz ZUZvbnQgL1RCTFhLQitBcmlhbE1UIC9Gb250RGVzY3JpcHRvcgozNyAwIFIgL0VuY29kaW5n IC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDMyIC9XaWR0aHMg WyAyNzgKXSA+PgplbmRvYmoKMzcgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9G b250TmFtZSAvVEJMWEtCK0FyaWFsTVQgL0ZsYWdzIDMyIC9Gb250QkJveCBbLTY2NSAtMzI1 IDIwMDAgMTAwNl0KL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA5MDUgL0Rlc2NlbnQgLTIxMiAv Q2FwSGVpZ2h0IDcxNiAvU3RlbVYgOTUgL0xlYWRpbmcKMzMgL1hIZWlnaHQgNTE5IC9TdGVt SCA4NCAvQXZnV2lkdGggNDQxIC9NYXhXaWR0aCAyMDAwIC9Gb250RmlsZTIgMzggMCBSID4+ CmVuZG9iagozOCAwIG9iago8PCAvTGVuZ3RoIDM5IDAgUiAvTGVuZ3RoMSA2NzgwIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AYVZCXxU1dU/9943SzYyCZB1knnDkEEyiZEA DRCaTJYJ2IAQCDpDg0wIkYBgIgmLijBUERg2Sy0VXHCpilrlZYJ0AliiuFQU4VOqdQXRfmp/ RdDfT61b3ve/bwYE66/fu/mfc+45527nnXfffZOuxUtaKZlCJMjbsqi5g4wr+yOwnJalXWqs npJFZG68pmPeolh94ELUr5u38IZrYvUcK3hhW2vz3Fidvgf/RRsUsTobBT60bVHX8lg9+11w 68L2lrg9R6rNi5qXx8cnaVeva17UKg2YShOI2tHe2WVUKUf2d0nH4ta4P/MTJf2lYlb3sBTq frGrxnsf0QAiBi9OX9B4uocskGxUQlcSKX9S8siEurSbUpt+t++RMbNTx39pzZXLIHrgw2GF kj9/15yrvt39wzwbWZNRTTD8pQHtLBX9V1CNjb7d/e2NtthI0nLu4r3UKC7pcWc5jh0Qw+kk wMXwiCfP0SuGibxIucMbFa6e9MGlqVXFQkWPJQZVQduB3cBBQKHZIh9WG+gqIATsBg4CxwAz Eai0qkA7sBM4CZhFnrBHVIetapjIRttsrDdVZNIZQAcEOUBLgCnAbGALsBMwG35S0w6sAg4C ZwEzeUVmZOtIzD0zssFgPQsWlhrV5li1aZZR7bkqEOOTG2K89vKY27iY24hRMfWl1TE+rCjG 0wtKQ+i8JzGltK8qQ2RgkRmYeAco489RKmPkoPvEYNIALjBVQ+MV6T1D3aU7DwqFmOCC0Vxy 6H2CRVLSSqsSuc7PUDo5+Gf8dMzCT/cMSCvdWfUrfop2AwcBwU+hfMA/oFX8pIw5aCWwEzgI HAXOAGZ+EuUEyvv8fUrl71EJUAnMBnYCB4EzgIW/B2rj78qMMaiUKwHO3wW18XewrHdAU/nb kN7mb+t9/PVI2djSXkPwlMQFR0FcyMyNC+kZpVH+WuSb4cgoN+40Mmq/GEIVNFIMiRSMcERF VmT8fEeUf9ijehz3VV3Gj5MGcMzkOEY+TiowFQgCHYAZ0huQ3qAQcDtwH6AByDJQG6Dyw8Ar wBt0GeAFpgJWfiyCYaL8aMRd7ajK4K/yFykTET/C/2rwV/gLBn+ZP2/wl8DzYT/MX4jkO6gq CXZCGxu4DbwEdhN/pmdoukOvSuMHEUEHaAlQCUwBZgNbADM/yIdE5jrS0cl+Ooxn2MEj9KnB H6YHrORd4PC6a5CAqiTucb+EBLJT3enmXve27ahK4t68FZIk7ls3QpLEfeNqSJK4Fy6FJIl7 7gJIkrhnzoYkiXtKIySQKL/3z0OHOcqmXMvUqlS+DFFahigtQ5SWkcKXyULfKHKOd0UKCxGx HV7P8EJHaB8LHWChaSz0AAu1stBKFlrNQuNZ6GoW8rCQnYXyWcjLQvvZGIQixLx7LqqO9Wax 0GEWeoKFOlnIzUIFLDSUhVRW5o1yZ+RyPHVgPoP1VMmHjjt7flmB3SeVOxFRJ3LeiT3hIOhR QDdqXjipQ2LO2fmSD+kprIzVLx1X2l41kR9Cw0O4DYfoBKDgBh1CGh1CJ4fQXSpoJTAb6APO ADpghvcQrGOLQVNBS4BKYDawCjgDmI3pnMFUOLWDyinuNiZWAloJTJE1fghlCIqTO715NrvN Y5sotthZaj6bkq/n8zLKyMC+nJ5mTYuylL1fp/z76xRKqErgm/kWysONuD3Ot0S+yXNE2Z0R 935H1WD2B8pXkHVsLLlZAfgY6jTqo8lulfpRZOePg5dG7FeiWWrEXeTYxwbIVnsd39g/cnxq j3KIn9j3O95UowqLOP4GzeN7Hcft6x0vlUSt0BxwRxnYPtVw7bWPcTxx2HBdDcOOiGOlZHsd N9snOK61G4bWmOHqTtS8qY5p7pmOieiv1j7H4e1En3sdlfarHeNjXqNlm72OyzAFT0wsxGSH 241BXflGhzPKoqzNW2TZZvFbplh+YSm1FFmcFoclz5JrGWRNt9qsA6zJ1kSr1Wq2KlZuJeug qH7S65FvvUFm4+VnRkIzUgzZhh2GyW0GlDizcvoVaQNFPa+fXs3qtb4Wqp+jal9Nd0VZYsNM zeSqZlp6PdU3VmtjPPVRiz5NK/PUa5apv/Z3M7Y5AK3G10UZNfqjTJeqNblaeo2/lxhLW7Mp V/JL1mwKBCgrY2llVmV6RdrYutqfIUFDGaz1/Hhl/Sh6sjx52rb66X7tsbyAVioFPS9Qr/1u utrk72VfsLO+2l72uWQBf6+oYF/4pkm9qKgNBOqj7ErDj1T2OfyQMWDws+LFLP1ItebH/HbE /ArQHn5DJYNfQgIVGH4FCQmGn8KkX3fnUF9t91AQ+GSq1Gn4dGaqF/ocLoBPAQh8MkJ02PA5 nBGSPlqF0Y3dDpd8ELiwHLIbLnaWY7gYM+82XEriLuvPu6w3RhKx2Rg+kqCblJPnfFJOwueC QP53sbXa42E95YGWJl+ryxd0+VqBoLZhaVuWFpqjqt0tAWlQNeEOzmlpk7y5VQu4Wmu1Flet 2l1utPuJuUmay1213dTka/R3N3lbayPl3nKfq7k20DNh6qiyi8Zaf36sUVN/ZqypsrNRcqwJ RrufjFUmzRPkWGVyrDI51gTvBGMsMnJ8qr/bStWBGtw/yXt4UiLyNZjrDFRn2DoqjOQtd2at zN2H08ouSvIEtGRXtZYCyLwuriqukiY8U9I0AOrUuClrZbkzdx/bFTfZoE5zVZOna0nnEsry za+N/XXigqpribwVMeqRup+94OLTvM218mxdrxVOr9cqG2b6uy0WaIO1AejGndMlJfmiel9M eSmU46SjEOcdpW681CUkxB3/MxeMOUGN6PTioLG/h3nzWRd1BoSWX9/IsRU0zkQYmmb69+Es JV8SnQEssJN5WOe53uQ6DJliGsKyO8+ha0lciseiK84N104PeTrPheRcdx4ZLIMYseryYGsz 7aNsIMf0CGUrbsL3j/4x8Ink/fP1T6Rdcv5PbHTROIh20RNsPj1BB+lZdhatdlMv7SF5BKql u2kF3UFr8VqbCc16moZigv4Olq3vwZfJ/Xhh3k9H4HsVraR9lMGy9E9pFa0Rr6PVGkqhIVRF U6mdNrFJ+hJqohPKLVRGk+g66mAh3a9v1rfqf6SHqFf8Vf+BkiiHWlCO6J+Z/q6/S8Vo8Xva TifY1oSnyItRQvC8hxbTDjFLYfo8/VvMwEnLMAeFJtMR1sc96L2VPmZZbIWoQS8P6pr+HLzs NIvaaAftY6PZBO40NemT9SOUgTGWo9ftFKG9KFF6mt5myaaz+h/1s5RNRXQ51rOHXmV9ov+H 1f2ViJsJURpOY2Fpp7/Qi3SMudgzvN2UbCo1eU036sdpEI2gGZjtI2j5v+xrvhJllXhBqdOr 8ZG3hn4ro03P0wcsh5WwKexKPpy383vFYrJixBEoc2k+4n0nen8fabSXJ/Oj4kHlceU7c17/ SX0A7oib7qJ76BmWgpWqrJP9hr3BPuQ1fDa/i58SdyiPKq9ZmrHqq2kRbaLH6WuWzsawBvZr 1sZWsLXst2w7O8KOsU94FW/k1/Izok1cL55WqlGmK53KLabbTBvMn/T7+5/r/5/+r/VS/TZq QD6sxux/T/diZb10lN5COUGnmIklsQEoKnOyGewmlJVsE3uA7WKPsj0Y5Rg7xT7FK+lL9h3H m5abeS4OP/II5OKLccK8g9/Nj6Ic4//i34hMMUR4xGgxXgREO2a1VtyO8pT4QMlRjio64lxq 2mbaadpletz0rOmsOdnyG7zjX/n+wR8Kf3i/n/rX9W/rj/Tv0T+gwbiHeHvgE2w8Zt+MsgD3 exsybje9zpIRuxxWyCrYJERmNlvArmfLEclb2Q72kDH3J9kBROlNdgZzTuF2Y86X8tG8mk9B uZq38utxGNvK9/A3+LfCIpJEqhgsCsUEMUu0ii5xg9gmNPGKeE+cEl+J71F0JVFxKEMUt+JR JiizlSXKvcrHysemJtPLpn+YE82LzLeZo+bPcaqpsEy1NFhmWbZY9lqOW4PIzkP0FP0ZGXj+ YifFauETT9FmPlLJxifMq8jn2TRXTObIVL6LreM3sz18qGm5uZyXsyvorOJGrF/gO/lXvFxM ZvVsOi3gI2Idmgcpj0Earxyi08oBrO1V9LzcnMxW8jPmZIrgjDQWZ6TnxWWKR7xMb4sTzKLc T+8oiSyTneaPiKnIgqeVCpOfnOJuelJcz26mp7iPKPE760bk8RXsMewLjayU/VvoOAZfgSwq Ex/SLXQt/zudxnO8jv7A5irzaDONZCvoY3oYT8Vw03XmQvNg9hKfr4T5QLaHuPIoVjeWDWXC NIhuZbPEDvMZ/hYtoaNKIr0v/oTZH+VPisnKWdM01oYn4Ga6ja7XV9MNJr/yGptHgl1JBcpJ 7G4rRKniBF+FXaUJe9pePN37sA9UicnQZCFzJiEvZmCH2IFyJ/YJBRk0H8/4VdjFXqU95kYe pXmmAQy7Dn6pebl/Gs3UH6bt+jy6Tt9KxdgP1uor0OMu+gdtoV1sTf9N1IFPybfwbE8y1fGj pjq9mIf5W3w633bx/UW0C1gW/RPlSdyZCtN+Citv0nSq1Dfqf0N2X4IddjvNwYH1I6zyM4ww UfTRyP4reLdeJzqw3hPUoD+iO1gitekLaQodoIcsJmq2eHCPNfYa1nsTtfJpepdo7Z+POGxB FLyI1hLsP+u9NTMaq7yVFb8cXz5u7Jiy0aNGlo64rOTS4iJP4fBLhrkLhrqGOFVHfp49Nyc7 KzNj8KCB6Wm21AEpyUmJCVaL2aQIzqjI56oLqpo7qClu18SJxbLuaoai+QJFUFOhqrvYR1Nl u2aYLvL0wvOan3h6Y57e857Mpo6n8cVFqs+lakdqXWqUzWzwQ95U6wqo2mlDnmzItxtyCmSn Ew1UX1ZbraqxoOrT6pa2hX3B2uIi1p2UWOOqaU0sLqLuxCSISZC0TFdHN8usYIbAM33jujlZ U7BELcdV69OyXWiKbkSBr3muNrXB76vNdToDxUUaq2lxzdFInpQ8hgvVGMNo5hrNYgyjzscZ R6MNandRX3hj1EZzgp7kua65zU1+TTSjD5+W5sG4tVrmjR9l/VhF5ziTrb3QmivCvqz5qnQO h9eq2n0N/gva5jplD4EA+kBbXlAXDNdh6I24U/XyLK7xNQG/xtZgSBwsC4xVxdYXO/UWBBeo WoKr2tUWXhDErckJazTtBmckJ8fbq5+kHJ8abvS7nFplrivQXGvvHkThaTf0ZHvV7IstxUXd trRYYLsHpMaF5JQLhVYEPWYzJMNdSvXTzkeWyTm6LsdJUFNbVMzE78KaxkjSOobCLWNwA3AF GFppc3FH5msJNcGwbZzUY4lMMxXYXGr4S0IGuE7/62JNc1xjLrB9SdIo8+R8qmms+ZyseTxa YaFMEUsN7inmWGHURxcXLY1yl6vDhu9n+dFAUxHb5sC4EoTf6ZQ3eEPUS3NQ0UIN/lhdpTm5 EfKW4GzNg9LSd84yeIa0hM5ZzjcPupDJe+T3LA3WrO7zf6m2jIG+tnEay/gv5taYvX66qx5H Y9UXDsaztr7xolrMLgOKuMEWl7SBNX6Ry6GTEs8VhjV2Qj7nguOyP1lTCvBnNpJ6btRiRVYa GqbWabbgxBgNJDqd8Wfm/2sU1c/KVgb7sVl8Gdo4T3yisWlr5RfVL5pecljUN2LL4TjZh8OJ F9mQarFZXh5nyHh86DvVGo1m4MkswB8+OcZIBHI1L0IGSyOeIkMdyI1XL3LMjTcK4JLZWVxU hz0zHK5zqXXhYLg5qofmuFSbK9zLn+XPhjt82O1iiRPV923I1eo2BhCxNjYOjwen6m4XW9fQ 7WXrps/09+InDnVdoz/CGa8JVge6h8Lm71WJvIaWS61UShdVVqieYZERbjX8c3u9RCHDqhgK o96CXzcMXcwJOkYtUR7T2c75ceiUmM5r6OT65B5T0+iP3xYjIeSjhxzCP1TQjTxj4GIo8kqG Uv4vQz2vQUqjyF9qQEwoON1biJxpzrQCEPyqQ9+rou97r4m+I1Xpg5fx4w6YPgxnv5+7OJTC MDBKj49slv+Qaaye5K+v9lQtnt+8cHLj/wEk4/ZRCmVuZHN0cmVhbQplbmRvYmoKMzkgMCBv YmoKNDU0MAplbmRvYmoKOCAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5 cGUgL0Jhc2VGb250IC9FQkpLVU4rQ291cmllciAvRm9udERlc2NyaXB0b3IKNDAgMCBSIC9F bmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZyAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAyMDEg L1dpZHRocyBbIDYwMAo2MDAgNjAwIDAgMCAwIDAgNjAwIDYwMCA2MDAgMCAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgMCAwIDYwMCAwIDYwMCAwCjAgMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDYwMCBdID4+CmVuZG9iago0MCAwIG9iago8PCAvVHlwZSAvRm9u dERlc2NyaXB0b3IgL0ZvbnROYW1lIC9FQkpLVU4rQ291cmllciAvRmxhZ3MgMzIgL0ZvbnRC Qm94IFstNjU1IC00MDkgNzY0IDEwODldCi9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgNzU0IC9E ZXNjZW50IC0yNDYgL0NhcEhlaWdodCA1OTUgL1N0ZW1WIDc2IC9YSGVpZ2h0CjQ2MiAvU3Rl bUggNjcgL01heFdpZHRoIDgyMyAvRm9udEZpbGUyIDQxIDAgUiA+PgplbmRvYmoKNDEgMCBv YmoKPDwgL0xlbmd0aCA0MiAwIFIgL0xlbmd0aDEgMjY4NDggL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4Kc3RyZWFtCngB1bx5YFXF3Tc+c865a27uvubu+5rcJRtZgBsIa2QRI6tBdlREQUBF asEqVaS4VEQFF6qIQl1QFhvca9D6VKq+opZWW7SpSxvz8FiqFsPN7zNzbzCkfd6/fy/hO2e2 c+7Md777zDmrr1qzmJSTDUQkU2fPX7GE8H8L9hEizyxcPn9FsaxvJ4RevvDq1b5iuew7QoQ7 lqxYurxY1t6C65all68t3W+cR8iUFZcsnr+o2E76cK27BBXFMq3BNXTJ8tXXFss6O57ffPmV C0vthldQv3P5/GtLv08+Qtl3xfzli4v9F9zByiuuXLW6WJ7/Dq6vrLhqcak/nUmI+gFCUTuF 3klU5DoiIwLRkzwxEKL4Qv0LzJfydvT50v1V4WJd8z+pQckf98iGf51kmTefsX50+rW+5+Ue 5XMoynl/1oB75MoCOsu3nX7t9K/lnrMtrJX9m9LSL2ygLcRERJonGqQjSAHpcJ42khHIN5Dn kQ7jNfU8X0c6UFNLtiGt4fXVvD5HFqEmw2sqeZqiIVxlNMFLcbIM7TFSizTK8xH+m2HeynqK NMif6qNeEsB9Pl7H8iL18L5u6iIXoMXN+7G8SJ3kPKQVPO/gd9ipDVcZT0VqJa/ykpm3mfjv G8k43GOgenIa/Qy8heVFquN5DU/LeKqmKuJGL5aKVEn+QdQoKbFOIlWQ/4MnyXBtRUnO+8t4 KpX6Sbwk8lTgGKWkCn0JmwHpR70Wq86urM8ZUAG7X4sSy4ugSfQm3/P20+Rf5Hq0n+YllhfJ d8SI9FvyDdmKlm95y7fkFSKh5p9kPupYi4h0A+r+SU7heTLeIpJ/tvSD1iTU8TnxNpHnRXKS WHDXf/Pn9ZKvSBnu6uUllhdJD/mM2FDXw+v+Tv7Ge/ydl1heJF8SD9IvyG6kn5MGpJ+RvxIl 7mF3ijwvkm7yNMMnrgwDf+Hpp4zCyCc8fwLtIvkzz/+Jp3/k6R+IGfXHye85Ro7zOpYXyYe8 5QNe8z45QFrw9Pd56RhP3yuuGXmPrwBbP5G8y1ve4enbpAI1v+NPOcrzb/H635L/YmtNfstL LC+SN8lv0E+GKxs9y4vkDfI6r2OpSI4wSiddjEPIa+TXvOU1EmalfrZKvy7Nn7WInFJF8hJ5 kfwMT32JP/UlvpovkhfILNSxFhEpW80X8NQI6liLiJStJasRyeHSvA+THEqdHC+/4k97jqeH +LwOYv2L+DnIaw/2v4MnsBqR7CfP8jHs5y37+RieJc/wMbAWEe1sDM+QfXwMrEVEiY1hX2lO rEXkeZGOITFQfStLyVN8TZ/kT36Cp7/k6V5Qh0ge5/nHeLqbp7vII4xPeSqShxmfkl+QNqQ7 yUNMHuDK8MvyInmQ3/MAuZ9TBktFsp3ch1oZT0VyL+9xN2/ZConZiJat/Hl3MSlDfs7b7yR3 cJpmqUhuZ7xLbiNbSBy9b+NcyfIicMHWfjNPb+XpJnILesvIJv4LLC+Sm3nLTzllb+Q0cRO5 EXUynorkJ7z9BoxFBF4h8ch68mMyFu3ryV6UWF4ka/n91/LnXsPvuJqs4eO/mpdYXiQref4K ni4nlxMdnrKcVKOF5UX8OhvxZaSA9RfJpeQSyDIZrozTWF4kS0k90iVkNufNJUy6kcX8VxeR dt57EV+FhWQBMCYjC/kTWV6EzJkHXS3DtRIllhfJXIyb8QlLRTKn9Nw5/C72GyKoh41pZunp MzlmZxAvl4czeNt0/vsXlnpcyOvYWESsOrt3Gqnj6zWNl87nT5jK85M5tU/i95/H0zYyDHdM 5K0TmN4i43l+HJcJY7nMGsNrRnMpNqr07FHkWvRt4c/OY12Z5Mrz+0eWSiP5E1iLSIbztJk/ p4mnjTxt4Okw4NiO+4dxTNaXfoHViTwvkhr+rGreO8fTLE8z/I40SaFnFa/h+hZlhockTxO8 T5woUBMr0XiMzz3KeSXCerVsgyRieiiEX2XrE+K0GuRPCPDUz1OuiflqiMCHxPt6OFW4gUWR uEp1Lt7bCXzH8DQnL7G8SBylX3DwOvZrIrQAG6+Vp1w7wxIxcg3BUhFWkB6YlvFUBOVqoell uDL+Z3kRtFXk3nL+DA3Wn3EUS0XgXoVny3gq4nmsTlHqr+A4YPeK6FGcj4xLAJYX8cd6U043 hGtYSu0bt9Dk/8P/yP9bY3dzExWy+jCkxW/IUeR2E7XgFMaTdaDjAyjfT54gRwQ13UbepyPp r8hddBN9lS6im3jvo3iAWUyDejT0VUkp9OCOp1C3CbL4KP2LdJz8EbS7hfxR3E7WiiPRspY8 RWeLo2DnrZTMvLwLfd4nRGoQm8g2qqYv0OP0j3Qz2U3foPh1cSb5Gs/bJN4vHsIoN0kO8rVY LQr4pW34jcf5M/Bc1N8rCvRh+jHtJYeIjS6hT1ENeVy4F795DT0NGb6NbKKV5E5yJx0JmblA 2om6GyAP2d9J/Mq9ZAv9Lea9BfCqeB76P4XZHqVOjOMoOUBXkkWikt4Ae7FAT4ta0caeBV14 M/7uIvcKN9Kx9E7BDUuKYWALUiJ9Iz1c/EPBC7z14je3EL/Uy/5kWrJGcGIk6IPaLXKzfDp9 Q6ikv6JvANOLBJuwhS6HTUOIgy5id4lq9LtTmCyuJ1vEdwUHLJItmMMNdJ30sLBLWIKSBjO5 nd4rzMZd24QmyOx1crOkBv74H2q3sJkK42VHZcNlbsx5m3g/vV28n7xE5cSB6zryoLhNvhE4 u4buBfauZ/gnK4G1RdJOjPRK/K0ErMOzZkLHnYRGu1JUQgMdZaPFqG3AlJphCs9YCUz5yTrZ Sthaq4R3ySqe3gVsrYXe/TNGg3/r+zGme6GhM3mFXCZhIUnKp98nhCcs2pc/f6bvN7P8lakh RZ9e4dtHpu4rX+v7VX//1JmSUzZrn8y1Twwr90nh4Cf/W+Mnlam2qTN9v6Kjx7SWHjtmXisq L5iJX8B/Vo2fG9NaiZFJR8kSAK70CcBM6aigxPV+wHbAcrSx68O4fg44iryEKysfAjwLwH2s nrxdgjeL/fm9ragbBTgN+Fg62l/AtR0wGbAAwNouArB+rPwSgP3meEADQAPwAyYCMDbSBLgd wO4ZDtACBMB0/CYbM4DcDGDPmwdg97D5vQDYCFgE2A34EnAJ4HBpTCw/G8DGw8bGxsDmxu5n Y4mjXw+u0wBsXG8AhgN9Rd+agCrldC7KPlhaFB64iHzxnwTtIOdZBTSICjqlDL3LoX10kCsG aAYT9IUFesaGXnZouQpoPRckiAfa0kf8sOSC0KphWMJR6ME4SaBfEpq6Epo7TTIky5+eQ1rN cwRavxb6vx52QQP0UxNpxlhHkJGwM1rIKDIaWncMbMFxsFgmQH61QQ9OKt35/8/LZD6sADBx CbyIr2kN3UBfoT2CRhghPCx8I/5UskuHZTnZg3JJvlUhVzQrtin+phyhfEI1SnVMPVP9p7KJ ZSc0V5Rry3eVf62dq/PoNugT+kMGyXCF0WM8YZpn+tQ813za8o7VaJ1u/dS21W62v+6Y5+ip 2Odc4PyDq90dcf/Ys9ob817ty/j+5r8kcEVQCG4PRUJfREhkd3RB9FdY8yWFbdIS2S6svYLY 8ioJJKGUCRJJv/XRW1miP/bWsbcyJoPfEPYb/Esk0rdKdPb9tbBNof3u66vkcTZFgT7R/6Xo l/4K2nCSqrxDp1JQSSOZDjkOava7FFRpBcnpidKlP9bd121saMBze071vWWwNWSoqKXBQCQq 1tbUVeesFlq8mOWoFP4YpFXBQJUQGFFXP6Lw7tIL2pcubb9gqTT3zDX+ZNIvbFI3jh7d2Ocf O3Pm2HGzmGwV6ExxubhGNhs0GiQj8lGfx2bRamSi0kieq1DuDwV9zgqLUe6xGrQqpUjkGkGy Cp6Q/ljPRz22BoPRxgbX19ydY2MrjauJ5qxuPlD/v9WIGodV8tqs8602r2R1FG522ESv1TbP ZvWgKC53ROhKjcNud2gKt0cc55YwXiooxeXCET7eUJ6PVCLPKfcbfxieEWMrjqr7P45JmM1G YLddbLOzEZR+0u5w2PlP4jfo/YUrxax0BNzpzxtEle4N536PhpjukFO5weLB8zu6c2za3Q2Y tFmukAsWs9XmoRa+DNGIUFtjrB9BsT5idrShtSGTdcww6b3n5ZZdNmNW44KI3iTda9kcf6jw 3W03/vO6UfstVkfL+Pvo1M49tPqOi+c52Bi2nx1DdT6gEp1v6PZ7HCqH6DA5bHFVXIyb4jbl Q3xEJg3BoJpP9XRkOwZGVVNXX2esrYlEq2iRUmxWo8UsKDj10O2txtGN2VzFdLPe34ZRzZo1 oiOiNxceNG+K76SqLRu+/dGo/Vazo2XcvYWnOvcU3rpjwUUVjHYpXV54Sayk50GGVeYr7EZD maRVE4dWPOpgBbUEC1rhsDjOLsJboF9OuCMoowugSEH5INIUQ2um9fSkssL7R51RkgpfKexa UaEcq9cL1BYwaVQyveJMl84oiBUKo6ZMJYPU3Q6NUy2kwTv+POokUVK8S97R65QKIpWJev2x Lr74p9jimwKR4YxB/IwesTZHzDabWRxuq/CY6HKH9TKT1Wq6zMgMSEof7v9aTNLpkNvmvEo8 pnpPI3cSDaaBhT7VkwkP4jP68PIZsy5fPnPm5bsmL1owdeqCBRjX5/23S5LsXsh5T14vlpuX kCUmwaRWEUkvNxdHhcU51pWR8dljUeopJxGOkY3WqNOVkMuEFY6I05OQyZy5UNyttGhkLTXh mEtpVoFXydH+P0PRaDFGG7k8P0feqSGdxpc079ubypoUNbRG1lbWpmilrbI5hjnl7aZlhmXl i0w7ynYottKtsj1lexS76W5ZZ1mn4hA9JHudvi770PBh+e9Nv7d9bvi8/AvTF7aQSmERFTqX HVPGzDHg7r4efS84GxRurM6BogQxIBj0LG/QC8KSVRs2rFq9YcPqFz7++IUX/vQnaX3h5Hf/ Kvw3NfzrO6r/fh5dSGshyBcW7i8cxd+OIg1JhIinZUpovZZ8yK8HkmRi+UteQ5dd7bMbLXri UHkln9yid/vkOhd1BfTHOrqO9XUxcWMAPRkhdNI9uT4sdaZITAyd4SI6DUwsYrEhe1DbhODt NeXlMm804KPxMkuZybpzViYWO7M3FsvM2i1lBSHotodUU0Ux6Pn+dXcshH8xt/guaAIRJCL+ BfiuJhvzC0Ny2JnlnevN1OyOh7vcLxGPY53mOtk65U8Dm6SHlDtk26Xtzm3eBxy7dLuMe+V7 FXuVe2V7pScdj4Y7lQfDzyuelz/vfEF6QeZKp6ozEQjTkEwZCCt8olqR8oVtYg3I45VjXT1s mphoA/Cf7unr0r/e0ctm3ZDhUxpJ6+oJODsYgOBRMLnPJl8iJSrXUf8AWVkYt1N1bfUrbnc9 nX3d/JGrgvLycFXIozXlX1y4+8+FJ2ZUraNvSlG/PwLB6rEnK1v2u1w1dOzdyzbWpJSm0akR Ib9pxIQP7u8qPH9+1dXJylRE1ImTvEHGM+RQ/5/F74CfLLknv5q4LcHOTIRGUu5Oi65TI38/ 9ZIlJ1WaK6eFpmnn6BeGFmov1a8IrdCuM6/zrNNvhQuzNbs19POqrbI7tY9W7cruoju1j5bv DO3T7icHss/SA1X7Qi8r/Rbi8CnSRsUKkYrz4iviQlzv8DkEh8qT05/q6ujqONYBYjVATYJe u3pOdYFiSzjL0AGhDByBLqpzdUwm4q+2pp4hrYjHIg6LdCMKa2747si9XyW9hvcvuubupbOd qfZpPsvkeVfPaX/G6gqfuOX+txcK+3x7rnv6z2vGeqJLbrl81jqDTJS1NKlFSXPJxIuvvSTk HL72xVsvxTaSgOgnEXtlGuSGkfvyC2+lh6lAfW5XhcWsCNtTOn1SKgv7SVe6LKvqsr8kxizD LNOFJcLVwk+FrcJu4aCgSsaG5dIBKeUTzBpRJ3e7fCrRIsLcrKW1qZjcqyZuXYzGvBnfeh3V NYBZjjV3d0Ap61/PdTBiYiKYs84AVfX25o41F5pfL1VmOqhBBe3N+aUWVAapCfRw+WSzehkS wVXc3jCDwLQ0SS0lLhMOFzZSXSYQjK4uVDpcbplId2uNOrlOkpZoDdVWu87sEkSlwuluD+bB d/SosPvM7EK1Nx7yP+7zjImlYD295dAKlOoFp/WMMuixqnTKeKjicW8kFOLygjwBuSdIvbCJ r8lP8cYDxCOOdE5xXuwUnfZOHcjiQ2PnVExdFe8KfKB6P7nMdrlpmXKd7UemrY47DLscOw2q gCceJBZFRAeNSdxXatZrBM08D/UkmWgB/XSA7bhgKck88Nw3HYWuDo46SJkST0lnSaVISmBC VmMoKhkudujGUSuqn/6yUHjz8b8kXGXvz/npYw9eO/tJo8cRr6anM5lcVaFJ1Npt/zjw8ndz Wirik36x/kePzk410q/97mg0HC/KebGPy/kQmZ8f43MGNBbVcR1m+KHYaQl0Ol+yvB+WguZg u7VdWKZcJi0SFlnXKddJq4XV1psqbjLfpN8d1MsVnoCR+DQKo9/uCutPwZbUd/eeFerfdPQa mTSFBVPiC0wmOiA7gkzKEyhOkCkzcOjtP1kyb936RfPXW+tumvzgxx88duQrOpd654+4enL6 wSN047odP7/6unt/fu/Ysb1PHfobbaAy2k4fcEXzAlV5Cv1cXrzd3yv2YB0DmFXeY/NapYqA BkFzvaar4gPxcPDSso1ks2a7ZnvZI2SPZj95XtNZprZZK0RTecCpKZPB5vYoyz3KeSZqCrKF 6yqpBKj84rp1YRENDSDrTBhUKhRlI/UPqNyRbB1L1oBCWKPUmgzjzDZRpJsKkhgKBvyUqqEH hLvdTnWZ2a7Va5U6tZRMVwZCarU02+VxYCmifrA0eRuyr1DSxWlyZ35VyK57WkVVfxA7E5ZO z0uJ9zNqt8xb4bZ4r1NeJ61RrxFust6k/Yn6J8Jm82b9ZuVmaYd7R3Krd2t8h31raEd6h2Nr cGt4V3BX+JfpXzr2uHb7DvkOBQ+FO12djs6qSMiuMSr8QbkiqlE4g1GiqHRloKW7TkHaneot ST+urU91/I7bpT+sqmnQCpsGDEJmdwySjnTVxiuu3HjL5ctuUd+4ZOmNNy5d+hP//AV/enLv p/MWL778LwcPfno5nXnZTRsuu+SG9bR34Y/XL5p3/fWFtZm7Fux44zd3LNuaiT+07NF3/s9j Sx5iPCuQN0u6wQ6vdnn+fKISzTpr4Dj2dsQPXZ0qa6fufdVL4TJlmVRmc9ra/XOcc9SL3Iv8 y5zL1Kvdq/3rnOvUDEm3ancod2j32PaqrQ4fUWj8XoUxIOf0DJ+om617D8MByBnEzOl5YLW5 jUK40oQ0qzOauNKEqQ7eFSfW/QRk/P7urpOFXxT+0DH8milVDx6R3bhk/rU/Xjh/g3DRmNav njz098KRQl9hT2GpK5IXBZUbgYCPfsQI/b67mO/EbUZEsZg95svrVcdE3THLe+I/7Ea5U0Ps sMl7mJ/Ax5cZ7KkxeVG0UgKRH6zJAatSOFoyKwvRAftSgN39qhjFbzF8tuTDA5Z3WPu2GDjm +od4FFWWogEud1hCCq/TEdYf6zvWw2R80YWEKfcZk2eMO/6jNQ47wjR4ZF+q7O63yw2wzAtK k1apEkdBBolJjPOKK2bNvPyU36hRiTDRP9drEfaWG8skdZl4aPKihVOmLGQ2cSvZIk2X5sKP yudTSrPdLLjNpjI1heusoLaPFR95kmQqESboLjOdbamQwjrmYuVsDdydgVeD8XaozmryKB1Q 3wNCGR5FVPg4FQl6tQFv318l+UWzlZLodEa03mAkJawtPGWJV3hCah1dRcVELheTgM7ysoDb GWfRW4poyRap/ew41Xa14LaUxmmjio9tH3lC5GIijNUtLjvbogtXSMzrgq957jgH+MtGrbai 9KRnrTRx5ZlwVSTo0YVdolNSzp6pljDeGrsnGKkS1tLJGKc7UFZeuEuQYrlsXBIKWwRbyFMR t3CeOg0f5a+IG5TB4mrLx7NJXUIjq3L7Qz63tUo8pLKecIf2qw7mUG2KRRNR5sJEI76c/qPu j2Ai6RmHgB67+2AiFY6iwBiGUcOgRQcBMGY5x8DkTlTRd2MqDlKVXrn4gvYlSy+YtuSKcKWz 9shPLht7dbkoKkf6o7/f8di7e3+TgEWwaVT7BaNHt19IX6wbYdM65lx30aqwVW6bnYktqD/v 19vX7Zk41R+PBIry4uP+beJR2UzMbARZkx9fnXOLzcRVl440xylxfCLVfZouVwebP0nH1Z+Y 4iMllVRhVpllSXuTvTHRZp+YmGOfnSiL6IkvR5J6V0MipUhY4yP1p/ow9a6eHDRF0UD8qEf/ em+Xvkvf+35RAaKh6KHyORedm7PsWSxaLYYBURn9QbpYTYYqBGPkJYniv6j9x1se+UXltQZT xS2Lj//t910P/Nyqy/kMQXt8YmThjQe2y21ypV530bIJoww5cZd989bC7wp/K7xWeDXitmZH I9y1lHbQH/+1r3CJy1Pur7ZUmPQ71t79pFBooedRenlH2zQNo4P+AiK5H0oPQ8pmyNZ8rk2Y IwgxsVNNOr1/UXen/W5R1xWzZsQyrQ4RE4/X59ekKir10JpV4UpFKpVFYKn7VEc31h6OFEg4 VxRRCB63OCDXWvFc7Grh6gV4ADr8aXkLYp4o+wB+AOuXUcj0PT09+h4Fuyh7ZpEO6ocvzZUv 07Y2FgkZ7JJF/YohNfReet+Ht/98eDY5j7rro3p6s6EuFqkpnDwvmW7pmF+Qps8flUlOKPwr n0g0mwQiGP3RuNcd7Ut7cPXGI97eXm+E5aIeRk8idn+JtAo4UiKylSNX56fEVZ8rPnPqOwPd DtJllOJS2Bw3h0PhWfFLZZfGLxXXimtla+M/Td4qal0Bh0nyVuRSxnhEr6aKoFFOyssjXmtE Kk9ZVURXka7W94GmjvVwQoJE5aqHMRMUUro3V2D/wVhFKzFJawcyJq6OmFtasiS5iVXSxNxf u/NPL2y/q/OLd2/b9KPV371ZyAeDqQv8/kmpUIC+d+xPraMvv3T2tOy1V2y5+Ior566bPXfW xd/3co91ozceDD/6wJSrI9GfXT5nW8aFMBJk2+T+v0jTpFexUtfmZypTykphjmGZYZ1hs2Gb c4fhkcxu5/7M85bDoe8qv0uVr3YdcAnEpNKIjiPemOZLU5f4RdX+2MEsE2URW8Sy2r7avDm+ q/JApUpvlZNsQGUtT2ayLFzQ1VN0WSFemKX5OhM2xoaOTMfKATltrWXCA94X45piQOGs4yrn kSkCmxOUIT6sDgXCHskXH2VWSKY75j/zwfFnG69tdM41e5PpfPveud8WXqJjvx21SbrBaQ0N W7CnLO2f69K1XVw484c/FM74/drRcY+nPlZfA4bS03K6yMdskgX9fdIa0IQGcfVZ+UaVTdPp EbsSFtLl6S53Kp1SUpmUmpRN0i8De6LPK5+X1DqP3SJZjX4iLw9VO401vnKis+Yq2eLnunOn eooClK15T08OErbQfCQT9oDeBwSoocQHZxe8ScwRA0wvLkboNb6Rnm/++tmZdNbyYGU4nGw2 6psrw9Hkgx//i8YuPL/twz3mi7eI4kdf9R4XRLbQUY+40RcLBwsvF/57Y/f0yeMkrr+w84h5 DSc/y0+NVaWT/pDXoldVN9Q1Kkio1/t5spek6ck0Tfe4VZ2Ov+u7s4quur+R4UaXRa9G8Fkp Vfmy0ZwrayFRejJKoxmPrsFSWy4p0yP0fV2Yal9zV8dKfW8O/4uuJDMp0vAjCww6VnYXurHe zPrGqhtY2pCpLpL4D1OnJdMb9cMp4uNFp5yH5v695nA6FE5OyufbKsORSrExEGScfqaHyt2h oNMVCjkLpwUz4/yQf4D+w8F4tKcmlpp0e+Hp2rpE5cTDbYnMmGBhzMOTUvGGvlAEuLoIcuEi 4GoYYjpttem6XCySdNkNyd7I57leUkdP1tG6npCh0/d3e7eWdCkUJBp2BF12o1Yp6cuoRGqj 2apg1iWRKnqyilbVh3UuS5m+Qf9RV66LYwmahWOJ61aGFOCC4epcVA0gCSJisGwUBssF0Mn/ iiphbjQRCQUKpkAomvaPHHleMhQQ1wSCwUDCc+YTqnTBKHAGQq7Cd1v8oWA4HAz7RC4i4tFC ATKF4ahiQi6SKOQiuQnuwhjgprX/E+ku6TXsJm3LXzIxMyczx7rMuixzfWad9fbMQ5mH0o/4 nrcerjlQt9+n8+di0WTIaDcQwzAd7RyppMr/HtZlT36Z6wp94dlvP9hkrbHWRWoidaurV9fv cit0Kr1GKVT60zJZNCuLE51GX1vuzDRx2dHXze1UhinuyDEJ0lvoALFximIohKfaEa49R2om qYF5MWAlX0ly2Lj/WqSocwWNuOs7j7siTPdVOPyJco2x4Q8rCqcKh+jo062bJqqDrrQ3kKix KWXhW2ft/6Cnq2HtE70+f8Tl94ddhb/bnRZ1IEOnU6hQusTrrbANW3xLNpo3qadML5z56C+F U9A6FGeciHQZaGssWZsfH+gc81l1yCcaOpP27tG1Ohzua1ZUVzbXSTWZ0cOTYSkW1KnsRkmv 8VWABSWSjw1rDeoaMjU1bmmYn+hqLJoafW4cthlyb7EdFn13roDL2UgOlA1XONDgvTY0saSX qRxGTyXf9wfeE4rVFFtTJbY8W1O6o6iwcYefXjO6KZMY98fBEundqcm6tkr659aGbOXMNypD 4USdXd+cSpz39vmpmgnZgn+LLxz3/iCgvPGYr7CLXhSAVkatv2/dgH6mOxmuXgKutMBVgNTn vT59p41xm1yrtBkkXZmvQk4kt9jg15nLGnRB2K85YOHsfBH67cllwiXGKU1nQKM2Uf/AhAzi tknJ5KQzv0iHIqlJn37aVhWJVAoXQ7BUtn26xR1jI0OsF2wRDoZCcW8fOwyAsS2HzrwLY0uT 8/PVZab2RHvVosSiqtWJ1VWKdCTsMjrlKW/qcwSqOxXdloMZvdpQjiUkunKDP5x1ZuC+nOrq 6+KkC9ZnQXQIzteZ4wXTiNtFg0fJuRxKsWRmYyMJBMz2k5gaEQqFr9tSwWilUJkOBVMTb/j1 7+fubQ9a3SF7QClJcrn1Jxfd+iPJODCHMzf89bfJSlM4+/exQZNR7Qqp/fXOKXN2PI15jQfO 2bzGk+fyY8vGJcfFq8O1yVyrvzXQ7m8PqGLV/nHjJWLIBbwg24S9uw5rMlwRyFXXjWgZp6gi LmnY+JFQD1WN/vE6SL30BKYdoPmOdXXov2lm5MioMVekRlYsmpQtMBXryDikbDu6ml0BbNMb wHKAHFrG81rUKfRSn6JH1qNXaHv65NoevaxnViZLOv5v0hJEj2D/ILuTsQGF32gaoAfsRkbY tlNUQbczCm8q7IWbkvbl8+clggE6vSnBSPwXGms2Bb88Ggilm7WF62c8/EvjCLTP87l1qiXR kT8edwVoPeb7QaT6YqD1S+k9eL4/HIz6C7caXyi87IkGw1qH9sUJa9aoL+F01QD8Xwn8x8jU fEJZJicmMWzpdHWLUVNXWdgbCbispnLJrEdLIEKy8kaHPqIzx/Uf9XTB1tAzF6bI/SWF8jrM TCYaDQjicRfOTZnK8P9fOMIv/tmTCIUigb5N6VAoed71109k9gZ9DSxSed7jgpne1ZZCReG5 YPQ/MAeF7USkVzGHFrI9f6WsRYfjC5aWNAm31Lprw9iDaqnJt7qxB9XSml9MnnY/HX6YvOx+ Ofwsjj6EQx53C1X4h/vryjqHS901EadY3lVpDnlIC5W5w/a8y61VNmuaXDrDyPJEPhLWNjbX NZUPHxHRZUfWekchhtmT6z7V3a3/TP9ZL7vC6Cj6MEUJmHvdWGQy09n4RnJg+c9uCJUVt4yi ZUPdEtMA3uCyCJd8qM1W7fL54/V6l60F1nfh88ZEblzS8roulUqktG8aixT0BXRpi9Wtr08E fLuqsuU4sHBVyBf0R9x9V7lj0LoxmGwXnXk1gUcJI/t2McrhiL3NHfEHfYhwU+LvPyltAk6b YKMPi/hr/Uv8lzZJscYaf5NP5lLmAsbOhKtbT7rqlY2+Jr91dHl0lD+arqmWjWqKVpfXuAyq lmbswjd3d7EYb4HjpQGs2AWjg7Ejw1IGrPgy5zQcFgGf+dixE7hs+p5ZjLFKm7ND9UZ1Br4K c+HOGrJn1UZRbFE6vXpiXVVywmnQU7zJ5Ghvqm6ImedWhR30u+i4umxi9H9nQsFkg8aZzdqc Z3pKeoLJXRiyfsGS7NsuWoNcecR8fQa3taxKvBv8IpCJsEduhD3C4mvD8ylNl2jsUu0XD9pD ppAtaUiWN5XXmGpsTQYWKLxJfZOg0ZWTVku5PMM2ME8N3sDUk2CgaCMQyrcxud9ulG4svPPV 3wtv06rer2jmzF8ef/XVx/e8/KowrdBb+AWdB3liph2FnWc0lH76KaX93Z/yUDbGhndyuB2p BDfPzQ+nnQRbX3Z44N1WVZcuEoiE5ijmiMsUy8R1inWi0uuw6iWbSadSChGfHEehy4OaKNEF x7hMNjA4TGzYjixAU1JyA17kBx3YfWWbLyw4YTrHVBxQeMzF5qLOQF96/oH7H7gf4guizRaA 2XfD2JmwC+nb/+g7/c+nJWMhs3rNqtV96/whJr6CgaJF+MJzzx0uvI05NWFOz4IOlSRPHsvP YBO4qJlNYUnV1VWKymYaa64aqUpiriP1I4WRFaTT3522qbrq9HWZ6pjTZvBLDnNVc1IpjGxI K2NUrw6MlMpJtaw8Vj4MbnPMY3akW5jKgKUMAw8CDZ4zOLY4bUaxXHn05jBtbjcXibYB5Jom zUir2GkohVbfg5ADI1u4dwPIEYtSfoDNBxvSxaMZiHbbflAFsA7FKmgLevPbP9ty66b3Wxsz icbCvkAoVuVvbITGDdLd991TM3rSlh9XxE1v+odBA6zMpuXiK02TRm6UnIXLFy9avKTvqrOa 4DZXNBBwByu3XrjqUZ8u5iq85Y0Ew+PlEg3OqinaFbf3vydV41zJaPJa/o5447imTY6fNt3V dJ9jq/7+7IOwrx8N/HL07obO0QebDjsOBAyJWKAyTORqscnuaJRavJVf1pR9aYRP3lLTFf7C u7/lYKt15Hm5i3KL9Ys8i2oXNSwzLbOt9qyuXd2wzrbOtEa/Ub/ZdFPzTZ6bas3Lsuuym7Oi jrga7Y6mQFZeH4tb5C5F3DJ2RP1YhasVRIgYYVHHsB0UWN48sAlTvGdAprCVKlo1zBjnLmy6 eL7ENmCv1HANW/Tsita4t3gupmSOs2gZ31Hk4oOOkoWiibhYDte3QlMWvOfSG36x8OKtb790 5sX66yYJrkAqIGljoVq3Vuv/0ZS196xcvfOpfaffHX9bsDKYrf/CmIlNT1rHnnfdxVPmac3u nXfe947b67ZWZN9VB6MTE5Zc3bXzz5upN9seu+3x37JAY9H/Wwkaz5Ir8yNdTpKF7ea0GFVy InfZxYyrs7y70tMViVamE76IO6g1GkSnpVytwn6rM2sZHxznhmIe79YlxqVzCKOxwFk39l9K fDuAnpK/l3s9x2NDDRmFVmHi+KrN1NVCO/G4GPZlaotSVPQbSgL4B/r1nxS8lcGgoBZCEXFx JETLhEgk5hHUhU+2c9/vzNvc99te+ETUtsXDIa+eTgzDYSkcMvpoKBhvoxJj9QHnr0iDw7GX ugXzz5Hr85NaLa2Odku7Y5FlkWO1ebXlKoeqwpDKScTWlU444bJ0BhTd6YPViWQoGgwmAy5v BXPjmK3rHVYRjdYkNcP0uqRUoyQtiIid1T8DaGBX7gDjMAMzg1moEUKO2cEDyvYHdTJAQf/m n3AU1R5CZATm+1HmbiQt9uD1591+Y+3k2sSojzOhcKpRe/wPR/4uGVlshLkeZz66cnFieOsT rwj13ji3831n9v/jH//4HaMBbf8p6SXgAO855NPtehqL6mMImRi0mLBd0R06GPeVpS0C5LPB 59fHlC7JMkGPcyhlE6Q41vxYBzc7Os5OCayCcAczdfVEDylF8GTDgIrlNTpei3oeK4XW5WHS Eg7OCnAV4mJsE/5sBd9qD6RxgiWXgBhPN8VTmSuwr9q2MV2ZaKQIiiRqNIV7vSFXw6i4ICEo ygyOcLDvXvGSIDdR4XhNawtfxs6mshOrRDqCeTeSzfncywE6rmJGhRAI0FhD0i6qO3OGbini 9tWltYKjIpGkykYSUKmBCe1ES93EdBOb+sDM082vc4+Tz9pMVJifCnqjgqiRc/DzrSxOzH41 QRqRS+IvwWavVyJQDMu+GCjugAwvGWs259Dp46wjM+dhqZUy4lD8LHpCZfNUuh2q1xY8UJWM D6OjrYFIRHObaDCNs9lVx19RWB1tZhy300SjPhttrY8nK7cAEdN9BqPzzG7R6QtGPFF3wN9n 95qNDmHfmckOvSkgfhbweyKeSNDHZzAdeLsGeGshX+dnyP0TWsb6Z7VM928y3Ky7z3CPbq9h t67T8JzuVy3aWEvWr5cCPkM5SMkh787n0mKgqyGWUWfqRlpHpuAj6kFTgUw2l2/RDA9bU+6w ui4sDh+Fsz9dxxBN/oArRaj/s049YxdGWymSBR6Zq2SAfjbAZm7ltJXBGAeoLUdyqM3zdtab 9WGx+wC/j9FmkRLZPRmUAqxNBnrksXuWFPNKnoGKpR3FDeOz5qFzwMMakFcDO3MDfi09VxHX 01eT4WCgLxzNpUzqv/SoLZm6RKgvEIynC6/Si1LQcYVTNaFUPt5P+irHZBD0/yYQS1TRaZJR gDeFyFUgUniZtuCQUjQcjAQKUwtJMeDzR5llTecXHvJEY76oH2RM38aexf2FLTi7+TAsxsa8 T2PVlZH/UXxt/R9dt12nLLPqmegyIaQMupxShh1adpSzKKLBzX2Q5kzDZWSDbIkfznYkqTD+ cXco4C78w5tIeGm5OxByP/6dz+kORlyyO10RPyJuoPhBYxiRD7AxKAhG8DVG8sMopIf4EEwm ie0TY5cTo4AcKY0Cg2DjGMwQ3LMrxQ6EjY97gn4P1fgSCV/hlBvB0cdxisvlRsTq9JWuSNDt 8oLbb+7/XLpZPACfrZbcmJ9xnWyzDKfULHcrfinbpcA5g9hey0H1897DhvIKt6O2PKsimoQj Lp44YaXWPtVpve8794nIt/r3Et9nk4ZG42GjmE1W1eZA21VeB4nGp8pjQVMdMxxOwS9jthyP 36V7uvtK8Tvmmw7YDIh9VGFCpe2yWltRHXK/1Tb0HFbpEB/nfrG1fmn19mevnL7+uHLaq0vu fu4fHzVePeKK1ZNf8bojHz+x70B2HA4WPeAKyelho+GSma0zN45/e+Lk3RsffEqnV6y6oj0d bpq2/+lCkwcebcAHvLT290o34jRfGXZFjrdcCHusHO8GluMtISveHS3H+yhWvNfK3hnLYKcg DPzpkGdvprnANydwjj9MCVrkyOvwLrUF7win8G52EO9fu3DSnr0hRvH2ogxAyaPg1UdxLvQg rgdxVeKMfxx93bhHhBPmwhn/EKQnez57LzKGtwWwEngPwEguRM8L0GcaepxPsogFdmP3Fiq0 hFVGM3zHqbe7gKjzQAOjnY7wwCYELC6RxUWJxQwvKBLlzkKJkgaULXw8i3D/ln37b938zDNP Dnv8sjeppvDV65fenzNZn4tGqlotplZEfO/1ODc/e9vmA/t/9rMDwg1jJxb+5zdHCr0T26Y6 7cyplYgPByjNFsx6HmivErSXIuvyF2103a67L/iQbof2PuOu1PO6w8EDKbWyTEGJaJCmlF1c dmXZItdq1/qyh8qeLtvl2udRe2ynQ2WGE1Li29B7la3GVmu7sd26J7IndjhyOKbUmknWr2g3 x6LT2V4MjvxxNPCd7S49jm1xe4xF287ZYuAbTyX6Y5vcnMtxpAvHKfm2010RhAQjEWfUldk0 6/7Xnr9r9No6k68l7I0W3n/8eOHP1Pf78+4T50l+b6btcDjszZ5/wa9+fveL4bDGURv1TnmU Wt95h9rYIX/4h5j/dtBYCDT0Yct00JgOK6kDjcnw9ogSdKYDncnw1poStKZD6sL6G/C2SBUo T8S7hsyKOIGjEgbQmh21J1D/LcrvodQP6vkePZhf1ApKace1Hde9oOm9oJ7DuB7mGpntAiYx Cg9CbewXjHgye7oF/ZL4tSjqZ6DlQtB5DO+tTGdU1oPDYl04QQ06OsvTYGp2sLJEepzCIPKH 82AKDrwzBNoGU1OJhYODj5eJd1kMzQcufbGf6n+7dFdT7YzqePSox1mZTUV8ffue3XTrs89s 3vKUxTOt7QJa/pu3qWnCOLoeRwVBUt/f5w8hKPfqrfue27L5wCGO4yXA8Wy8UecCN73YMpks AT6vBuzmYCV7ML89WItDKLP3Wxm3+pFagL1OsgH8SwG341kn+PMgutH2LXq9B4y14s52wG7o kj3g2z1YnT244yDKh1E+jPJhlNX8TR588wNPNWIsKuA6htSOGIGbc/N0EhqgUuAN//kmR08f O3nIUAo6ZcHeUFHrFHdCOUbBsQhhhv1cblKzcv+ONTh97IF6XPT+peB4GvjyPWpNX6I7s1jY rNuzbuMh+vAdD1wfcbkztmwNVRz/mBr7yaFhkRuvufNnGCBG+wJsmSaZF/7P7S3VWH32Rq8T 8s6P3Ank2Mn6ToxahzpKrFRAXT8oj4De5KjTI4+j9sCBGmUC+ZRGiZ0DsOFpUVw94PkoaqLA kRqnBnD8pAtntWHfgHhKfhL3j7DBA3cf7AqMQGANxPOHSqYiCwMTkF1QH262i8hKfoO4PZ6M R89cxdK9u+KVidiDv/tsxbKqkHFTduUCuiCeTEUKu28PIbgfQiIsjCDXevCRXK03Zr/4igao g+iZBxheBLKxsFLaKD4IvqknX7XMB78m8MaUDzybwJ6hD2/E+/DWX4L8CNcnAI8g/wKuh0F7 +5Fne8pJBLnTCIjyb5DAtpJjP5GghmH4BGiD0Rl7x/oE2oyUSfpvsS8rYS+yFbhuBZW249qO 662gnL3QE3uxKodxPYyrCk/P4Cx6Gr+lwm95gOFq/NrtKD8NEADtwH8UNBwmw2BQ9pzqYGEl HIgs7qv19HSzU0DA+MBKwG3poGdVck2Evc0ySC8j7lRkcO6VgMGxFgOWIBUm3rh7940/eewx mnEFhv3XpqsurQ46V7i3/mj41nnP/7Pv8KS72pzue2Kx3BijqHz4hvWPPLJ+/a4zlT9bk5o4 KZXxpnW3PLp23Kh/vfzKmYbG8RZzMBjzYfaLQJ/rIDcbyJst40FrUVCcBtKR+REhUBSbH7Ox COqieMNbDxwqQaFJ4JS9kc3oNAd8u1AOsuA08nbcl0Itw1wDcMbeGa8DDhnOZLjDC/0axCrb IQlN6DWDr2cUbRegPAd9p6HXLNII/QsxiNBVcbsbZPtDRAREDOuNm+29TBeXYlqoztSfIxeZ KsaBoiKzD7j71FA8nHhudXWvqRUi8l6nZ8Ltk+55Mp1LxWKFb9L+eEPwssVLdwSbE/504Zto NN26pah6raZCU2vLC7sLTdgUD8ERdtOda9bduqQwj+2eMxXNaH03cDxVNg+0HiXXtSSQBoEv 9l0aFZURF3AbBFVWAD/fY/5m5Hzg7hAwibegsCZ60DCzX3zAylzk86ihfJ2i6OdDvxh4Hjtg HfxcPsMMoIQgtnl3Cu84DOxZFBnbNMDUJQe4hDHuCQvqaH5ELNySj3bCDQgH033fxWKJBM2+ Fk/iRHnY6ZVeuHxYeub0eKSv3I99PDB7QLgBAc6g1cTm+2VhjbidzzdBrm5h71ZGOI96seJ8 1mc51Iu5MxxEMH/GoUlwogtzi2LmcswsAnoqzlmDXBC1UTwJh8hx/kV/rKQbS1vYOA3C+YzZ wOec/vx3Jqs1FL2n4nQ3x1qGR0P5lhjVeQIN/3XLysvAWFe5f/6jwtr52VhMiLIJL2uomjUz Gv3+8PqbwE9VjJ9u3i28jUNAbNIU71AS6V7wUTP5pmUsKDmFt0FT2JmuxGnHJORECjSdxPdO mgFN4IgYVjmGGbIvLpSjNgV7NIm5ylBLQSkSKQduzCSG1AfsmMFzTXhaGWikBq3sjgrcUYla HAzCncz2GYacEvzDrJAo9KWGDGfuQq77GPQB4xAwDI7S9DDTgpEIZydkmL9rJSnKxoxn4tqE v2aSZDWAZt6CV5tx5dEGuK3wWXtYgAGBhQz8VrYV9m+Hb5iZawgXj2hyisPhdi3VUc6STKdw 8qundJ+/ojMaS0/KxKfn4tGXnR7q93tTCaqLxOabyuILcnfSddOTYRym+J9ULBotfEjXF47H MkUjmFksVtOZ6q+1AZvHEwg0qwVBVptaX1jENg09fmdUA9+bQqoTib297iSzWrzAJKqgW/vP cl6R15RoUaCJ8aGEPwJOY5w7FbxGAawGr4p2dXUU35ACGrkkYow2xIUcwmRCcO/8bDxKJ2J6 jdCt6TOQEmAsi7SlOAVmdBXZCb9B+bnDz2FvTaEVLZfhSzjDyN0Y0138WyAEGtOMmcg5rU2B ttNi1MOhTas5z7CvlZxG5CmFOVaDfvLIfwudl2CSBz2/h88UxD1jQJ9YX9ijowDNZDFgDUCO N5ujmO8Y9BuP36qELqwBbbhxF5M4w2GxsK+BaIEbOTQ3Qa+FSC9CXx++MeNEPdPqF6O1HqWL cP8MPJFxAatj3tZUtnHfjT1GPdta1Pfi3VsmtIriC5fiuSYWFU83s/AMO9LDjvowhPOOfIP/ HEHOKHA4NZSO054r3X84nAGyLMbKi+mAcuDkKx6vHjFxhnF4PBBcn/S2NlW2OcPNiUAGcj+c bjUbx1bHYvf5LUJ8btPYOdbEFeNuuEY/IhEKro1FhMotCzesKMxjb7XFRrnp7sltM2przhxn ugDhQbdwgy8WDNrCqcTwESObH3+h6CJnsFtRlB/r4b81kbdbJkIiaCEHlFjhJGwL9sUT5p2c BkdzTYz1NGA1U1gL9jUwpoOrsa5MR4SAfRfsRgfurearVo7nsK+XNSEqwb5cNgxWYnlJExc9 3YvQewb6sxVKoq2oic3QxMOwXmwzZRZh+53/URmzhRiA/6CPB2ljhJ7dpbOJpYX5QV6cu4jF F0mqv4Y2TqTT835Qx+nmj/OhRCO08ZL7oY1DYw/VxePQxgyzYb/V1DqgjKN+TwLhqrPKOOFh C4BZz4YPs0p8FtRpI2PyNeSETn7C8q3uPXurorWsTdZG2xXtZXNkc+hew17To7ZHyw8bDpsO 2g6W68WYZpEqZpxu53GrotKBGIUdXTp8CL+fMo+/6N4SYcn2I6/fd9+RLuGxwkdfflH4iIa+ +IKGV712zz1Hjtxz76/p7A8KJ6n+gw+orsC+GCiQUbCJb4RNHAPO/9QyA3ZvCBCF7euG7RsC RGH7usE97IsFYXCVC7PQg1YYBShQdwK1adCJF5FKgu+ZSDj4LyJ6okDNt1j/Nvi1bZABc3Cd g+uj8EN2g24O4noIVyX0UQ7PNOCZSkg6HfDEZCGTeSn8agA5Zu0x7RKAvDCjnXnZ55Nadm6K Wb8DOpiZatzx6kEIhbtdxVN6jFhgBA81x4qRZmbsFmkErhgiBZHoOdhddDISCacL42Lx6jEm 05jqeAwBktZHL36TavvJG5c920zrNj+7/9Zb9z3dT3AIyheCjStpGdOZLfPHji2cPHqk0DZW eHrzLc/s23TrPobzycD57dwPqSEfITa1F3P/JWb/CDDBPM7nkd+PvByS14E1wDupwLgIy4RZ a+xLWidQDgHbbnDXCXDet9CfIvCvIG7gvxYyVw1gvq0aIOAXjHiykcvABKwZFo3CGmEFarAq WTzXjRLT6SwGxiweFjFIAM9hYJzJAROiBsA3k50M4UBokQH/F4yzRmwADXopiRqY0xEqRREG OxnnSszqvn2bEZ/a/LOnhVUjnl12pNBPdf81d9dYp+eeWCQ72sRiVLHC2HQ4FqFv3PLUM5tu eebZvqfo7WPbCkd+R3Vjx863mLHD6/v+a6xById4IMaP817Qw1dC1iXJjS1pUFMMFOfikg66 ltEtZspiMYxmGQ0P0PdWYGIX4ACAfWmK0SmjUjPWR1ei0yJtmkGdZahLMbu4C0ji+2LF0+I9 MH94TK8ouDLhc7T0OUpiQFwN+MIKQaLnMYv4zFXRWDz5VOv8TDTW7XRd/LtrZl1R77ctT05+ 8lKc/xwwiZl1aDHvvWb1+IZww/Arr8Xcn+3/UrJh7nk6p+VuHM/KwUY0YH1zWFMDvmvThO/Z VACcABe+Xmcim0ArN0GW/xR9HkD7XdwGcOLqIjvQfh/at6J9G9q3gTrvA608iX6PoN8jeM4j 6LeH83o5sJcB/VWBqptA1RUAJ8AFekwgClEJzGaB+wDAj5YUqBNnFKAFyvBsI8bHtIedy4My rM8wfIsnjC/6xEDVYZpH/xO4w45VG4G298gKrA1kB1paYJPW4BfKIWVY7KIMz1XimfiOB3+u Bau5GN8J9MOz9hMcm0EfP3gnjVoCHdfCrFgcemMvjcJoZcKX7ST0dfX0dMCSBf0PcgxB7PU8 iDFok7ykaSB14GMjPefIKgtR/vA5Ce6PP+sPx+368sSuhZdtWHp9/VsfvPvipJ1S2QhPwO8L elJec+21589ddfVr77xy7EDDzy4L5gw4e/BsKjIsYKhrmT52XPNtN9/082Q0l1tTm64OGrPJ C/Ij6yTZzVtuftjisNmYvU4Rs+yVFkiHgZGdLY3wxMvJasBNgK2AXQAZZIENmPIAtJAHacj4 FO5lVtdptHhR14maCI+qgXWoErXvYRUjxAd5znQFs3FF5A24G6er8adDPQXgvZQOuAPstc6i Duc7rB3NcBiKUaIBxQ55PRAD4lKkKLyLkQt+kPKsw106U4nPkVyTrUwkCssuXDqn4HFFs00L Hhiz5qGo2bA3Eam5cGU4mgqIiwLwGQvP7rrkspjbn7VFQ20Tg/MWeelkIN9ztDYZz836LcPT eHwlaBW+MZUlj7cwemTSUQTlZ0E7zOpl3/SpQA2L80Sg8QgoWQu5EQAmTJDSFZhzJSg8jJwZ +GHfgfnBdq1CPQE+WRyJ2aU2cKMRsU0mcZmeC0O75SBtcTADJlBJ2DLZMYAztv8CNDI65AgD LQ685HsWLz9EIIoWajHoM7iZLr9s1fIdm6LBSOL9iLcqixgb4hDzNp336KOW1lw0fk/QSVf+ ePWtl9AH/MFIyJ8/M80XZn5P68T6p5+hv2ZazsX2GSmJ938s7QS+IuQXLVHIBB18zjB4lEUZ 5SXK8HC7AbYjl7dyYCsIbEVxfwSY8AGv7EtKCmBKBM6YjGZfTozC78F/7kmWzhdg0lDozIE0 YrNzDG6N4CF65NhjvLwuguUYg1o8nG9Js11PZfFEEb4Zwni1KIOT9D9tyTMz4P5R8MSpvSGS Gx2mEvU3T6qLNNDaWCw7ylg45Mimk2mHyDW9F9uTZ9YKN+PVJC+LcZ2J1vt9w/DTtL8HeHkX eGkkx1pGQlMrsMbMtiX4xiZUEuYYBM24MFvmhzdBYlH0ZdFXL6AaetoBHCiBsRSmJcGvkYCz JvRgO/FO9Gb7VY24r/h1qWpwsAblS8G1S8HlFDkTchrC9vaxuc/28HBOA297sIMar0OGlfae jYgIjeGjCeFajb8a4kSOWXwVuCrZb7J9ZGVPMWU7x2e/VVS0pUo4BZcm8TU6HgXDlv+AICwi XFH6vJEw7wZ1LBaK6f+qSoSjEVpWF7EaDJW+xiduKItFQ3H99Y/ak2MyoRqq8XpDuU/Ko9FQ Qkv7CmHs2ueE434c3vVG7UFJJp15nB7AHn+2ME+YiYCYB7sIPuGMiVUxYkNkT8J3+choejV8 2jrgqw5ksgbXa6APbgZsgid6M6jvJtSxc4l3Y/Z7UHcAVw0w64elQNDPD8yOhtb04z0AP74o Nxo8G8CX50bjCaOhBUeDp2NIWU89Vgo78Gj3YgXZDk+c2LGCLXimFjXMfmYrrYOUzKLOh56j UKvEGpeBoJdDfiyDVluOsgupBSUJ1zzKUwHzACKgjLSCPTpwZlb/2anPSgGXgbcFBha3CpMf g4MDY/AjxaMCYzi/jMKPB1CbxR/+IVc8SsB4id0xCsCGxg4djMEBA/AawICBAkpt1Yy/QBfF 8wRDTxewA3xDjnSf5bizcWZb/Tn0w3iyKO/PemtRutmdG5atLfR4YnVNZtpa+LW2sbJ6/NG6 bH2N8sOjlmF1mToqeaO5elfhEzpXHUlk2t6qzWUSw/q2hAOhQMwTDuAVy1ovd4wDoffe8wej wagX71m9X9gbRnsg5I98w+ilAfb5FtBLmrzUkgPCfLClfWQxYAlfVRZDywABzEbsxAqmsdqe 0hrDrsQaMw8oA1Sy78Kl0av4/TcleNgMqbgUVwnr5uQ5+MBYP0TL9MXFO3uGip37Lp29YcvB EM+exwQeWwi260B4rRclvKND9Gwh+EogTsaPThaReDYAbUKk4j9JvtI6KARnckIN4l3V6XA0 evzhwp1cAtqGcQmoo+bomJpIw7fxaGpYP4Gdya1rOlJ4m+kBLgOPC+zIBmQg+A+DAy7fAO9p gMsoFVoWIrJDYHtGoe2i4B4zWYzyWlzXQkathQbchPwm5Jn9eR/y9yHPbM09yBf354zAuBlg AhiRwwF7+EBRSFYTJGUUfGMCn0WBWRNWhvktUfRiUc1OYE+GlXBg9WTAnQNrgDxWi62iDHxe jt5mrCXTSHISQn8NShSsEQJXWnDVgxNjWK0evBSe4xYgDmDj+z0wEqGdoZBe5jyEx2BJmNlD mKhkWifD+WDw63ADcUh/MTrOrZiShKRb6NfAb6Bm1JlHhjU6qoTmAk68hUKjxwu2seMqK7fU TEdEaHdltCrlzFQJTdUz4BPtjUfxRvUEJqhAi8NxrnoL7DUWcwiSfIsV1IbvPdMIZmQBxtju pwb2vBFfuGY2CD52wHN3wZbGp9+YNDn1GSZ8qhnvI+Uy9fwMR3Gkg18lH5wffkFD4wUXNDad Lw6bhty0psbzC4vaGxqnnd/UeMHyYhPLsi7nNzW08yvzh/m/wl3Y1/1P/6agku1my2ANsC8u /vvXFod+a5G9dDL0S4vnfmcxB6F27pcVR0CutoI+h35NcTKZAml7PnTIBfCkL4Tsn4E931n4 wuscxBc74LczKjcC2D85kwljRk1su3BycvSVa666dPFVpRbWrRUwFTAPsAKwAXAHYCdgH+AV wDuAE4CTRcQIelx9gAwgD5gKmAdYAdgAuAOwE7AP8ArgHcAJwEmGNIAe4ANkAHnAVMA8wArA BsAdgJ2AfYBXAO8ATgBOMuMEoAf4ABlAHjAVMA+wArABcAdgJ2Af4BXAO4ATgJPMnAHoAT5A BpAHTAXMA6wAbADcAdgJ2Ad4BfAO4ATgJEMmQA/w9Zf+oYKczVPiG1L2DykHhpSjQ8qxIWV2 qmPw85nXM7iMvYhzylVDykweD+6fGVLmKnbQ+HND2quHlPmR8kH9a4e0M0tm8O/VDykzC3Rw e8OQcuOQMvNzBvdvHlIeMaQ8ckg5P6TcMqQ8akh59JBy65DymCHlsUPK44aU8e7bOeOfMKQ8 cUi5bUiZ7SgMnv+kIeXJQ8pMMg3uP3VIme0oD25nvt3gcvuQMou0DW6fPqQ8Y0gZ76ec03/O kHLHkPL8IeUFQ8oLh5QXDSkvHlJeMqS8dEiZvRE3eD7M4xlcvmxIedmQ8uVDyojhnXP/FUPK Vw4prxhSXjmkfNWQ8qoh5dVDysxjGDx+rq8G8ec1Q9qvHVJeO6R83bllX4SV/z+XPMm/CmVu ZHN0cmVhbQplbmRvYmoKNDIgMCBvYmoKMTc4MDQKZW5kb2JqCjQzIDAgb2JqCihNaWNyb3Nv ZnQgV29yZCAtIGRyYWZ0LWR1a2hvdm5pLW9wcG9ydHVuaXN0aWMtc2VjdXJpdHktMDMuZG9j eCkKZW5kb2JqCjQ0IDAgb2JqCihNYWMgT1MgWCAxMC45LjQgUXVhcnR6IFBERkNvbnRleHQp CmVuZG9iago0NSAwIG9iagooV29yZCkKZW5kb2JqCjQ2IDAgb2JqCihEOjIwMTQwODE5MTYw NzQ0WjAwJzAwJykKZW5kb2JqCjQ3IDAgb2JqCigpCmVuZG9iago0OCAwIG9iagpbIF0KZW5k b2JqCjEgMCBvYmoKPDwgL1RpdGxlIDQzIDAgUiAvUHJvZHVjZXIgNDQgMCBSIC9DcmVhdG9y IDQ1IDAgUiAvQ3JlYXRpb25EYXRlIDQ2IDAgUiAvTW9kRGF0ZQo0NiAwIFIgL0tleXdvcmRz IDQ3IDAgUiAvQUFQTDpLZXl3b3JkcyA0OCAwIFIgPj4KZW5kb2JqCnhyZWYKMCA0OQowMDAw MDAwMDAwIDY1NTM1IGYgCjAwMDAwNTc1MTQgMDAwMDAgbiAKMDAwMDAwMzk5OSAwMDAwMCBu IAowMDAwMDMzMjA0IDAwMDAwIG4gCjAwMDAwMDAwMjIgMDAwMDAgbiAKMDAwMDAwMzk3OSAw MDAwMCBuIAowMDAwMDA0MTAzIDAwMDAwIG4gCjAwMDAwMDY5MzUgMDAwMDAgbiAKMDAwMDAz ODQ2MyAwMDAwMCBuIAowMDAwMDA0MjAwIDAwMDAwIG4gCjAwMDAwMDY5MTQgMDAwMDAgbiAK MDAwMDAxMTg5OSAwMDAwMCBuIAowMDAwMDA2OTcwIDAwMDAwIG4gCjAwMDAwMTE4NzggMDAw MDAgbiAKMDAwMDAxMjAwNiAwMDAwMCBuIAowMDAwMDE3MDM1IDAwMDAwIG4gCjAwMDAwMTIx MDQgMDAwMDAgbiAKMDAwMDAxNzAxNCAwMDAwMCBuIAowMDAwMDE3MTQyIDAwMDAwIG4gCjAw MDAwMjIzNzcgMDAwMDAgbiAKMDAwMDAxNzI0MCAwMDAwMCBuIAowMDAwMDIyMzU2IDAwMDAw IG4gCjAwMDAwMjI0ODQgMDAwMDAgbiAKMDAwMDAzMzM3OSAwMDAwMCBuIAowMDAwMDI2NzYy IDAwMDAwIG4gCjAwMDAwMjI1OTQgMDAwMDAgbiAKMDAwMDAyNjc0MSAwMDAwMCBuIAowMDAw MDI2ODY5IDAwMDAwIG4gCjAwMDAwMzA2MDEgMDAwMDAgbiAKMDAwMDAyNjk2NyAwMDAwMCBu IAowMDAwMDMwNTgwIDAwMDAwIG4gCjAwMDAwMzA3MDggMDAwMDAgbiAKMDAwMDAzMjk5OSAw MDAwMCBuIAowMDAwMDMwODA2IDAwMDAwIG4gCjAwMDAwMzI5NzggMDAwMDAgbiAKMDAwMDAz MzEwNiAwMDAwMCBuIAowMDAwMDMzMzI5IDAwMDAwIG4gCjAwMDAwMzM1NTIgMDAwMDAgbiAK MDAwMDAzMzgxMiAwMDAwMCBuIAowMDAwMDM4NDQyIDAwMDAwIG4gCjAwMDAwMzkxMjggMDAw MDAgbiAKMDAwMDAzOTM2MCAwMDAwMCBuIAowMDAwMDU3MjU1IDAwMDAwIG4gCjAwMDAwNTcy NzcgMDAwMDAgbiAKMDAwMDA1NzM1OCAwMDAwMCBuIAowMDAwMDU3NDEwIDAwMDAwIG4gCjAw MDAwNTc0MzMgMDAwMDAgbiAKMDAwMDA1NzQ3NSAwMDAwMCBuIAowMDAwMDU3NDk0IDAwMDAw IG4gCnRyYWlsZXIKPDwgL1NpemUgNDkgL1Jvb3QgMzYgMCBSIC9JbmZvIDEgMCBSIC9JRCBb IDw2NWZjZjY1NTI3YjBlMGNhNDZjZWE2ZThlMTcwNDNkOD4KPDY1ZmNmNjU1MjdiMGUwY2E0 NmNlYTZlOGUxNzA0M2Q4PiBdID4+CnN0YXJ0eHJlZgo1NzY1OAolJUVPRgo= --------------030103090407050108050200-- From nobody Tue Aug 19 09:09:43 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D9A1A04E9; Tue, 19 Aug 2014 09:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGIa2Ru598Oc; Tue, 19 Aug 2014 09:09:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA5D1A055D; Tue, 19 Aug 2014 09:09:37 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:52760 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XJlyZ-000G8F-Lt; Tue, 19 Aug 2014 12:09:35 -0400 Message-ID: <53F376BF.6080701@bbn.com> Date: Tue, 19 Aug 2014 12:09:35 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dcrocker@bbiw.net, saag@ietf.org, "ietf@ietf.org" References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> <53F26D8A.1050304@bbn.com> <53F27065.9030902@cs.tcd.ie> <53F36E34.7020701@bbn.com> <53F36FB1.4020008@cs.tcd.ie> <53F371CC.7020106@dcrocker.net> In-Reply-To: <53F371CC.7020106@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/d8kEhBZVloDGol6pn_luGIWlnV8 Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 16:09:42 -0000 Dave, Thanks for the diff! Steve > On 8/19/2014 8:39 AM, Stephen Farrell wrote: >> also do a diff of this vs. -03, > attached > > From nobody Tue Aug 19 12:05:54 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1B81A0706; Tue, 19 Aug 2014 12:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvpinXZpeH5D; Tue, 19 Aug 2014 12:05:51 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D851A05D1; Tue, 19 Aug 2014 12:05:49 -0700 (PDT) X-AuditID: 1209190f-f79aa6d000005b45-a2-53f3a00cfbc8 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 6E.DB.23365.C00A3F35; Tue, 19 Aug 2014 15:05:48 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s7JJ5l3J018835; Tue, 19 Aug 2014 15:05:47 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7JJ5jl6021352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Aug 2014 15:05:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7JJ5ijT002130; Tue, 19 Aug 2014 15:05:44 -0400 (EDT) Date: Tue, 19 Aug 2014 15:05:44 -0400 (EDT) From: Benjamin Kaduk To: Stephen Kent In-Reply-To: <53F376BF.6080701@bbn.com> Message-ID: References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> <53F26D8A.1050304@bbn.com> <53F27065.9030902@cs.tcd.ie> <53F36E34.7020701@bbn.com> <53F36FB1.4020008@cs.tcd.ie> <53F371CC.7020106@dcrocker.net> <53F376BF.6080701@bbn.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUixG6nosuz4HOwwau9ohbPNs5nsdg4m9Fi Sn8nkwOzx9TzoR5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4c9Og4BRbxYqDO5kaGJewdjFyckgI mEgcb50DZYtJXLi3nq2LkYtDSGA2k8SfBR+YIZyNjBJrd/9ghHAOMUnMebCeHaRFSKCBUeLc pmIQm0VAW2LR63XMIDabgIrEzDcb2UBsEQF5iW/HtrKA2MwCRhLfuyYxgdjCAoUSN3d1gNVw CqhLfN/yE2wmr4CjxLwNexkh5v9lkli8SBbEFhXQkVi9fwoLRI2gxMmZT6Bmakksn76NZQKj 4CwkqVlIUgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpmujlZpbopaaUbmIEhSunJP8Oxm8H lQ4xCnAwKvHwKmR/DhZiTSwrrsw9xCjJwaQkyntnLlCILyk/pTIjsTgjvqg0J7X4EKMEB7OS CC9rB1CONyWxsiq1KB8mJc3BoiTO+9baKlhIID2xJDU7NbUgtQgmK8PBoSTB+20eUKNgUWp6 akVaZk4JQpqJgxNkOA/QcJ75IMOLCxJzizPTIfKnGHU5Wpre9jIJseTl56VKifMeBRkkAFKU UZoHNweWZl4xigO9Jcx7H6SKB5ii4Ca9AlrCBLRk6+KPIEtKEhFSUg2Mk8TWqOR+dLscNrnz yw4PexvZMIsfeRHvLr5r/nuZ2f2lzxX5UxOama1ClgqmiHxMLVyyqm4N3yL5H07qMxgWNnKe /rXWzHZ10h5tiTrN5WtV7d8VJwXdKrp7Jd9H7f6it4FzVk90rnz9JHvb/7fx+cl7OQ5L/Nrk /ljy6QSG5Sf3f1y011vVVYmlOCPRUIu5qDgRACJLzUUOAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/saag/vHRq6tXLXlANzDfwSSPgdv-9YB8 Cc: saag@ietf.org, "ietf@ietf.org" Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 19:05:52 -0000 I'm happy to see that Steve's proposal shares a fair bit of structure with the changes I have been making, in particular the breakdown into "determine the peer's capabilities" and then "figure out what to actually do given that information", which I think is key to helping readers understand things. Steve is being very aggressive about reducing verbosity; I'll need a closer read to see how much of that I agree with. One thing that I do see from a quick skim is the change to "Opportunistic Crypto-Security (OCS)" instead of the existing "Opportunistic Security". I don't think that Viktor (or the group) is likely to adopt that without the sense that we have a consensus for that term. Thanks for the rewrite, I look forward to reading it more carefully. (And thanks as well to Dave for the diff, it is handy.) -Ben From nobody Tue Aug 19 13:42:15 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E5D1A6F15 for ; Tue, 19 Aug 2014 13:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16AYH2gA8x4k for ; Tue, 19 Aug 2014 13:42:12 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368BE1A6F14 for ; Tue, 19 Aug 2014 13:42:12 -0700 (PDT) X-AuditID: 1209190d-f79c06d000006f95-06-53f3b6a2b060 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id D0.11.28565.2A6B3F35; Tue, 19 Aug 2014 16:42:11 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s7JKg99v014001; Tue, 19 Aug 2014 16:42:10 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7JKg7aA024806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Aug 2014 16:42:09 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7JKg7Y8014045; Tue, 19 Aug 2014 16:42:07 -0400 (EDT) Date: Tue, 19 Aug 2014 16:42:07 -0400 (EDT) From: Benjamin Kaduk To: dcrocker@bbiw.net In-Reply-To: <53F3611B.3060208@dcrocker.net> Message-ID: References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrLt42+dgg3sHGC1+f/rAZjGlv5PJ gcnj0s6TbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4d2Mxc8FMgYrpS3+yNjD+5uli5OSQEDCR WPp7JjOELSZx4d56ti5GLg4hgdlMEiu7VrKDJIQENjJKXNuVCJE4xCRxYfVtVgingVHizpUH YO0sAtoS8z49ZgGx2QRUJGa+2cgGYosIiEr03NvDBGIzCwhKXOrfAmYLCxRLPL2yFqyeU0BH 4sTmXlYQm1fAUeLRr4XMEAtaWSUur1gJViQKVLR6/xQWiCJBiZMzn7BADNWSWD59G8sERsFZ SFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXSy80s0UtNKd3ECA5WSd4djO8OKh1i FOBgVOLhVcj+HCzEmlhWXJl7iFGSg0lJlNd7A1CILyk/pTIjsTgjvqg0J7X4EKMEB7OSCC9r B1CONyWxsiq1KB8mJc3BoiTO+9baKlhIID2xJDU7NbUgtQgmK8PBoSTBu3MrUKNgUWp6akVa Zk4JQpqJgxNkOA/Q8MUgNbzFBYm5xZnpEPlTjIpS4rz+G4ESAiCJjNI8uF5YMnnFKA70ijDv apB2HmAigut+BTSYCWjw1sUfQQaXJCKkpBoYQxeVsr7uj5fVEC31FzsaFFYhGfbcxJlZPZ2N VdCvdu7TxL1+R1adaz5dt3fxnJslTzoebtnyevrZGa1J7HFb6uf3b+ta0GDQdu7NJf3Cwjy/ 9xdSNykXn54Qs27qhsBfE2+GaFuf2vzLbX/kxh1bI86vNXndczKsTn3tEdkjbh8nvnDd2CFc rsRSnJFoqMVcVJwIADnDEKMBAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zKz2xoWRXfzxZ17-gygopKSF4r0 Cc: saag@ietf.org Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 20:42:15 -0000 On Tue, 19 Aug 2014, Dave Crocker wrote: > On 8/17/2014 6:52 AM, ianG wrote: > > On 17/08/2014 14:20 pm, Dave Crocker wrote: > >> This is an example of confusion about the meaning of the term design > >> pattern. It is, equally, an example of the draft's limitation in > >> carefully documenting the concepts it is attempt to teach. > > > > I am not confused at all about the term 'design pattern', it's a term in > > wide-spread usage. > > The examples I cited were for very different meanings. They undermine > the current usage. > > Since you say it is in common usage -- presumably with a related meaning > as that in the draft -- please provide some pointers to examples. I think probably the easiest way to find some examples is to load up www.amazon.com and search for "design patterns" in the "books" category. [lots of point-by-point commentary trimmed] > I could imagine having a paper that explores such choices and then > provides a variety of examples. > > This draft isn't that paper. Dave, I think you've done a great job reading the document and pointing out places where the text of the document does not match well to how people are describing what they want the document to say in the list discussion. I think it would be a much more productive use of everyone's time to actually go and make the document say what people want it to say, rather than continuing to discuss the ways in which the current text is flawed. I, for one, have been trying to do so. As a case in point, we seem to have some concern that the term "authenticated encryption" is poorly defined or confusing or otherwise problematic. In https://github.com/kaduk/saag/commit/1e10ebc320d1a4d13dd0c693b07bba2492aa1947 , I propose to define a new term "authenticated connection" and define authenticated and unauthenticated encryption in terms of whether or not the encrypted data is transiting an authenticated connection. By separating the two security mechanisms, I think that the potential for confusion is reduced. -Ben From nobody Tue Aug 19 13:54:36 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939221A893B; Tue, 19 Aug 2014 13:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lkgbGv4cH6K; Tue, 19 Aug 2014 13:54:32 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477EB1A891A; Tue, 19 Aug 2014 13:54:32 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 324712AB2A7; Tue, 19 Aug 2014 20:54:31 +0000 (UTC) Date: Tue, 19 Aug 2014 20:54:31 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140819205430.GM14392@mournblade.imrryr.org> References: <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/y0rDESsGrJ1cPLGsd2GSafrJjpo Cc: ietf@ietf.org Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 20:54:34 -0000 On Tue, Aug 19, 2014 at 04:42:07PM -0400, Benjamin Kaduk wrote: > I, for one, have been trying to do so. > > As a case in point, we seem to have some concern that the term > "authenticated encryption" is poorly defined or confusing or otherwise > problematic. > > In > https://github.com/kaduk/saag/commit/1e10ebc320d1a4d13dd0c693b07bba2492aa1947 > , I propose to define a new term "authenticated connection" and define > authenticated and unauthenticated encryption in terms of whether or not > the encrypted data is transiting an authenticated connection. By > separating the two security mechanisms, I think that the potential for > confusion is reduced. Based on Steve Kent's earlier suggestion, I had updated my work-in-progress document to avoid the problematic term. Note, in many cases what we have is "authenticated sessions". Not all protocols are "connection oriented", and notably TLS supports session resumption. So "authenticated connection" is perhaps not optimal. I had used "authenticated encrypted communication" as suggested, but will see whether that is still needed after further suggested revisions. Thanks for the concrete feedback, it is much easier to work with suggested text than without. -- Viktor. From nobody Tue Aug 19 14:03:14 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FF61A013B; Tue, 19 Aug 2014 14:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX5VuUqym-8N; Tue, 19 Aug 2014 14:03:03 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id B154E1A8753; Tue, 19 Aug 2014 14:03:02 -0700 (PDT) X-AuditID: 12074422-f798b6d00000386f-62-53f3bb86e094 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 66.35.14447.68BB3F35; Tue, 19 Aug 2014 17:03:02 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s7JL31Nf016593; Tue, 19 Aug 2014 17:03:01 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7JL2xNM032509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Aug 2014 17:03:01 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7JL2xxT016630; Tue, 19 Aug 2014 17:02:59 -0400 (EDT) Date: Tue, 19 Aug 2014 17:02:59 -0400 (EDT) From: Benjamin Kaduk To: saag@ietf.org, ietf@ietf.org In-Reply-To: <20140819205430.GM14392@mournblade.imrryr.org> Message-ID: References: <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> <20140819205430.GM14392@mournblade.imrryr.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixCmqrNu2+3Owwa1eLotnG+ezWEzp72Ry YPJYsuQnUwBjFJdNSmpOZllqkb5dAlfG/l0HWQoWsFRc+/2YqYFxH3MXIyeHhICJxKUtm1gg bDGJC/fWs3UxcnEICcxmkujcepodwtnIKHH6QyszhHOISeLRlQdMEE4Do8TqV+fZQPpZBLQl Hv+6zQRiswmoSMx8sxEsLiKgILFycjvYDmGBYomnV9aC2ZwC1hJX5kLYvAKOEr8+7YTa/YtZ YmnrNrBBogI6Eqv3T4EqEpQ4OfMJmM0soCWxfPo2lgmMArOQpGYhSS1gZFrFKJuSW6Wbm5iZ U5yarFucnJiXl1qka6qXm1mil5pSuokRFIzsLko7GH8eVDrEKMDBqMTDq5D9OViINbGsuDL3 EKMkB5OSKO+BHUAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrysHUA53pTEyqrUonyYlDQHi5I4 71trq2AhgfTEktTs1NSC1CKYrAwHh5IE755dQI2CRanpqRVpmTklCGkmDk6Q4TxAwy+C1PAW FyTmFmemQ+RPMepytDS97WUSYsnLz0uVEuc1B7lOAKQoozQPbg4sibxiFAd6S5j3CsgoHmAC gpv0CmgJE9CSrYs/giwpSURISTUwspscecLw+0Jijt3326oPKwJnHUx59mLiXUu2csHCM9dS XWJknKcL5Im98Hrfz3xiwecjL96eN55sxRg2jcl1VerHCc9mCkh//VM7j/OOLnf91ZrnbSWL Txr6/AlrljGbLvQyWi0vuWva09oSma08BlseVQbUcVzTuhPLp8o3c7VcwvcLu74rK7EUZyQa ajEXFScCACB/Qv39AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/saag/lXt394xFfM02H1vqBidJlh8JoUs Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 21:03:09 -0000 On Tue, 19 Aug 2014, Viktor Dukhovni wrote: > Note, in many cases what we have is "authenticated sessions". Not > all protocols are "connection oriented", and notably TLS supports > session resumption. So "authenticated connection" is perhaps not > optimal. I had used "authenticated encrypted communication" as > suggested, but will see whether that is still needed after further > suggested revisions. I agree that non-connection-oriented protocols can cause confusion here, so "authenticated sessions" may be better. -Ben From nobody Wed Aug 20 01:25:54 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF551A0085; Wed, 20 Aug 2014 01:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.97 X-Spam-Level: X-Spam-Status: No, score=-2.97 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmtxoV3zD92F; Wed, 20 Aug 2014 01:25:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 856951A005C; Wed, 20 Aug 2014 01:25:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIK96381; Wed, 20 Aug 2014 08:25:45 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Wed, 20 Aug 2014 09:25:41 +0100 From: Hosnieh Rafiee To: "saag@ietf.org" Thread-Topic: [saag] [Secauth] secauth requirements and usecase scenarios - link Thread-Index: AQHPu8LDhZ897soOiEqt1l7j1u4jrZvZH7KA Date: Wed, 20 Aug 2014 08:25:41 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A2838A@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A27C16@lhreml513-mbb.china.huawei.com> <814D0BFB77D95844A01CA29B44CBF8A7A27C5E@lhreml513-mbb.china.huawei.com> <20140818163957.GP14392@mournblade.imrryr.org> <006101cfbb2a$e7a6c2c0$b6f44840$@rozanak.com> <006b01cfbb31$45f54fd0$d1dfef70$@rozanak.com> <20140819003927.GR14392@mournblade.imrryr.org> <002301cfbb6f$a51c8f30$ef55ad90$@rozanak.com> <53F36502.4070002@joelhalpern.com> <814D0BFB77D95844A01CA29B44CBF8A7A27FD5@lhreml513-mbb.china.huawei.com> <20140819153137.GA14392@mournblade.imrryr.org> In-Reply-To: <20140819153137.GA14392@mournblade.imrryr.org> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/saag/EdIWNevDTE_uPaUFCYsUB9v7NrI Cc: "secauth@ietf.org" Subject: Re: [saag] [Secauth] secauth requirements and usecase scenarios - link X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 08:25:51 -0000 Thanks again Viktor for your continuous suggestions and comments. >=20 > On Tue, Aug 19, 2014 at 03:20:00PM +0000, Hosnieh Rafiee wrote: >=20 > > > If DNS is protected, then DANE could be used. With greater > > > flexibility and less modification of existing tools. > > > > As far as I understood from DANE document, by knowing only the IP > > address of a node, DANE cannot work because IP spoofing is still > > possible and there is no CA to protect this. No bindings of IP > address > > is available. >=20 > This is not a DANE-specific issue. Typically, applications want > channel security to a destination that is a domain name, not a network > address. Absent a secure mapping from one to the other, there is > little that network-layer security, that authenticates only the network > endpoint, can do to close the gap. I agree that there is a gap in security especially in the end points. But I= guess it is also important to try to remove this gap. Maybe it is not poss= ible to completely remove it but do as much efforts as possible.=20 I still think that secauth can work on making this gap smaller by network s= ecurity. I agree that most applications are working with domain names and n= ot the IP address. But where they bring this domain name? So, the initial c= onnection is with an IP address. As I also mentioned the cga-tsig draft as = an example case, it can secure the communication in end point with DNS serv= er where DNSSEC or other approaches are unable to do this or they cannot ea= sily do this. And of course secauth also wants to consider privacy, this is= why encryption is a part of that. But it can be handle by other protocols.= like my example about SSH.=20 To be clear, the plan of this API is to offer solutions in first point of c= onnection or automate this step as much as possible. When first point can b= e secure then you can combine this approach with TLS to also encrypt all th= e data or use the offered solution by secauth to encrypt the data. This is = then your choice. =20 > This problem applies equally to DANE, Web PKI, ... So it appears that we agree on the problem and we are talking about the sa= me problem. I think the solution I plan will work...=20 I am not quite sure but I think for requirement draft, it is important to i= dentify the problem(s) and explain the requirements to solve this problem. = And of course there can be some usecase scenario that where we want to go a= nd how we can use this approach. If there is other things need to be added to the requirement document, I we= lcome any suggestions.=20 Today I am working on the requirement draft to cover what we discussed here= .=20 > > Secauth only provides a transparent API for you to use it in other > > layers. >=20 > The requirements draft is very unclear on this. Is this an attempt to > expose the security state of the network layer to applications? Yes > Possibly also allow the application layer to in part control the > network-layer security association for a particular flow? About this, I am not sure.. depends on other's opinions.. and decisions. > If so, the draft should probably talk more about what state it intends > to expose and what control mechanisms it intends to provide. Or at > least what the requirements are for exposing state and controls. Agreed. Thanks, Best, Hosnieh From nobody Wed Aug 20 03:40:37 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE451A01D2; Wed, 20 Aug 2014 03:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OP5k3LvRIgx; Wed, 20 Aug 2014 03:40:32 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9CE1A01D0; Wed, 20 Aug 2014 03:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3039; q=dns/txt; s=iport; t=1408531232; x=1409740832; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=bQ0J6IQ+Ou9DVfF/wAjCv29zHbUJXiVL3NAESlD6oAo=; b=JLEpFChcS7sM0urc/cjetNIW5Wq/BMgFqB5beYEqkSom1Z6RnbtIiq/A IJkP+RrtMlfK8h99gtyP6y61TBOMeaneiajaKMOtSLM3hiUCPHaQ8wFaU 1Hp98zt6GYlX7UJl3eEnS0syOf19/FMpnXo2KfQLG9CR9HEdU/rubHpoi 0=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMEANR69FOtJssW/2dsb2JhbABZDoNSV4J8yUYBCYdZAYEld4QEAQEEAQEBIEsKARALBAETCRYEBwICCQMCAQIBFTAGAQwBBQIBAYg+DawylUoTBI9MB4J5gVMBBI8ShBOBSodThyuNXIIXgQREOy+CTwEBAQ X-IronPort-AV: E=Sophos;i="5.01,901,1400025600"; d="asc'?scan'208,217";a="148000781" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 20 Aug 2014 10:40:30 +0000 Received: from [10.61.109.234] (dhcp-10-61-109-234.cisco.com [10.61.109.234]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7KAeTXk011435; Wed, 20 Aug 2014 10:40:29 GMT Message-ID: <53F47B1C.8070105@cisco.com> Date: Wed, 20 Aug 2014 12:40:28 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Kent , Benjamin Kaduk References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> <53F26D8A.1050304@bbn.com> <53F27065.9030902@cs.tcd.ie> <53F36E34.7020701@bbn.com> <53F36FB1.4020008@cs.tcd.ie> <53F37696.8080000@bbn.com> In-Reply-To: <53F37696.8080000@bbn.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wPM0OGkMOpVfMo0rf9oWI2nCpU9jFeElg" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FDNTijf4ACzZBGfMxT2g1jKOdGc Cc: saag@ietf.org, "ietf@ietf.org" Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 10:40:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wPM0OGkMOpVfMo0rf9oWI2nCpU9jFeElg Content-Type: multipart/alternative; boundary="------------040902010108030407050603" This is a multi-part message in MIME format. --------------040902010108030407050603 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Personally I like your proposed version, Steve. It sorts the definition issue nicely, retaining the already well defined scope. Thanks. Eliot On 8/19/14, 6:08 PM, Stephen Kent wrote: > Sorry that the doc was mangled by some MTAs. > > I have attached a PDF of the doc, which I edited in MS Word, based > on the .txt file as an input. > > Steve > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------040902010108030407050603 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Personally I like your proposed version, Steve.=C2=A0 It sorts the definition issue nicely, retaining the already well defined scope.
Thanks.

Eliot
On 8/19/14, 6:08 PM, Stephen Kent wrote:
Sorry= that the doc was mangled by some MTAs.

I have attached a PDF of the doc, which I edited in MS Word, based
on the .txt file as an input.

Steve 



_______________________________________________
saag mailing list
saag@=
ietf.org
https://www.ietf.org/mailman/listinfo/saag

--------------040902010108030407050603-- --wPM0OGkMOpVfMo0rf9oWI2nCpU9jFeElg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJT9HsdAAoJEIe2a0bZ0noznAgH/AxgT9ZgKfVbT+0jFr1au9oE 9PAlVUvIMzkOZjF0k4By8x05/2Bw3E+8HqO4vPMERyiP6uaGddubHHP6HyndyJx9 +3QcdgciO3fqHwnCimKxFnpMeNpMyT9N9wttzLou10KWzVrbbAc2BvXFqFxV1vtt jAlTUw19sGWQ29+j3s4SC84rJS9YoDumxue1Hw8RdHpdM4Vb8tiRPgCvE/GSdKx0 dm5FxBBXltuhpH0mLLAs2lQeijZ7Vukkxk71dzEcxw8cRGED+Ax6IvcdG7fmOnW/ 0UOJafpj/60nFnV83qTpy8D/n9r8YfVzLTTVjxFgNLftzjDphiK50qtiVdg9EC4= =PFCC -----END PGP SIGNATURE----- --wPM0OGkMOpVfMo0rf9oWI2nCpU9jFeElg-- From nobody Wed Aug 20 08:04:04 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C5A1A0327 for ; Wed, 20 Aug 2014 08:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AKYjpE9vB_I for ; Wed, 20 Aug 2014 08:03:58 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F021A02E6 for ; Wed, 20 Aug 2014 08:03:58 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49641) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XK7Qa-0008Om-Nc for saag@ietf.org; Wed, 20 Aug 2014 11:03:56 -0400 Message-ID: <53F4B8D8.2080808@bbn.com> Date: Wed, 20 Aug 2014 11:03:52 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/9BdbfRZsQH8OC5reS0S56EeQrkE Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 15:04:03 -0000 Ben, You noted my use of the phrase "Opportunistic Crypto-Secruity" instead of "Opportunistic Secruity." I made the change after someone else suggested it as a more precise description of what we're doing, and because it has the advantage of being represented by an acronym that isn't so common (OCS vs. OS) in our arena. Steve From nobody Wed Aug 20 08:11:58 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6211A0712 for ; Wed, 20 Aug 2014 08:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiG9ciGi2p4v for ; Wed, 20 Aug 2014 08:11:43 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 38C151A06DD for ; Wed, 20 Aug 2014 08:11:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D443EBF14; Wed, 20 Aug 2014 16:11:21 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ACj96f0J2ye; Wed, 20 Aug 2014 16:11:21 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B538CBEFC; Wed, 20 Aug 2014 16:11:21 +0100 (IST) Message-ID: <53F4BA9A.40100@cs.tcd.ie> Date: Wed, 20 Aug 2014 16:11:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Stephen Kent , saag@ietf.org References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> <53F4B8D8.2080808@bbn.com> In-Reply-To: <53F4B8D8.2080808@bbn.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/GSVVUuUrYvvvs0Fv6CWySDd_468 Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 15:11:51 -0000 Steve, Ben, With no hats, I prefer OS to OCS myself. Can't recall if I said that on list before or not, sorry;-) Wearing my "will have to figure out rough consensus" hat - let's not debate that again, I think everyone who stated a position on it was already clear, so I can't imagine what's left to be said. But if someone who's not yet stated an opinion wants to, that'd be fine. And since this is a straight forward OCS vs OS thing, sending to me (and say Paul H. as shepherd) offlist is fine and I'll summarise any offlist mails I get on this when we're done (incl. email addresses, so no cheating:-) Cheers, S. On 20/08/14 16:03, Stephen Kent wrote: > Ben, > > You noted my use of the phrase "Opportunistic Crypto-Secruity" instead > of "Opportunistic Secruity." > I made the change after someone else suggested it as a more precise > description of what we're > doing, and because it has the advantage of being represented by an > acronym that isn't so common > (OCS vs. OS) in our arena. > > Steve > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From nobody Wed Aug 20 10:01:50 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79E31A047C for ; Wed, 20 Aug 2014 10:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzkRNSB-aPbG for ; Wed, 20 Aug 2014 10:01:47 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 852741A0401 for ; Wed, 20 Aug 2014 10:01:47 -0700 (PDT) Received: from [192.168.1.65] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7KH1hM6030617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 20 Aug 2014 10:01:47 -0700 Message-ID: <53F41581.2030508@dcrocker.net> Date: Tue, 19 Aug 2014 20:26:57 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 20 Aug 2014 10:01:47 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ti2C0RX6Sv5PZ-4C5OEOMDIHkGA Cc: saag@ietf.org Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 17:01:49 -0000 Benjamin, On 8/19/2014 1:42 PM, Benjamin Kaduk wrote: > On Tue, 19 Aug 2014, Dave Crocker wrote: >> Since you say it is in common usage -- presumably with a related meaning >> as that in the draft -- please provide some pointers to examples. > > I think probably the easiest way to find some examples is to load up > www.amazon.com and search for "design patterns" in the "books" category. Note that I offered some citations for the term, a day or three ago, that I found through an online search. Also note that their meaning was not obviously related to the use here. Since the term is in such common use, we ought to be able to find some useful references that do not require buying a book. More significantly, please note Steve Kent's observation that there is little obvious need for this specialized term in this draft, especially since the use of the term 'design pattern' in the draft is not well-defined nor all that meaningfully used. >> I could imagine having a paper that explores such choices and then >> provides a variety of examples. >> >> This draft isn't that paper. > > Dave, I think you've done a great job reading the document and pointing > out places where the text of the document does not match well to how > people are describing what they want the document to say in the list > discussion. I think it would be a much more productive use of everyone's > time to actually go and make the document say what people want it to say, > rather than continuing to discuss the ways in which the current text is > flawed. Sorry for my confusion, but it appears you are suggesting that the way to improve a document is to ignore its problems? In any event, I've suggested how to improve the document, when I could. I've asked for clarifications (albeit sometimes by indicating what I don't understand) and have noted few responses that respond with clarifications. Basically, I do not know how to make a document better when folks don't engage in developing shared, concrete, substantive understanding. Since you seem to feel that you know how things should proceed constructively, then please explain how to 'make the document say what people want it to say'. It's certainly a a worthy goal. > As a case in point, we seem to have some concern that the term > "authenticated encryption" is poorly defined or confusing or otherwise > problematic. Oh? I haven't noticed concern with that term. The concerns I've noted have been with other terms. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Aug 20 10:42:56 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBC11A065E for ; Wed, 20 Aug 2014 10:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IN4_eM7-kCuD for ; Wed, 20 Aug 2014 10:42:51 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57CB11A0687 for ; Wed, 20 Aug 2014 10:42:48 -0700 (PDT) X-AuditID: 12074425-f79e46d000002583-dc-53f4de17a37b Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 1D.52.09603.71ED4F35; Wed, 20 Aug 2014 13:42:47 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s7KHgki2007837; Wed, 20 Aug 2014 13:42:46 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7KHghlu004609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Aug 2014 13:42:45 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7KHgh2E021371; Wed, 20 Aug 2014 13:42:43 -0400 (EDT) Date: Wed, 20 Aug 2014 13:42:43 -0400 (EDT) From: Benjamin Kaduk To: dcrocker@bbiw.net In-Reply-To: <53F41581.2030508@dcrocker.net> Message-ID: References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> <53F41581.2030508@dcrocker.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6noit+70uwwdwpvBa/P31gs5jS38nk wORxaedJNo8lS34yBTBFcdmkpOZklqUW6dslcGWsO/uJueCbccWVryoNjIc1uxg5OSQETCS6 Dp5ghrDFJC7cW8/WxcjFISQwm0ni5tK7UM5GRomLx34xQziHmCS2fLjLCuE0MEo8fPCOHaSf RUBbYt2pHWwgNpuAisTMNxvBbBEBUYmee3uYQGxmAUGJS/1bwGxhgWKJp1fWsoDYnAI6El9v bmfsYuTg4BVwlGhfUgwx/zarxKVHO8DuEwWqWb1/Clg9L9CckzOfsEDM1JJYPn0bywRGwVlI UrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3StdDLzSzRS00p3cQIDlUX1R2MEw4pHWIU 4GBU4uG9sehLsBBrYllxZe4hRkkOJiVR3gO3gUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeOuv AeV4UxIrq1KL8mFS0hwsSuK8b62tgoUE0hNLUrNTUwtSi2CyMhwcShK81XeBGgWLUtNTK9Iy c0oQ0kwcnCDDeYCGzwCp4S0uSMwtzkyHyJ9iVJQS52UGSQiAJDJK8+B6YankFaM40CvCvOYg VTzANATX/QpoMBPQ4K2LP4IMLklESEk1MKq475STrvu38+1CQ2uhhlsRimd+TRa1T8xObm7x 2qr46diNX2z8B+YWyRw7xLR9lfyt5vV+Ovc7Q0/s3dFgcfN4m6HKC46uPeqZp+bvvzt5zxe3 K8/nbyo0MetLyb/23PyoyIRXd2Zq2l991v8/+VWc8PLrHIV3n0pW1R/ktDnAqWGmExN3fJkS S3FGoqEWc1FxIgDrtet6AAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/saag/guaKKhYvZccwzgCEBKTgWyIAlIc Cc: saag@ietf.org Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 17:42:54 -0000 On Tue, 19 Aug 2014, Dave Crocker wrote: > Benjamin, > > On 8/19/2014 1:42 PM, Benjamin Kaduk wrote: > > On Tue, 19 Aug 2014, Dave Crocker wrote: > >> Since you say it is in common usage -- presumably with a related meaning > >> as that in the draft -- please provide some pointers to examples. > > > > I think probably the easiest way to find some examples is to load up > > www.amazon.com and search for "design patterns" in the "books" category. > > Note that I offered some citations for the term, a day or three ago, > that I found through an online search. Also note that their meaning was > not obviously related to the use here. I saw those. I concluded that the online search used to find them was finding results for an unrelated topic, and that more accurate search did not find them. I thought I covered this in http://www.ietf.org/mail-archive/web/saag/current/msg05388.html ; if you disagree, perhaps you could reply to that message? > Since the term is in such common use, we ought to be able to find some > useful references that do not require buying a book. My implied assertion was that this term is used by textbooks used for undergraduate CS classes. > More significantly, please note Steve Kent's observation that there is > little obvious need for this specialized term in this draft, especially > since the use of the term 'design pattern' in the draft is not > well-defined nor all that meaningfully used. To me, the meaning of the term is self-evident: we are attempting to describe a common pattern shared by designs for certain internet protocols, and promote the use of that pattern. I am open to being persuaded that an explicit definition should be given in this document, but my understanding is that most readers will understand the meaning intended. I guess I did not particularly note Steve Kent's statement at the time (I assume you refer to http://www.ietf.org/mail-archive/web/saag/current/msg05369.html). Perhaps we can break down the term, which (again, to me) divides naturally into (protocol) + (design pattern). Since both you and Steve Kent do not see the meaning of the combined term as naturally as I do, I am forced to consider the possibility that it is not in fact a phrase that needs no explicit definition. What does the phrase "design pattern" just by itself mean to you? > >> I could imagine having a paper that explores such choices and then > >> provides a variety of examples. > >> > >> This draft isn't that paper. > > > > Dave, I think you've done a great job reading the document and pointing > > out places where the text of the document does not match well to how > > people are describing what they want the document to say in the list > > discussion. I think it would be a much more productive use of everyone's > > time to actually go and make the document say what people want it to say, > > rather than continuing to discuss the ways in which the current text is > > flawed. > > Sorry for my confusion, but it appears you are suggesting that the way > to improve a document is to ignore its problems? No, of course not. I'm saying that there is no need to point out the same problems repeatedly using different language, once those problems have been acknowledged. (I will grant that it is less clear that anyone other than me has acknowledged some of the issues in question, to date. But, per RFC 7282 as you noted in a separate message, I expect our ADs to take note regardless.) > In any event, I've suggested how to improve the document, when I could. > I've asked for clarifications (albeit sometimes by indicating what I > don't understand) and have noted few responses that respond with > clarifications. If I remember correctly, the "lots of point-by-point commentary" that I trimmed from my reply boils down to basically the question of encryption vs. more-than-encryption, and different ways to authenticate a connection. The author and his fanclub have repeatedly stated that the document is intended to be about more-than-encryption. In many places in the current form of the document, the word "encryption" is used and it detracts from the meaning intended by the authors, you are correct. I have attempted to go through the XML source and change them, as part of https://github.com/vdukhovni/saag/pull/2 . On the question of ways to authenticate a connection, I believe that multiple examples in the document have been quoted on this list. This seems to be becoming well-trodden ground; I would rather have a new version of the text that makes these examples more clear and prominent than continue to discuss the known flaws. > Basically, I do not know how to make a document better when folks don't > engage in developing shared, concrete, substantive understanding. > > Since you seem to feel that you know how things should proceed > constructively, then please explain how to 'make the document say what > people want it to say'. It's certainly a a worthy goal. Patch the XML make a pull request? All I can do is quote http://www.ietf.org/mail-archive/web/saag/current/msg05368.html: % If anyone can suggest better language, please send a patch % for the XML: % % git clone https://github.com/vdukhovni/saag.git I have some out-of-band reason to believe that the author has been reluctant to take sweeping changes, but I hope that the recent proposals from myself and Steve Kent have indicated that doing so will greatly improve the quality of the document. As you yourself have said, we have a long history of spending the time needed to produce quality documents. (Speaking of time, it looks like I've spent some forty minutes drafting and researching this email. That level of detail becomes a huge mental drain when one is trying to keep up that quality of response and yet there keep pouring in tens of messages per day even while one is still composing responses. This is what I mean by my remark about "require more hours than there are in a day".) > > As a case in point, we seem to have some concern that the term > > "authenticated encryption" is poorly defined or confusing or otherwise > > problematic. > > Oh? I haven't noticed concern with that term. > > The concerns I've noted have been with other terms. I did not intend to imply that my example was relating to concerns that you in particular had raised. It was rather an example of a concrete suggestion made in the form of a github pull request, that happened to be easy to describe in emailed prose. -Ben From nobody Wed Aug 20 13:46:31 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEB91A0714 for ; Wed, 20 Aug 2014 13:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqU3bVknaHeI for ; Wed, 20 Aug 2014 13:46:28 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B0F191A0661 for ; Wed, 20 Aug 2014 13:46:28 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 7269310062 for ; Wed, 20 Aug 2014 13:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=paqX0MRyGNpSDKR5aBGP gDbgnyw=; b=yNHyxgRjYY/jOQ91MB3Nt8uX3AOuzrYqhdE8sB4ENNteY3P2bf09 IELqDGkvNiEYVkR92Kb00Wqt7BLrIqrzTRC/EPooOUhMk23+3r1eis1ldhpGLfcp 7B+Dp+jupCueFrCLCH4rFGMxg62mX8AwAdeps2p5BiSWlh6wD1FVzMI= Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 209AA1005D for ; Wed, 20 Aug 2014 13:46:27 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t60so8504686wes.34 for ; Wed, 20 Aug 2014 13:46:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.72.209 with SMTP id f17mr17699742wiv.3.1408567586830; Wed, 20 Aug 2014 13:46:26 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 20 Aug 2014 13:46:26 -0700 (PDT) In-Reply-To: <53F4B8D8.2080808@bbn.com> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> <53F4B8D8.2080808@bbn.com> Date: Wed, 20 Aug 2014 15:46:26 -0500 Message-ID: From: Nico Williams To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/9nitVA-aLdwOZ3coX-M0owd73g0 Cc: "saag@ietf.org" Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 20:46:29 -0000 [I've been too busy to comment on Stephen K.'s proposed changes, but I will soon.] First, my sense of Stephen K.'s proposed changes is that they don't change the substance of the draft. I.e., we really are and have been down to matters of style and wordsmithing. Second, OCS is not a good term. I've given my reasons for this before several times, and if need be I'll repeat them again; I repeat some below. Third, I'm not a stickler for purity when it comes to terminology because we already have many conflicts between the protocols in Internet security space. I'm uncomfortable enough with Viktor's use of "authenticated encryption" that I second using "authenticated sessions". Back to OS vs OCS vs OE vs any other options: - OE is no good: OS denotes more than mere encryption with unauthenticated key exchange, whereas OE doesn't denote the possibility of strong authentication. - That OE was used before does NOT bother me. If I didn't have other reasons to reject OE, I'd take it. - OCS is a bad term because I expect that this document, like many other RFCs, will bleed into popular culture, and so we need a term that users can understand. OCS is too long, to start, and it's not clear to me that "crypto" will mean much to users. Whereas OS is short, sweet, to the point, does not misrepresent, and denotes roughly the right meaning. Nico -- From nobody Wed Aug 20 20:34:03 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA27C1A6FAB for ; Wed, 20 Aug 2014 20:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oo8K8zyxwRJR for ; Wed, 20 Aug 2014 20:33:57 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020B01A6F87 for ; Wed, 20 Aug 2014 20:33:57 -0700 (PDT) Received: from [10.225.7.207] ([50.59.22.2]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7L3XrtE003036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 20 Aug 2014 20:33:56 -0700 Message-ID: <53F56802.9080907@dcrocker.net> Date: Wed, 20 Aug 2014 20:31:14 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> <53F41581.2030508@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 20 Aug 2014 20:33:56 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/1o59_t9S6DDwSqfYzIdJ31FMTOE Cc: saag@ietf.org Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 03:34:00 -0000 Ben, On 8/20/2014 10:42 AM, Benjamin Kaduk wrote: > On Tue, 19 Aug 2014, Dave Crocker wrote: >> Note that I offered some citations for the term, a day or three ago, ... > I saw those. I concluded that the online search used to find them was > finding results for an unrelated topic, and that more accurate search did That's fine, but the alternatives you found really do not look any more satisfying. Remember that the claim was that the term was in common use. Again, if it is so common, online explanations should be readily available. Yet there aren't. My guess is that folk are confusing the common term "design pattern" with "protocol design pattern". The former is a nice innovation of perhaps 30+ years ago, but it's a very general concept. The latter has little or no established use, I believe, and the lack of online examples encourages this view. Any online use that is close, isn't all that close. > My implied assertion was that this term is used by textbooks used for > undergraduate CS classes. We are not in a CS class. If the term is in common use, it will be in use beyond classrooms and textbooks. In any event, the current draft needs to explain the term well enough for the reader to know what it means, just as it needs to define the 'protocol design pattern' 'os'. It doesn't do that, either. >> More significantly, please note Steve Kent's observation that there is >> little obvious need for this specialized term in this draft, especially >> since the use of the term 'design pattern' in the draft is not >> well-defined nor all that meaningfully used. > > To me, the meaning of the term is self-evident: we are attempting to To you, perhaps. The next reader might think the same thing, but wind up applying a different meaning. Again, this document is supposed to be a specification. (A definition is a form of specification.) Specifications do not make assumptions, especially when the readership is highly diverse in training, culture and primary language, as it very much is in the IETF and the rest of the Internet. Once again, to the extent that the phrase 'protocol design pattern' is essential, it needs to be defined carefully and practically. The draft does not do it. Also again, the draft is supposedly defining 'os' as a design pattern but never specifies the detailed characteristics of that pattern. So there is no way to tell in the future which protocols fall within the design patterns and which do not. In an offlist message Stephen noted another I-D that uses the term: Observing Resources in CoAP Section 1.2 Protocol Overview https://tools.ietf.org/html/draft-ietf-core-observe-14#ref-GOF He thought that it might make the use in the 'os' draft more comfortable. My response was: It's clear and concrete, ... Anyhow, note that coap-observe is invoking an /existing/ pattern -- presumably defined in that book -- which it cites very specifically and then gives a very clear summary of what the pattern is, that is being used. This is very crisp text. In contrast, the opp-sec draft uses the term 'design pattern' but does not invoke or define what that means, substantively, nor explain pattern is being used. Nor is the use of the term used all that meaingfully or consistently in the document. And 'os' is being defined as a /new/ pattern, but has no description anywhere near as clear and concise as what is in the CoAP draft. > describe a common pattern shared by designs for certain internet > protocols, and promote the use of that pattern. I am open to being > persuaded that an explicit definition should be given in this document, > but my understanding is that most readers will understand the meaning > intended. I've no idea where that understanding is coming from, but we have decades or perhaps centuries of experience that teach the folly of doing specifications in that fashion. > I guess I did not particularly note Steve Kent's statement at the time (I > assume you refer to > http://www.ietf.org/mail-archive/web/saag/current/msg05369.html). yup. And its essential point about this is that the term 'protocol design pattern' is not essential to this draft. It become just another term tossed in, without being used productively. > Perhaps we can break down the term, which (again, to me) divides naturally > into (protocol) + (design pattern). Since both you and Steve Kent do not > see the meaning of the combined term as naturally as I do, I am forced to > consider the possibility that it is not in fact a phrase that needs no > explicit definition. What does the phrase "design pattern" just by itself > mean to you? Not sure why the vagaries of my personal meaning for the term are relevant. Again, we ought to have a common, public anchor for terms. And indeed, the term does provide ready and reasonable examples online, such as: http://en.wikipedia.org/wiki/Design_pattern#Alexander.2C_A_Pattern_Language >> Sorry for my confusion, but it appears you are suggesting that the way >> to improve a document is to ignore its problems? > > No, of course not. I'm saying that there is no need to point out the same > problems repeatedly using different language, once those problems have > been acknowledged. First, they mostly have been either ignored or summarily rejected. (It's been amusing to see my assertions of this also get summarily rejected, rather than discussed.) What is needed when someone raises a concern is to engage in ensuring a shared understanding of the issue. That is, engaging in a process that is often called "discussion". With few exceptions, there has been very little of that. Rather, folk have tended to consider responses like "I don't agree" or "That's not true" as substantive and sufficient. > But, > per RFC 7282 as you noted in a separate message, I expect our ADs to take > note regardless.) By the time ADs deliberate, the community process is over and should have established a very clear track record of engaging in resolving differences in views. > If I remember correctly, the "lots of point-by-point commentary" that I > trimmed from my reply boils down to basically the question of encryption > vs. more-than-encryption, and different ways to authenticate a connection. (Side comment: Kent's preference "communication" rather than "connection" or "session" is well-taken, IMO, for the reason he gives.) Yup. Encryption, with or without some form of authentication. > The author and his fanclub have repeatedly stated that the document is > intended to be about more-than-encryption. In many places in the > current form of the document, the word "encryption" is used and it > detracts from the meaning intended by the authors, you are correct. I > have attempted to go through the XML source and change them, as part of > https://github.com/vdukhovni/saag/pull/2 . On the question of ways to > authenticate a connection, I believe that multiple examples in the > document have been quoted on this list. This seems to be becoming > well-trodden ground; I would rather have a new version of the text that > makes these examples more clear and prominent than continue to discuss the > known flaws. Encryption w/ or w/out authentication is the real topic of immediate concern, is the concrete topic of discussion in the draft, and is (IMO) entirely sufficient to justify the document. So the real problem (IMO) is a scope creep infection that is affecting folks' vision. The document does not need to do a better job of explaining the applicability of the 'pattern' for security functions other than encryption. It needs to stick with the actual substance already in the draft, and drop the claim that it is covering more. A challenge for any interesting project is focus. > I have some out-of-band reason to believe that the author has been > reluctant to take sweeping changes, but I hope that the recent proposals > from myself and Steve Kent have indicated that doing so will greatly > improve the quality of the docement. Steve's draft is definitely an improvement. >>> As a case in point, we seem to have some concern that the term >>> "authenticated encryption" is poorly defined or confusing or otherwise >>> problematic. >> >> Oh? I haven't noticed concern with that term. >> >> The concerns I've noted have been with other terms. > > I did not intend to imply that my example was relating to concerns that > you in particular had raised. Sorry I wasn't clear. I wasn't commenting on my concerns (about this) but that I hadn't noticed concern amongst /others/ with that specific term. Perhaps some debate about nuances (eg, does TOFU qualify as an acceptable example of authenticated encryption) but nothing major. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Aug 21 08:35:36 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0E91A068D; Thu, 21 Aug 2014 08:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdsjfvD68603; Thu, 21 Aug 2014 08:35:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A683E1A063D; Thu, 21 Aug 2014 08:35:27 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:35060 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XKUOc-00037m-IN; Thu, 21 Aug 2014 11:35:26 -0400 Message-ID: <53F611BE.20804@bbn.com> Date: Thu, 21 Aug 2014 11:35:26 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ietf@ietf.org, saag References: <53F548E5.2070208@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/aDbX2RSfhuGSw9B9_voeAJ3N1hc Subject: Re: [saag] Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 15:35:32 -0000 Nico, > ... > Near as I can tell there are no remaining substantive objections to > Viktor's draft, only ones related to wordsmithing, writing style, and > the name we'll give to this concept. All of these are a flavor of > bikeshedding. We should stop arguing about such things, make just one > more small effort to adjust Viktor's prose, and publish. I agree that we seem to have settled on a small set of design principles. I continue to disagree with your assertion that clear, concise wording is a not an important aspect of this task. Steve From nobody Thu Aug 21 09:04:11 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E514C1A040C; Thu, 21 Aug 2014 09:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZqU--ZItLKs; Thu, 21 Aug 2014 09:04:05 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB621A03FA; Thu, 21 Aug 2014 09:04:04 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F152E2AB2A0; Thu, 21 Aug 2014 16:04:02 +0000 (UTC) Date: Thu, 21 Aug 2014 16:04:02 +0000 From: Viktor Dukhovni To: ietf@ietf.org, saag@ietf.org Message-ID: <20140821160402.GT14392@mournblade.imrryr.org> References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/chrm4OQgFxgq0_Qsqcsj8y43EnA Subject: Re: [saag] Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ietf@ietf.org, saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 16:04:08 -0000 On Thu, Aug 21, 2014 at 08:24:22AM -0400, Phillip Hallam-Baker wrote: > > There are quite a few substantive threads on it, I think > > the first goes back on March 6th this year started by PHB. [1] > > > > [1] https://www.ietf.org/mail-archive/web/saag/current/msg04604.html > > And in that message PHB presciently wrote: Yes, thanks for that message, it got the ball rolling. > "There are arguments for all of these but I am just watching a > presentation on 'opportunistic encryption' in DANE and I think the > term is selling DANE short. The reasons why that's not the case were explained and we are now defining what it means for DANE to be used opportunistically. It can also be used for mandatory authentication just for the key management part. TLS can likewise be used for sessions with mandatory encryption and authentication, or as "opportunistic TLS" with SMTP. Neither DANE nor TLS are opportunistic or not, they are just tools that can be used in multiple ways. > DNS is an authoritative path for statements about DNS labels. Ergo > authenticated DNS RRs are authenticated statements about them. Correct, and this is precisely why DANE/DNSSEC can be used to securely discover which peers have published TLSA RRs and can be authenticated. The existence of an authenticated out-of-band (relative to the application protocol) mechanism for publishing capabilities[*] is what makes it possible to employ opportunistic DANE TLS. What's opportunistic is still the use of TLS (with DANE providing a downgrade resistant commitment to "STARTTLS" and key material to enable authentication). * Yes OS protocols can overload TLSA RRs as a capability to employ TLS *with* authentication. > DANE > provides authenticated statements about security policy and keys. Ergo > DANE cannot support opportunistic encryption because it is policy > directed encryption (i.e. better)." But the keys are not always there, in fact currently for SMTP, I know of ~32 domains with published TLSA RRs for their MX hosts, and that's probably accurate to within a factor of 10 or so. So from the perspective of an MTA, TLS with DANE is very much opportunistic. * Look up MX RRset. If not DNSSEC "secure", back to plain opportunistic STARTTLS for all MX hosts. * For each MX host (sorted by priority in the usual way) look up up A/AAAA RRset, if not DNSSEC "secure", back to plain opportunistic STARTTLS for that MX host. * Look up TLSA RRset, unless present and DNSSEC "secure", back to plain opportunistic STARTTLS for that host. * If all TLSA RRs are unusable, require STARTTLS encryption, without authentication (since no usable authentication keys available). * If some TLSA RRs are usable, require STARTTLS encryption, with authentication. The above is done for each peer domain, and for each peer MX host. What is opportunistic is the use of possibly authenticated TLS, with out-of-band signally via DANE enabling downgrade-resistant authentication. > With all due respect [1], I don't think this effort is helping the > goal of getting encryption deployed and used. On Sun, Aug 17, 2014 at 11:20:26 -0400, Phillip Hallam-Baker wrote off-list: > On Sat, Aug 16, 2014 at 11:17 PM, Viktor Dukhovni wrote: > > On Sat, Aug 16, 2014 at 11:13:23PM -0400, Phillip Hallam-Baker wrote: > > > >> DANE isn't opportunistic security. It is authenticated security policy > >> and keys. Thats the opposite of opportunistic. > > > > Have you read the draft? DANE can be "opportunistically employed", > > when TLSA records are present, and not when they are absent. > > While DANE is not opportunistic per-se, a protocol employing it, > > for example: > > > > http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-11 > > > > sure is. This statement suggests you've either not read the draft, > > or just skimmed it. It is also possible that my explanation of this > > is too obtuse, in which case please help me polish it, or at least > > chime in on the need for me or others to spell this out in more > > detail, e.g. in the SMTP example at the end of the draft. > > Draft, schmaft. > > Opportunistic encryption is a pre-existing term of art. If the draft > is causing people to get confused about what opportunistic encryption > is then it should not be published. Have you read either draft yet? We're not even defining "opportunistic encryption". We're defining "opportunistic security", which is not surprisingly a broader term. > We have a collection of policy inputs: > > * The https URI prefix means 'use http over TLS' That is mandatory local policy (based on HTTPS URI semantics), and OS is out of scope. OS is in scope for SMTP, IMAP, XMPP, and HTTP where no explicit security mandate is in force. > * Presence of a DANE record means 'use TLS with key matching these criteria' If this in the context of an "HTTPS" URI, then the use of DANE key management for mandatory authentication is out of scope for the OS draft. > * Protocol headers can be defined to mean 'use TLS' > * Manual user config OS is about selecting a mutually supported set of security mechanisms, even if that sometimes results in less than complete cryptographic protection or even cleartext. > So pragmatic security means 'act on the best available intel'. Well, at least we largely agree on the substance. If your object is just to the term, please send your thoughts off-list to Stephen Farrell, he'll presumably let us how the rough consensus worked out. > Using the terms 'opportunistic security' does not help because I am > not interested in opportunistic security except as a last resort. Whichever term we choose will mean exactly the same thing, with different words. So it makes no sense to presume that OS means something other than your suggested term of "pragmatic security", they are one and the same. We're just choosing the term. > I don't expect an RFC titled 'last resort kinda rubbish security' to be > giving me advice relevant to anything other than last resort > situations. Good thing that's not the phrase we're proposing. :-) -- Viktor. From nobody Thu Aug 21 09:14:43 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9F71A069C; Thu, 21 Aug 2014 09:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QMfYCJC16xM; Thu, 21 Aug 2014 09:14:30 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 476AA1A06A3; Thu, 21 Aug 2014 09:14:01 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CE0992AB2A0; Thu, 21 Aug 2014 16:13:59 +0000 (UTC) Date: Thu, 21 Aug 2014 16:13:59 +0000 From: Viktor Dukhovni To: ietf@ietf.org, saag Message-ID: <20140821161359.GU14392@mournblade.imrryr.org> References: <53F548E5.2070208@cs.tcd.ie> <53F611BE.20804@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53F611BE.20804@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/K8KtSlxcLn7gBmyg3LVWNlsKlUk Subject: Re: [saag] Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 16:14:38 -0000 On Thu, Aug 21, 2014 at 11:35:26AM -0400, Stephen Kent wrote: > >Near as I can tell there are no remaining substantive objections to > >Viktor's draft, only ones related to wordsmithing, writing style, and > >the name we'll give to this concept. All of these are a flavor of > >bikeshedding. We should stop arguing about such things, make just one > >more small effort to adjust Viktor's prose, and publish. > > I agree that we seem to have settled on a small set of design principles. Thanks. > I continue to disagree with your assertion that clear, concise wording > is a not an important aspect of this task. Whether the -03 was adequate, or inadequate, I agree that much of the proposed text in the abstract and introduction is an improvement, ... Thanks a lot for the text! [ Wish it were XML, and not extracted from "Word" and sent as HTML, but that's something I managed to get past with help from lynx and Perl... ] I'm working on integrating the improved bits, but keeping more of the original *content* in place (reworked). In deleting the "Pattern" section and compressing the "Principles" section, too much was lost in the proposed revision. So that's where my efforts will be spent, recreating that content with more clarity and less repetition. Still working on it, ... -- Viktor. From nobody Thu Aug 21 09:28:23 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6291A03EF; Thu, 21 Aug 2014 09:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4RZfcv3etSR; Thu, 21 Aug 2014 09:28:20 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1923C1A02E3; Thu, 21 Aug 2014 09:28:20 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id B165B2C807A; Thu, 21 Aug 2014 09:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Mb1pRKsYzBl3v8 N2hUMJB2Mm9D4=; b=bONaGq/6Zt5U8gcALPRLF/35nJV7SRK0mKQA+6NeWUJFZ8 aMOojBenl5DG8iSZYWZJWN4lvAWum10MXLsXDblCXB4zB/3lf00TjOICEEM/9B16 rttGLaaHUGhup7oh3BaCj7GO7JM/qVYev1AI0wdteG4lpqnt6cmzk0b+Fgm2Y= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPA id 4FA762C806E; Thu, 21 Aug 2014 09:28:19 -0700 (PDT) Date: Thu, 21 Aug 2014 11:28:18 -0500 From: Nico Williams To: Stephen Kent Message-ID: <20140821162816.GH3104@localhost> References: <53F548E5.2070208@cs.tcd.ie> <53F611BE.20804@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53F611BE.20804@bbn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/-0RSltog98CsEZNHdALSIOHfPnA Cc: ietf@ietf.org, saag Subject: Re: [saag] Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 16:28:21 -0000 On Thu, Aug 21, 2014 at 11:35:26AM -0400, Stephen Kent wrote: > I agree that we seem to have settled on a small set of design > principles. That's excellent news. > I continue to disagree with your assertion that clear, concise wording > is a not an important aspect of this task. It is important, it's just that agreement on the substance is clearly the first order of business. If we're down to wordsmithing then we can have a more leisurely / less confrontational discussion of said wordsmithing, and finish this up. Nico -- From nobody Thu Aug 21 11:26:19 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA1D1A061D for ; Thu, 21 Aug 2014 11:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avnJ41ezkoLq for ; Thu, 21 Aug 2014 11:26:16 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4F81A045D for ; Thu, 21 Aug 2014 11:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3740; q=dns/txt; s=iport; t=1408645576; x=1409855176; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=yCkuzay3Qi3Sun05UV3pEzy0XoaphL4oQ5Qludb0MkQ=; b=K4kay4CaOmVVaK7ZAmJs8F7uYlnhAZvkHLsvUZGG6Br9eqKxzXqOYkZQ IytQgWQUVFEeMVHq/0sCf6HY4300xtFNpiOL2YIWaDzURQ8Vxcn8Zu+Wn Na26c9DjtRixGs8GH3blnZ8AUyZcBDqgPV4/46lqbsJmeM0VGTeeXYKYv o=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMEABY59lOtJssW/2dsb2JhbABZg2CDU9ElAYEld4QEAQEEI1UBEAsYCRYEBwICCQMCAQIBRQYBDAEHAQERiC2uN5UWF451VweCeYFTAQSTKIFKh1WHLY1dghiBSDuBNoFIAQEB X-IronPort-AV: E=Sophos;i="5.04,374,1406592000"; d="asc'?scan'208";a="148717943" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 21 Aug 2014 18:26:13 +0000 Received: from [10.61.208.203] ([10.61.208.203]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7LIQC19008852; Thu, 21 Aug 2014 18:26:12 GMT Message-ID: <53F639C3.6080809@cisco.com> Date: Thu, 21 Aug 2014 20:26:11 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nico Williams , Stephen Kent References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> <53F4B8D8.2080808@bbn.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lROHRLnACRirI5jIcBtsDvdhAQf6fER8G" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/O1I6SjScaiDOk5_42q7yFF9IsmY Cc: "saag@ietf.org" Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 18:26:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lROHRLnACRirI5jIcBtsDvdhAQf6fER8G Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Nico, On 8/20/14, 10:46 PM, Nico Williams wrote: > [I've been too busy to comment on Stephen K.'s proposed changes, but I > will soon.] > > First, my sense of Stephen K.'s proposed changes is that they don't > change the substance of the draft. I.e., we really are and have been > down to matters of style and wordsmithing. The reason there was a need for such a document in the first place was that people were struggling with terminology in our working groups, starting with the HTTPBIS working group, and the term had been thrown around in other drafts. The crypto folk (you included) were rather put off with the term, OE. Fine. But in as much as we are focusing down on crypto-related stuff (and we are), let's limit the scope of the term to crypto-related stuff. > > Second, OCS is not a good term. I've given my reasons for this before > several times, and if need be I'll repeat them again; I repeat some > below. I'd be grateful if you would send me a pointer off list to the other reasons. > > Third, I'm not a stickler for purity when it comes to terminology > because we already have many conflicts between the protocols in > Internet security space. I'm uncomfortable enough with Viktor's use > of "authenticated encryption" that I second using "authenticated > sessions". > > Back to OS vs OCS vs OE vs any other options: > > - OE is no good: OS denotes more than mere encryption with > unauthenticated key exchange, whereas OE doesn't denote the > possibility of strong authentication. Ok. > > - That OE was used before does NOT bother me. If I didn't have other > reasons to reject OE, I'd take it. Ok. > > - OCS is a bad term because I expect that this document, like many > other RFCs, will bleed into popular culture, and so we need a term > that users can understand. This, I had thought, was Dave's point: who is your audience? In this case I didn't think it was users, but developers, and they darn well ought to understand what the expansion is. And really what is needed by IETF spec writers is a term that can be commonly understood to mean a set of specific practices (or, if you must, a design pattern) they can employ in their drafts. Seems like the draft really does a good job at that. Do you believe users will really understand what a design pattern is? But supposing you are correct that the term does bleed into popular culture (and I suspect you're right): do you want OS to be so narrowly considered, as it is in this document? And again, I like the scope of this document as it is. More text won't help. Worse, I am a little nervous that by catering to users this document will neither be fish nor fowl (meaning it will not be optimal for either users or developers). Eliot --lROHRLnACRirI5jIcBtsDvdhAQf6fER8G Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJT9jnDAAoJEIe2a0bZ0nozAHUH/jgygCBFmra8C9sKblipHi1p y5r3zMieT2uQkXDOsqhS3U/8eb9O8UC6+iZHQ5yPkcfh/6WoISklN9Jn+cu+3CBT ZxIBBsRGh1cRBrccCHcyM+tVY+XJeQsucV2q/IafbG9nZc0n5jSj0d7Ush5so2ul yX6tMDjSA3DxmRJ1jB7xCRnV9tPlyApNAcQX7DiFpGRQw3TjIkxTYI14Ys2n5zhU Wo04pUpbfLxug/dP32pvQiv9tJga/cotCNHYDTApj9u41GgApN0hbFJn2YbfZqj+ ExffNsThBgy2gKsTGhy49nhubXHoLFvZyUO+pCdyXeUBckYnap9DORPVBHFCXJc= =M0jg -----END PGP SIGNATURE----- --lROHRLnACRirI5jIcBtsDvdhAQf6fER8G-- From nobody Thu Aug 21 11:58:35 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A0C1A0745 for ; Thu, 21 Aug 2014 11:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx1uLt9et8sk for ; Thu, 21 Aug 2014 11:58:32 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 72D1E1A06A4 for ; Thu, 21 Aug 2014 11:58:32 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id F3C61163D; Thu, 21 Aug 2014 11:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=iyHhjkn6AFvmTk 3PglfN4BEDNjk=; b=ZUmOTDy3veqwJLTw1zrd43tukVzosTiodIeD9k5mYK0DMB KGTHitCpu3sdGouif5m6BqN2tbYKItXb5L2wcRz+xCBJBZyETjh41KuBTcO+C3PM RXJiHeuluK00dCoOGUxRbs4WSOrpg7zoow4q89MW7y2dysKrVEQxuHNgnqSwY= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id 89E4F1638; Thu, 21 Aug 2014 11:58:31 -0700 (PDT) Date: Thu, 21 Aug 2014 13:58:31 -0500 From: Nico Williams To: Eliot Lear Message-ID: <20140821185829.GN3104@localhost> References: <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> <53F4B8D8.2080808@bbn.com> <53F639C3.6080809@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53F639C3.6080809@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/3RLoL1SOHG1O0JjUsKYcmtOHD70 Cc: "saag@ietf.org" Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 18:58:33 -0000 On Thu, Aug 21, 2014 at 08:26:11PM +0200, Eliot Lear wrote: > > - OCS is a bad term because I expect that this document, like many > > other RFCs, will bleed into popular culture, and so we need a term > > that users can understand. > > This, I had thought, was Dave's point: who is your audience? In this > case I didn't think it was users, but developers, and they darn well Only Internet protocol designers will very likely read the RFC. Implementors will very likely read the RFCs documenting the protocols they implement, which will hopefully describe what to do in those particular protocols' implementations to get OS semantics. They might also read this RFC. Users will be aware of the term though, and -hazily- its semantics, that's my prediction. More than that: I think we'll have a better chance of success if we aim for this, or at least if we don't try to impede it. (Of course, users will most definitely not read the RFC; they never do.) My argument is that OS is a very subtle but significant change in our collective attitude to Internet protocol security, one extremely likely to greatly improve security on the Internet. If that's right then it's also extremely likely to become well known to the public, like SSL/TLS. We need a name and/or acronym that's accessible to the public at large. At the very, very least we need it to be accessible to developers and marketers, not just the IETF in-crowd. We should definitely want users to be somewhat aware of OS: so that they may demand products that support OS. It might be key to OS' success. IMO we cannot ignore potential user awareness of OS. > ought to understand what the expansion is. And really what is needed > by IETF spec writers is a term that can be commonly understood to mean > a set of specific practices (or, if you must, a design pattern) they > can employ in their drafts. [...] OS is a very significant change of attitude for us, so much so as to deserve a name and doc of its own. > [...]. Seems like the draft really does a good > job at that. [...] Eh? How? It captures one concept, not a set of good security practices. Or did I miss that? > [...]. Do you believe users will really understand what a > design pattern is? But supposing you are correct that the term does Indeed, no way. But they'll understand a marketing term. They know to look for "SSL" and "TLS". We should want them to know to look for "OS". > bleed into popular culture (and I suspect you're right): do you want > OS to be so narrowly considered, as it is in this document? And Yes, I do. I'm open to that being ill-considered on my part, but remember: the public has become quite aware of security failures. Shouldn't we want the public to become aware of security successes?? > again, I like the scope of this document as it is. More text won't > help. You're just down to debating the name then? > Worse, I am a little nervous that by catering to users this document > will neither be fish nor fowl (meaning it will not be optimal for either > users or developers). This is true, but the document isn't catering to users. The _name_ is catering to users: that's as much as we can hope they'll know, with a minimum of its semantics -- semantics which the name, short as it must be, had better denote to some degree... Nico -- From nobody Thu Aug 21 12:20:48 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D061A89E8 for ; Thu, 21 Aug 2014 12:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRAaLYa3cmyI for ; Thu, 21 Aug 2014 12:20:44 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E6431A89E6 for ; Thu, 21 Aug 2014 12:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1096; q=dns/txt; s=iport; t=1408648844; x=1409858444; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=DudYSmtEz6vhF1yezkaGxuC7/b/GoTw2YVDi5Idsvwo=; b=VI3bUXudpJ4iI6QB5cM6QjuiGqtvpqn0tQQoRbRMQhiOBnA0Wl6lnpfk GW/htWUYVbOG1mKqcFw08TxAy7IBMtFhq2QX5zZFS2tsp5SyVQ+wTEeRX 9WI/g3iJmaqLys6mHSNnEeDdOMYYsRUq/dlkJW5o/EGVSoNRqIqaEFpHt Y=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0GALNF9lOtJssW/2dsb2JhbABZhzOKQMZnAYEld4QEAQEEI1UBEAsYCRYEBwICCQMCAQIBRQYNAQcBAYg+rkeVGhePTAeCeYFTAQSTKIFKh1WHLY1dghiBSDuCfgEBAQ X-IronPort-AV: E=Sophos;i="5.04,374,1406592000"; d="asc'?scan'208";a="149410789" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 21 Aug 2014 19:20:40 +0000 Received: from [10.61.208.203] ([10.61.208.203]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7LJKeUH008304; Thu, 21 Aug 2014 19:20:40 GMT Message-ID: <53F64687.2070204@cisco.com> Date: Thu, 21 Aug 2014 21:20:39 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nico Williams References: <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> <53F4B8D8.2080808@bbn.com> <53F639C3.6080809@cisco.com> <20140821185829.GN3104@localhost> In-Reply-To: <20140821185829.GN3104@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qnjrtEOfhkJdHiSKw6DouOlDmhRrUwHD6" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/oCfZm1HXxo_hTlkcu67785J-Hxo Cc: "saag@ietf.org" Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 19:20:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qnjrtEOfhkJdHiSKw6DouOlDmhRrUwHD6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/21/14, 8:58 PM, Nico Williams wrote: > You're just down to debating the name then? Somewhat yes, because that was how all of this started. Eliot --qnjrtEOfhkJdHiSKw6DouOlDmhRrUwHD6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJT9kaHAAoJEIe2a0bZ0nozMYcH/A2dX6kFNzQjyWKSFmE373MV h7nEccAZwWh5waxH/FCjHB2boQUPVah8LWh1QkTWtJBjg7B7C2O6IcAb+3aVMd/E G4WPxYu/KvKYX0w1lqMh4gflhF2TWz7GK2A+Ji0t10JjnFSXeViLDYqw6L+GEsAL VhTfFWd6GC3rFtJoCLSiQvC03LrHl8jJscWJAysJrrAOJcNstZqveBTMQxX4dJw8 5YdNxpamvQYrOp4K4Uq3xMUp/L4w0xxWrExiF3D3oOBuN8FjZgUSCwbFEoNN32nD xhV3RNuuHaMkVsaJqlf2ncDVpBArYcAXzwD4x9C7iv9PHeZZ91Eq159vj6pvF7o= =IZO0 -----END PGP SIGNATURE----- --qnjrtEOfhkJdHiSKw6DouOlDmhRrUwHD6-- From nobody Thu Aug 21 12:33:56 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5F01A067A for ; Thu, 21 Aug 2014 12:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NGi4j-TfqVE for ; Thu, 21 Aug 2014 12:33:54 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EC6741A87DE for ; Thu, 21 Aug 2014 12:33:51 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id A14EF594069; Thu, 21 Aug 2014 12:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=pJKxD1BK2nWE9n gOm1L9Z4qXhTE=; b=NUOc0Oi2BlazujwvXYoM0LrcDZFDutXG6vCV0aFY/9gFSg bFzpyvcsUdCZmz6ZwXXkO6Y4HSDMuqKFzeDwyfUAKBX/Peip4LKvsYaGVVFPgd0K 2L9YGe/urDGV3x3FbDo8RngiXqNPyAtiIgAoDZ1+yzjr745dxrA0LtREs7oE4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPA id 46BD7594061; Thu, 21 Aug 2014 12:33:51 -0700 (PDT) Date: Thu, 21 Aug 2014 14:33:50 -0500 From: Nico Williams To: Eliot Lear Message-ID: <20140821193348.GQ3104@localhost> References: <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> <53F4B8D8.2080808@bbn.com> <53F639C3.6080809@cisco.com> <20140821185829.GN3104@localhost> <53F64687.2070204@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53F64687.2070204@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/CP2d5wMnBLITgRXf6IZd7qSjsu0 Cc: "saag@ietf.org" Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 19:33:55 -0000 On Thu, Aug 21, 2014 at 09:20:39PM +0200, Eliot Lear wrote: > On 8/21/14, 8:58 PM, Nico Williams wrote: > > You're just down to debating the name then? > > Somewhat yes, because that was how all of this started. That's progress. It took a long time to get to agreement on the substance of Viktor's proposal. There's a lot to naming. We must choose carefully, no doubt. I'm quite convinced that we won't find a better term. We've tried so many variants... That alone is strong evidence that we're likely not going to please everyone. I know I've been a bit forceful as to the name, but really, if you find a better term, I'll be all for it. But so far every name pitched has failed to be better than OS. Back when we first discussed this I made a list of many possible names and pitched them to friends and family. None was great, but OS seemed like the best name, and when explained they seemed to get it. If we really want a better name then we should repeat that exercise, but more scientifically (standard questionnaire and polling procedures, larger sample size + some record keeping). It'd mean a significant delay, but given how long we've been debating it, and how much longer we could continue to, it might be no big deal. Have we ever done something like that?? I would rather we didn't run a scientific poll _now_. I proposed it a while back and no one said peep. Who would run the poll? We're volunteers, with limited resources... Nico -- From nobody Thu Aug 21 22:25:30 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFE21A0040; Thu, 21 Aug 2014 22:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEWkiV3LBVGa; Thu, 21 Aug 2014 22:25:23 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.107]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436B21A002A; Thu, 21 Aug 2014 22:25:23 -0700 (PDT) Received: from [193.109.255.147:31914] by server-3.bemta-14.messagelabs.com id FF/5A-23707-144D6F35; Fri, 22 Aug 2014 05:25:21 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-15.tower-72.messagelabs.com!1408685121!14385698!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19435 invoked from network); 22 Aug 2014 05:25:21 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-15.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 22 Aug 2014 05:25:21 -0000 Received: from EXHY021V.surrey.ac.uk (131.227.200.104) by EXHT022P.surrey.ac.uk (131.227.200.43) with Microsoft SMTP Server (TLS) id 8.3.342.0; Fri, 22 Aug 2014 06:25:20 +0100 Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.200.4) by email365.surrey.ac.uk (131.227.200.104) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 22 Aug 2014 06:25:20 +0100 Received: from AMSPR06MB438.eurprd06.prod.outlook.com (10.242.23.15) by AMSPR06MB357.eurprd06.prod.outlook.com (10.242.20.139) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Fri, 22 Aug 2014 05:25:19 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB438.eurprd06.prod.outlook.com (10.242.23.15) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Fri, 22 Aug 2014 05:25:17 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.1010.016; Fri, 22 Aug 2014 05:25:17 +0000 From: To: , Thread-Topic: Adept Encryption: Was: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) Thread-Index: AQHPvMP2AuxVJ2IG8ESWBidoQO1Q3JvaPakAgAAEcICAAAdoAIAAnT6AgAAVZQCAAD1gAIAA3ylN Date: Fri, 22 Aug 2014 05:25:17 +0000 Message-ID: References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> , <20140821160402.GT14392@mournblade.imrryr.org> In-Reply-To: <20140821160402.GT14392@mournblade.imrryr.org> Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.200.59.30] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199003)(51704005)(377454003)(24454002)(53474002)(66066001)(15202345003)(15198665003)(77982001)(15395725005)(19580395003)(76576001)(50986999)(21056001)(2656002)(4396001)(83322001)(99396002)(81542001)(19580405001)(76482001)(87936001)(93886004)(107046002)(79102001)(64706001)(106116001)(74502001)(33646002)(54356999)(80022001)(76176999)(31966008)(85852003)(15975445006)(74482001)(85306004)(20776003)(108616004)(101416001)(83072002)(81342001)(95666004)(106356001)(46102001)(107886001)(105586002)(86362001)(74662001)(74316001)(92566001)(90102001)(2501001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB438; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB438.eurprd06.prod.outlook.com X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: surrey.ac.uk X-CrossPremisesHeadersPromoted: EXHY021v.surrey.ac.uk X-CrossPremisesHeadersFiltered: EXHY021v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/saag/63YgiOgjatSzbr-N5v_o_9zKZjo Subject: Re: [saag] Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 05:25:26 -0000 Okay, so with opportunistic security, all a man in the middle has to do is = block any communications he can't decrypt, and it automatically downgrades = to select something he can break? Ah, there's the opportunity. Got it. Lloyd Wood http://about.me/lloydwood ________________________________________ From: ietf on behalf of Viktor Dukhovni Sent: Friday, 22 August 2014 2:04:02 AM To: ietf@ietf.org; saag@ietf.org Subject: Re: Adept Encryption: Was: [saag] DANE should be more prominent (R= e: Review of: Opportunistic Security -03 preview for comment) On Thu, Aug 21, 2014 at 08:24:22AM -0400, Phillip Hallam-Baker wrote: > > There are quite a few substantive threads on it, I think > > the first goes back on March 6th this year started by PHB. [1] > > > > [1] https://www.ietf.org/mail-archive/web/saag/current/msg04604.html > > And in that message PHB presciently wrote: Yes, thanks for that message, it got the ball rolling. > "There are arguments for all of these but I am just watching a > presentation on 'opportunistic encryption' in DANE and I think the > term is selling DANE short. The reasons why that's not the case were explained and we are now defining what it means for DANE to be used opportunistically. It can also be used for mandatory authentication just for the key management part. TLS can likewise be used for sessions with mandatory encryption and authentication, or as "opportunistic TLS" with SMTP. Neither DANE nor TLS are opportunistic or not, they are just tools that can be used in multiple ways. > DNS is an authoritative path for statements about DNS labels. Ergo > authenticated DNS RRs are authenticated statements about them. Correct, and this is precisely why DANE/DNSSEC can be used to securely discover which peers have published TLSA RRs and can be authenticated. The existence of an authenticated out-of-band (relative to the application protocol) mechanism for publishing capabilities[*] is what makes it possible to employ opportunistic DANE TLS. What's opportunistic is still the use of TLS (with DANE providing a downgrade resistant commitment to "STARTTLS" and key material to enable authentication). * Yes OS protocols can overload TLSA RRs as a capability to employ TLS *with* authentication. > DANE > provides authenticated statements about security policy and keys. Ergo > DANE cannot support opportunistic encryption because it is policy > directed encryption (i.e. better)." But the keys are not always there, in fact currently for SMTP, I know of ~32 domains with published TLSA RRs for their MX hosts, and that's probably accurate to within a factor of 10 or so. So from the perspective of an MTA, TLS with DANE is very much opportunistic. * Look up MX RRset. If not DNSSEC "secure", back to plain opportunistic STARTTLS for all MX hosts. * For each MX host (sorted by priority in the usual way) look up up A/AAAA RRset, if not DNSSEC "secure", back to plain opportunistic STARTTLS for that MX host. * Look up TLSA RRset, unless present and DNSSEC "secure", back to plain opportunistic STARTTLS for that host. * If all TLSA RRs are unusable, require STARTTLS encryption, without authentication (since no usable authentication keys available). * If some TLSA RRs are usable, require STARTTLS encryption, with authentication. The above is done for each peer domain, and for each peer MX host. What is opportunistic is the use of possibly authenticated TLS, with out-of-band signally via DANE enabling downgrade-resistant authentication. > With all due respect [1], I don't think this effort is helping the > goal of getting encryption deployed and used. On Sun, Aug 17, 2014 at 11:20:26 -0400, Phillip Hallam-Baker wrote off-list= : > On Sat, Aug 16, 2014 at 11:17 PM, Viktor Dukhovni w= rote: > > On Sat, Aug 16, 2014 at 11:13:23PM -0400, Phillip Hallam-Baker wrote: > > > >> DANE isn't opportunistic security. It is authenticated security policy > >> and keys. Thats the opposite of opportunistic. > > > > Have you read the draft? DANE can be "opportunistically employed", > > when TLSA records are present, and not when they are absent. > > While DANE is not opportunistic per-se, a protocol employing it, > > for example: > > > > http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-11 > > > > sure is. This statement suggests you've either not read the draft, > > or just skimmed it. It is also possible that my explanation of this > > is too obtuse, in which case please help me polish it, or at least > > chime in on the need for me or others to spell this out in more > > detail, e.g. in the SMTP example at the end of the draft. > > Draft, schmaft. > > Opportunistic encryption is a pre-existing term of art. If the draft > is causing people to get confused about what opportunistic encryption > is then it should not be published. Have you read either draft yet? We're not even defining "opportunistic encryption". We're defining "opportunistic security", which is not surprisingly a broader term. > We have a collection of policy inputs: > > * The https URI prefix means 'use http over TLS' That is mandatory local policy (based on HTTPS URI semantics), and OS is out of scope. OS is in scope for SMTP, IMAP, XMPP, and HTTP where no explicit security mandate is in force. > * Presence of a DANE record means 'use TLS with key matching these criter= ia' If this in the context of an "HTTPS" URI, then the use of DANE key management for mandatory authentication is out of scope for the OS draft. > * Protocol headers can be defined to mean 'use TLS' > * Manual user config OS is about selecting a mutually supported set of security mechanisms, even if that sometimes results in less than complete cryptographic protection or even cleartext. > So pragmatic security means 'act on the best available intel'. Well, at least we largely agree on the substance. If your object is just to the term, please send your thoughts off-list to Stephen Farrell, he'll presumably let us how the rough consensus worked out. > Using the terms 'opportunistic security' does not help because I am > not interested in opportunistic security except as a last resort. Whichever term we choose will mean exactly the same thing, with different words. So it makes no sense to presume that OS means something other than your suggested term of "pragmatic security", they are one and the same. We're just choosing the term. > I don't expect an RFC titled 'last resort kinda rubbish security' to be > giving me advice relevant to anything other than last resort > situations. Good thing that's not the phrase we're proposing. :-) -- Viktor. From nobody Thu Aug 21 22:35:08 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA2B1A0047; Thu, 21 Aug 2014 22:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzfs4zMR02nq; Thu, 21 Aug 2014 22:35:05 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E621A004B; Thu, 21 Aug 2014 22:35:05 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2DF282AB2BB; Fri, 22 Aug 2014 05:35:04 +0000 (UTC) Date: Fri, 22 Aug 2014 05:35:04 +0000 From: Viktor Dukhovni To: ietf@ietf.org, saag@ietf.org Message-ID: <20140822053503.GD14392@mournblade.imrryr.org> References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <20140821160402.GT14392@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/fpmJLb4OYkk5csDsEc7R4p_QAdc Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 05:35:07 -0000 On Fri, Aug 22, 2014 at 05:25:17AM +0000, l.wood@surrey.ac.uk wrote: > Okay, so with opportunistic security, all a man in the middle > has to do is block any communications he can't decrypt, and it > automatically downgrades to select something he can break? And without OS, he need not do anything at all, because the vast majority of the traffic is cleartext. However OS can support downgrade resistant modes of operation, given appropriately secure out-of-band signalling, (possibly DANE/DNSSEC). OS is not an effort to displace already working authenticated encrypted traffic. Rather, it is an effort to upgrade currently unencrypted traffic to encryption or currently unauthenticated traffic to authentication. Hence, "Opportunistic TLS" with SMTP for the former, and "Opportunistic DANE TLS" with the latter. You can point fingers at the shabby clothing of the OS emperor, but at least he's not naked. -- Viktor. From nobody Thu Aug 21 22:42:22 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49AE21A004B; Thu, 21 Aug 2014 22:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqgoaCG7lFlK; Thu, 21 Aug 2014 22:42:17 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AA4031A0047; Thu, 21 Aug 2014 22:42:17 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 4BB072005D82E; Thu, 21 Aug 2014 22:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=bz5t2ICwes7GEuLAmTSS gSr242g=; b=johY4HwBQiBZPZkp8M+xJ7PNYwboueawXE5g46eV31Cm/L7CZTF1 /ezaatUFT+oJH/wq8XIAzwcMgD4pgcc/P2Lk/0aQoXnAiAcOitA8x7U+ci/utfCD i1zCNMGMlP+uWmOwS/YnCSSVhXzUYdt87d8pwPsrOPXYRFc/eXAzSFU= Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPSA id CB9CB2005D807; Thu, 21 Aug 2014 22:42:16 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id z12so9917355wgg.0 for ; Thu, 21 Aug 2014 22:42:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.71.11 with SMTP id q11mr2882723wju.33.1408686135515; Thu, 21 Aug 2014 22:42:15 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Thu, 21 Aug 2014 22:42:15 -0700 (PDT) In-Reply-To: References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <20140821160402.GT14392@mournblade.imrryr.org> Date: Fri, 22 Aug 2014 00:42:15 -0500 Message-ID: From: Nico Williams To: l.wood@surrey.ac.uk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_a4CMb-x9SKASHP6LbUqFW5erJY Cc: "ietf@ietf.org" , "saag@ietf.org" Subject: Re: [saag] Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 05:42:18 -0000 On Fri, Aug 22, 2014 at 12:25 AM, wrote: > Okay, so with opportunistic security, all a man in the middle has to do is block any communications he can't decrypt, and it automatically downgrades to select something he can break? > > Ah, there's the opportunity. Got it. Eh? The idea is to be downgrade resistant. Nico -- From nobody Fri Aug 22 01:11:56 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D311A013B; Fri, 22 Aug 2014 01:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnKXJtdt_kej; Fri, 22 Aug 2014 01:11:42 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.151]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409A91A0119; Fri, 22 Aug 2014 01:11:42 -0700 (PDT) Received: from [195.245.231.67:10515] by server-15.bemta-5.messagelabs.com id CA/73-12002-C3BF6F35; Fri, 22 Aug 2014 08:11:40 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-16.tower-82.messagelabs.com!1408695100!36477570!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26489 invoked from network); 22 Aug 2014 08:11:40 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-16.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 22 Aug 2014 08:11:40 -0000 Received: from EXHY022V.surrey.ac.uk (131.227.201.104) by EXHT022P.surrey.ac.uk (131.227.200.43) with Microsoft SMTP Server (TLS) id 8.3.342.0; Fri, 22 Aug 2014 09:11:39 +0100 Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.201.241) by EXHY022v.surrey.ac.uk (131.227.201.104) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 22 Aug 2014 09:11:39 +0100 Received: from AMSPR06MB440.eurprd06.prod.outlook.com (10.242.23.24) by AMSPR06MB487.eurprd06.prod.outlook.com (10.242.107.23) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Fri, 22 Aug 2014 08:11:39 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB440.eurprd06.prod.outlook.com (10.242.23.24) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Fri, 22 Aug 2014 08:11:38 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.1010.016; Fri, 22 Aug 2014 08:11:38 +0000 From: To: Thread-Topic: [saag] Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) Thread-Index: AQHPvcvYIIfE//9+y0SvQmMnMSntCJvcRM5z Date: Fri, 22 Aug 2014 08:11:38 +0000 Message-ID: References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <20140821160402.GT14392@mournblade.imrryr.org> , In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [124.170.214.211] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(24454002)(199003)(51704005)(189002)(19580405001)(4396001)(86362001)(85306004)(79102001)(92566001)(108616004)(21056001)(106356001)(83322001)(64706001)(33646002)(46102001)(74316001)(77982001)(15975445006)(83072002)(90102001)(19580395003)(99396002)(2656002)(80022001)(50986999)(66066001)(107046002)(93886004)(20776003)(74482001)(101416001)(81342001)(15395725005)(31966008)(81542001)(15198665003)(106116001)(76576001)(85852003)(76176999)(87936001)(74662001)(54356999)(76482001)(105586002)(74502001)(95666004)(110136001)(15202345003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB440; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB440.eurprd06.prod.outlook.com X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-CrossPremisesHeadersFiltered: EXHY022v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/saag/0SLn5wmP4drKyYV53l8nLhDMh5I Cc: ietf@ietf.org, saag@ietf.org Subject: Re: [saag] Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 08:11:45 -0000 no, it's at encyption above a baseline. assume mitm can't crack maximum lev= el,,but can crack baseline and above. if maximum can't be negotiated becaus= e mitm prevents it , and less is settled for... well. may as well have fall= en back to clear. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Nico Williams Sent: Friday, 22 August 2014 3:42:15 PM To: Wood L Dr (Electronic Eng) Cc: ietf@ietf.org; saag@ietf.org Subject: Re: [saag] Adept Encryption: Was: DANE should be more prominent (R= e: Review of: Opportunistic Security -03 preview for comment) On Fri, Aug 22, 2014 at 12:25 AM, wrote: > Okay, so with opportunistic security, all a man in the middle has to do i= s block any communications he can't decrypt, and it automatically downgrade= s to select something he can break? > > Ah, there's the opportunity. Got it. Eh? The idea is to be downgrade resistant. Nico -- From nobody Fri Aug 22 07:00:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553D61A0438; Fri, 22 Aug 2014 07:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAOONjFMdwWx; Fri, 22 Aug 2014 07:00:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC241A03FE; Fri, 22 Aug 2014 07:00:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1CDDF2AB173; Fri, 22 Aug 2014 14:00:01 +0000 (UTC) Date: Fri, 22 Aug 2014 14:00:01 +0000 From: Viktor Dukhovni To: ietf@ietf.org, saag@ietf.org Message-ID: <20140822140000.GE14392@mournblade.imrryr.org> References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <20140821160402.GT14392@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Gu2cjsSrmKMt7MfrRKZfdFDReJA Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 14:00:11 -0000 On Fri, Aug 22, 2014 at 08:11:38AM +0000, l.wood@surrey.ac.uk wrote: [ top-post rearranged ] > Nico wrote: > > > On Fri, Aug 22, 2014 at 12:25 AM, wrote: > > > > > Okay, so with opportunistic security, all a man in the middle > > > has to do is block any communications he can't decrypt, and it > > > automatically downgrades to select something he can break? > > > > > > Ah, there's the opportunity. Got it. > > > > Eh? The idea is to be downgrade resistant. > > no, it's at encyption above a baseline. assume mitm can't crack > maximum level,,but can crack baseline and above. if maximum can't > be negotiated because mitm prevents it , and less is settled for... > well. may as well have fallen back to clear. For the record: OS is primarily about high level security mechanism selection (cleartext, passive-only, active and passive protection). The draft says deliberately little about the fine details of crypto handshakes, which may or may not support a range of ciphers and will typically do exactly the same thing when used opportunistically in an OS protocol as otherwise. For example, I don't see TLS changing to become opportunistic. Rather I see higher level application protocols that can employ TLS using it opportunistically when previously they might have sent in cleartext. (Vocabulary point I try to keep straight, "plaintext" is input to encryption, or output of decryption, while "cleartext" is unecrypted content on the wire). OS does not impact the active attacker's ability to tamper with unathenticated communication. However, OS encourages authentication: * Any currently protected traffic remains protected, OS does not trump existing policy that mandates comprehensive security. For example, opportunistic security for HTTP does not downgrade HTTPS, all it does is upgrade HTTP to resist passive and perhaps some day with some peers also active attacks. * OS suggests that it is a good idea to employ downgrade resistant mechanisms to discover which peers can be authenticated, and then authenticate those peers. It used to be easy to dismiss opportunistic security as a waste of time, it is now clear to most that it is not. -- Viktor. From nobody Fri Aug 22 07:13:38 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253AB1A0417; Fri, 22 Aug 2014 07:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrU_ft2wh8As; Fri, 22 Aug 2014 07:13:30 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539531A02E2; Fri, 22 Aug 2014 07:13:30 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 05A5582E12; Fri, 22 Aug 2014 10:13:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1408716809; bh=DSkBMlyXAOsZ1j5lPVaiLFopSreHkePTX8Yqt23zWys=; h=Date:From:To:Subject:In-Reply-To:References; b=aOFyjavQy7BRZDDMuQKW669IlxG1E9X0u0kW30eAxJmcY3VkI1iD9WxRwn2BlU2C8 XfF99QR4Rci1BUWtEAB7vnLzUN8fmtdwN6CpeKE//XJwPRTWE1jNcp1r5EEZRIsGuE kVGDj5C8AlaghWzSHnKIklwBBCnY70ISLZLSVWJo= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s7MEDSng030259; Fri, 22 Aug 2014 10:13:28 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 22 Aug 2014 10:13:28 -0400 (EDT) From: Paul Wouters To: saag@ietf.org, ietf@ietf.org In-Reply-To: <20140822053503.GD14392@mournblade.imrryr.org> Message-ID: References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <20140821160402.GT14392@mournblade.imrryr.org> <20140822053503.GD14392@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/BNPWADH2a-5uuQrldfSuyeRV27I Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 14:13:32 -0000 On Fri, 22 Aug 2014, Viktor Dukhovni wrote: > On Fri, Aug 22, 2014 at 05:25:17AM +0000, l.wood@surrey.ac.uk wrote: > >> Okay, so with opportunistic security, all a man in the middle >> has to do is block any communications he can't decrypt, and it >> automatically downgrades to select something he can break? > > And without OS, he need not do anything at all, because the vast > majority of the traffic is cleartext. However OS can support > downgrade resistant modes of operation, given appropriately secure > out-of-band signalling, (possibly DANE/DNSSEC). > > OS is not an effort to displace already working authenticated > encrypted traffic. What this little exchange above here shows is that people involved in this dicsussion _still_ don't know whether "OS" is just the anonymous crypto or whether includes the "design pattern recommendation advise" of using authenticated encryption if available. If the people who agree to "just publish it" cannot even keep their usage straight, I'd say the document needs more work..... Paul From nobody Fri Aug 22 07:18:29 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69631A0488 for ; Fri, 22 Aug 2014 07:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7EXIGaAHUvy for ; Fri, 22 Aug 2014 07:18:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6461A041D for ; Fri, 22 Aug 2014 07:18:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 02142BEF3 for ; Fri, 22 Aug 2014 15:18:02 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytvwOUWgvx_b for ; Fri, 22 Aug 2014 15:18:01 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AA6D3BF37 for ; Fri, 22 Aug 2014 15:18:01 +0100 (IST) Message-ID: <53F7511A.1090306@cs.tcd.ie> Date: Fri, 22 Aug 2014 15:18:02 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <53F733DC.5010507@cs.tcd.ie> In-Reply-To: <53F733DC.5010507@cs.tcd.ie> X-Forwarded-Message-Id: <53F733DC.5010507@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/sKHBZl0XWdHI7xEIdYuCdEV_po8 Subject: [saag] Fwd: Re: Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 14:18:14 -0000 FYI, for any folks who are only subscribed to/read saag. I think we've had a good discussion and the next step is for the IESG Thanks, S. -------- Forwarded Message -------- Subject: Re: Adept Encryption: Was: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) Date: Fri, 22 Aug 2014 13:13:16 +0100 From: Stephen Farrell To: Christian Huitema , dcrocker@bbiw.net CC: IETF Discussion Mailing List Hi Christian, On 21/08/14 20:23, Christian Huitema wrote: > Viktor's draft is basically fine. It is short and clear. The various > rounds of edits tend to make it "different," but not better. IMHO, it > is time to ship it. I think your mail is a good summary though perhaps it doesn't catch all of the concerns that Dave expressed. In particular he also had a concern that we may be addressing the wrong target audience. However, there was no significant discussion of that when I kicked off a thread so I conclude that others don't share that concern. All that said, I agree with your conclusion that we risk going more sideways than forward with additional iteration. Right now, Viktor is preparing a -04 taking into account list discussion on -03 and the substantial editorial inputs from Steve Kent and Ben Kaduk. Barring late surprises, my plan is to put that into IESG evaluation as I conclude we have reached rough consensus on the concepts here. For who are those interested, I plan to add the saag list to the cc for IESG evaluation comments/discuss points so you'll be able to follow along there as the IESG consider this draft. That'll probably happen in the run up to the Sep 4th IESG telechat, or maybe the one on Sept 18th, depending. And lastly, thanks to everyone for the engaging discussion. Cheers, S. > > -- Christian Huitema > > > > From nobody Fri Aug 22 08:04:40 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B151A0383 for ; Fri, 22 Aug 2014 08:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ToeueIEpbEO for ; Fri, 22 Aug 2014 08:04:36 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D426B1A0330 for ; Fri, 22 Aug 2014 08:04:36 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id B71986D621; Fri, 22 Aug 2014 11:04:31 -0400 (EDT) Message-ID: <53F73271.3040900@iang.org> Date: Fri, 22 Aug 2014 13:07:13 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> <53F4B8D8.2080808@bbn.com> In-Reply-To: <53F4B8D8.2080808@bbn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/EEnFs3ysPTzkASfMdLtlPGPIIV0 Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 15:04:38 -0000 On 20/08/2014 16:03 pm, Stephen Kent wrote: > Ben, > > You noted my use of the phrase "Opportunistic Crypto-Secruity" instead > of "Opportunistic Secruity." > I made the change after someone else suggested it as a more precise > description of what we're > doing, It's not more precise, it's either a distinction of no difference or a mistake. What we are doing is Opportunistic Security. That is, we are securing the users' interests using an opportunistic approach. We are then applying this approach to protocols. Now, obviously, when we are doing protocols, most security ends up being crypto in nature. So in this sense of high-level viewpoint, the distinction is no distinction, OS is crypto-security. But, at a more detailed level, this simplification is reversed: sometimes we come across a technique that isn't crypto-related. For example, TOFU. This is based on the limited time/space window, the knowledge of the human operators, and the economics of attacking every possibility all the time. TOFU is not crypto, yet it is OS. So, by saying crypto-security we are in danger of eliminating one of our best and most successful techniques [0]. And, as we are talking opportunistically, we indeed want to not be so prejudicial. We'll take a benefit where we find it. > and because it has the advantage of being represented by an > acronym that isn't so common > (OCS vs. OS) in our arena. Yeah, overloading is a nice to avoid, but not essential. How about opp-sec? Of if someone points out a clash with operational security, then oppo-sec. Frankly, I don't think that is important. In any field of such breadth, we have to deal with overloading of terms. iang [0] If one believes the words matter. From nobody Fri Aug 22 08:04:45 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3051A03AE for ; Fri, 22 Aug 2014 08:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_lh3OJhGmza for ; Fri, 22 Aug 2014 08:04:40 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C50B1A0330 for ; Fri, 22 Aug 2014 08:04:40 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 2DCA06D621; Fri, 22 Aug 2014 11:04:37 -0400 (EDT) Message-ID: <53F73AFE.9080706@iang.org> Date: Fri, 22 Aug 2014 13:43:42 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> <53F41581.2030508@dcrocker.net> <53F56802.9080907@dcrocker.net> In-Reply-To: <53F56802.9080907@dcrocker.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/1sR85R37Gp5M0qCsqBazTHXG46Y Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 15:04:42 -0000 On 21/08/2014 04:31 am, Dave Crocker wrote: > On 8/20/2014 10:42 AM, Benjamin Kaduk wrote: >> On Tue, 19 Aug 2014, Dave Crocker wrote: >>> Note that I offered some citations for the term, a day or three ago, > ... >> I saw those. I concluded that the online search used to find them was >> finding results for an unrelated topic, and that more accurate search did > > That's fine, but the alternatives you found really do not look any more > satisfying. > > Remember that the claim was that the term was in common use. Again, if > it is so common, online explanations should be readily available. Yet > there aren't. Pattern or design pattern is a term that has been in use for at least 15 years to my knowledge. It is a subtle term, and I can understand that there might not be good definitions. I suspect the definition is a little pointless because without a good understanding of the concept of design patterns, any definition isn't meaningful. Which is to say that the way to understanding is to learn several design patterns and then triangulate backwards to the meaning of the term. For those who find this unsatisfactory, oh well. The language works that way, learning works that way, human nature is, and our use of the common term is far more important than finding a definition. > My guess is that folk are confusing the common term "design pattern" > with "protocol design pattern". The former is a nice innovation of > perhaps 30+ years ago, but it's a very general concept. The latter has > little or no established use, I believe, and the lack of online examples > encourages this view. Perhaps it makes more sense expressed as "design pattern for protocols" ? Otherwise I can't see the confusion here. > Any online use that is close, isn't all that close. > > >> My implied assertion was that this term is used by textbooks used for >> undergraduate CS classes. > > We are not in a CS class. If the term is in common use, it will be in > use beyond classrooms and textbooks. > > In any event, the current draft needs to explain the term well enough > for the reader to know what it means, Disagree. It may be someone's job to explain all the words that we might use. But the English language is descriptive; we use the words and then later on the wordsmiths come in and hammer out their meaning in committee. They get to do that at their leisure, and we get to the words at our pleasure, including the joy of making new words on the fly. It is not the job of this draft to define every word in common use, nor the conjunction of two common terms 'protocol' and 'design pattern' just as it isn't the job of this draft to define MUST or 'is'. > just as it needs to define the > 'protocol design pattern' 'os'. It doesn't do that, either. Granted, we may want to define the term 'os'. That's harder. Mostly it is harder because like all patterns we want to define it by explaining some common examples, *but* also we don't want to get dragged into too many examples, nor to get dragged into the minute detail and religious warfare that is typically attendant. We need a helicopter view, and we may end up describing it rather than defining it. I believe that's acceptable to readers, YMMV. >>> More significantly, please note Steve Kent's observation that there is >>> little obvious need for this specialized term in this draft, especially >>> since the use of the term 'design pattern' in the draft is not >>> well-defined nor all that meaningfully used. >> >> To me, the meaning of the term is self-evident: we are attempting to > > To you, perhaps. The next reader might think the same thing, but wind up > applying a different meaning. > > Again, this document is supposed to be a specification. (A definition is > a form of specification.) Specifications do not make assumptions, > especially when the readership is highly diverse in training, culture > and primary language, as it very much is in the IETF and the rest of the > Internet. Well, that's wrong then! One cannot "specify" opportunistic security. It's an approach that can be employed, by its very nature it defies specification because it defies measurement; it'll take the non-opportunistic successful method as much as deliver nothing. So maybe the IETF process for 'specifications documents' is simply the wrong path. Oh well. Do we care? Better to have the document out there so we can start to slay some of the policy dragons and model gremlins than to pass yet another burdensome and inappropriate bureaucratic hurdle... > Once again, to the extent that the phrase 'protocol design pattern' is > essential, it needs to be defined carefully and practically. The draft > does not do it. The term is not essential. It's just a really good descriptive term for that community that has it. If you grok the two, it comes together naturally. If not, well, apologies, but let's move on... > Also again, the draft is supposedly defining 'os' as a design pattern > but never specifies the detailed characteristics of that pattern. So > there is no way to tell in the future which protocols fall within the > design patterns and which do not. It's a way of thinking that we need to put out there. The last thing we want to do is ontologise the successes and give people gold stars for their prescriptive delivery. ... > In contrast, the opp-sec draft uses the term 'design pattern' but > does not invoke or define what that means, substantively, nor explain > pattern is being used. Nor is the use of the term used all that > meaingfully or consistently in the document. as above... > And 'os' is being defined as a /new/ pattern, but has no description > anywhere near as clear and concise as what is in the CoAP draft. OS is perhaps a new approach to IETF. Outside IETF, no, the approach has been in use for decades. If one needs a basis for that, one could look at risk analysis and risk taking behaviour of people, well studied in psych and finance. SSH and Skype celebrated the approach. The term itself isn't so common mostly because people just do it, it might be that the term is in a 'coming of age' transition and we haven't noticed until now, like NoSQL. .... > And its essential point about this is that the term 'protocol design > pattern' is not essential to this draft. It become just another term > tossed in, without being used productively. Perhaps. People who understand the two terms will instantly see where we are heading. People who don't, won't. >> Perhaps we can break down the term, which (again, to me) divides naturally >> into (protocol) + (design pattern). That. ... > Encryption w/ or w/out authentication is the real topic of immediate > concern, is the concrete topic of discussion in the draft, and is (IMO) > entirely sufficient to justify the document. > > So the real problem (IMO) is a scope creep infection that is affecting > folks' vision. Well. Encryption is the need of choice for PM, but the approach that will put it into play is OS. Calling it OS isn't scope creep because encryption without an opportunistic security context isn't going to mitigate the threat (or, didn't for the recent history). > The document does not need to do a better job of explaining the > applicability of the 'pattern' for security functions other than > encryption. I would have thought it quite reasonable to explain the applicability of the pattern by describing example(s) in encryption. ... > .... Perhaps some debate about nuances (eg, does TOFU qualify as an > acceptable example of authenticated encryption) but nothing major. As the draft is about OS not AE, asking whether TOFU qualifies as AE should be out of scope. iang From nobody Fri Aug 22 10:57:46 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CA21A06D5 for ; Fri, 22 Aug 2014 10:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7qL4OsGIasF for ; Fri, 22 Aug 2014 10:57:42 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 435DB1A06AD for ; Fri, 22 Aug 2014 10:57:36 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id DC3AB20058D80 for ; Fri, 22 Aug 2014 10:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=qIOA8hFQXPZrzYn2bP9j 7Pxb4a8=; b=ZzyGboiu/pI4yTz2xWw++HxPvgI45WTjVwVaaly5NRrezunVaQuX dI9dn/YCd7rCgcHfXM6bbKUKp5uwTT3NmCRamIVblsf7w08tvTieHYhNp+QWUKLY K0hOeF+56BSuxjQa9wA8Zz5PMQ/BaMPcSkp32SWMqNAGzg75My7QLzA= Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPSA id 925572005D82E for ; Fri, 22 Aug 2014 10:57:35 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so37665wib.16 for ; Fri, 22 Aug 2014 10:57:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.13.99 with SMTP id g3mr144999wic.28.1408730253479; Fri, 22 Aug 2014 10:57:33 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Fri, 22 Aug 2014 10:57:33 -0700 (PDT) In-Reply-To: <53F73271.3040900@iang.org> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> <53F4B8D8.2080808@bbn.com> <53F73271.3040900@iang.org> Date: Fri, 22 Aug 2014 12:57:33 -0500 Message-ID: From: Nico Williams To: ianG Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/QcvNGD99n4y3RQXnt3yac9JsxnQ Cc: "saag@ietf.org" Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 17:57:44 -0000 On Fri, Aug 22, 2014 at 7:07 AM, ianG wrote: > On 20/08/2014 16:03 pm, Stephen Kent wrote: >> You noted my use of the phrase "Opportunistic Crypto-Secruity" instead >> of "Opportunistic Secruity." >> I made the change after someone else suggested it as a more precise >> description of what we're >> doing, > > It's not more precise, it's either a distinction of no difference or a > mistake. I can make a [totally contrived] case for opportunistic non-cryptographic security that nonetheless uses the same principles as OS. I won't bother to here, but the point is that you're quite right, though I don't think that's enough of an argument to settle the matter. Besides, personally I find OCS a reasonable term for _us_. If the name were the only sticking point (I think it is) left and we absolutely had to ditch OS to get published, I'd settle for OCS, no doubt, and I'd hope that OCS turns out to make a decent marketing term. I've explained my rationale for why OS is better. I admit that what's better depends on the audience. Perhaps it's a terrible idea to try to come up with a name that the public can be aware of. I'm not sure of this (and a lot of other things); it's a gamble. But I continue to think that on the whole we're better off giving this new attitude an accessible name, especially since we've not found a hands-down awesome name for it. We've given the naming thing many go-arounds... Nico -- From nobody Fri Aug 22 12:30:15 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D60A1A059F; Fri, 22 Aug 2014 12:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYszkCyAPbWH; Fri, 22 Aug 2014 12:30:11 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65C461A056D; Fri, 22 Aug 2014 12:30:11 -0700 (PDT) X-AuditID: 12074424-f79346d000004923-87-53f79a4298a3 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 60.23.18723.24A97F35; Fri, 22 Aug 2014 15:30:10 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s7MJU9OE023961; Fri, 22 Aug 2014 15:30:09 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7MJU7BL007904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Aug 2014 15:30:09 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7MJU6Xs007305; Fri, 22 Aug 2014 15:30:06 -0400 (EDT) Date: Fri, 22 Aug 2014 15:30:06 -0400 (EDT) From: Benjamin Kaduk To: saag@ietf.org In-Reply-To: Message-ID: References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> <53F26D8A.1050304@bbn.com> <53F27065.9030902@cs.tcd.ie> <53F36E34.7020701@bbn.com> <53F36FB1.4020008@cs.tcd.ie> <53F371CC.7020106@dcrocker.net> <53F376BF.6080701@bbn.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsUixG6nous063uwQdMzLotnG+ezWEzp72Ry YPJYsuQnUwBjFJdNSmpOZllqkb5dAlfGx77zTAXLeCtefWtlbWA8wdXFyMkhIWAi8fnqA3YI W0ziwr31bF2MXBxCArOZJK5+6WCGcDYySnz+e4YRwjnEJHH//T52CKeBUeL/+zUsXYwcHCwC 2hJ3DyiDjGITUJGY+WYjG4gtIiAo8aBvEguIzSygLNH+cQEjiC0sUChxc1cHG0grp4CTxLcL ZiBhXgFHiZtvLkDt2sws8bnzAytIQlRAR2L1/iksEEWCEidnPoGaqSWxfPo2lgmMgrOQpGYh SS1gZFrFKJuSW6Wbm5iZU5yarFucnJiXl1qka66Xm1mil5pSuokRHKAuKjsYmw8pHWIU4GBU 4uFVsPoeLMSaWFZcmXuIUZKDSUmUV2QqUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIr3QhUI43 JbGyKrUoHyYlzcGiJM771toqWEggPbEkNTs1tSC1CCYrw8GhJMF7fAZQo2BRanpqRVpmTglC momDE2Q4D9Bw3pkgw4sLEnOLM9Mh8qcYFaXEeReDNAuAJDJK8+B6YQnkFaM40CvCvFtBqniA yQeu+xXQYCagwdNnfAUZXJKIkJJqYNx2XaQuO2x9SdVBtTlzlc7/cfmxb4JFgfDuJp1tDipl 7Bl/NxToru72ezPdLmjBw4X29Vunsb2V5y/Ywnr30dyul5psN9glbNMd3ILU1AWOvNz24GrV jKDl8V2S64xP3P+d9C3sxW2xM/sK529MmlWzjOHQsZqVj60nsGr0VCgpOSh07VI6/0mJpTgj 0VCLuag4EQAxMwgA+wIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/saag/7mB5PCroW-ZlPIrD6w30_PhCSIw Cc: "ietf@ietf.org" Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:30:13 -0000 On Tue, 19 Aug 2014, Benjamin Kaduk wrote: > I'm happy to see that Steve's proposal shares a fair bit of structure with > the changes I have been making, in particular the breakdown into > "determine the peer's capabilities" and then "figure out what to actually > do given that information", which I think is key to helping readers > understand things. > > Steve is being very aggressive about reducing verbosity; I'll need a > closer read to see how much of that I agree with. > > One thing that I do see from a quick skim is the change to "Opportunistic > Crypto-Security (OCS)" instead of the existing "Opportunistic Security". > I don't think that Viktor (or the group) is likely to adopt that without > the sense that we have a consensus for that term. > > Thanks for the rewrite, I look forward to reading it more carefully. Having gotten a chance to read it more carefully, I offer some general comments. There doesn't seem much point in offering specific comments, since Viktor still needs to integrate the proposal and things may change in that process. I generally agree with the new text, and find that it adequately represents my understanding of what has been proposed and fleshed out in our discussions on the list. The text is a bit stiff in some places, and perhaps overly concise, but on the whole still represents an improvement. I don't think I would object to publishing this text on the grounds that it is poorly written. I forget if I have opined on the list about OS vs. OCS or OE or other terms already, but I will just say that I prefer OS over any of the other proposals I have seen. Thanks again for writing this up, Steve. -Ben From nobody Fri Aug 22 12:45:29 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7943B1A0936; Fri, 22 Aug 2014 12:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDaoxasTFRua; Fri, 22 Aug 2014 12:45:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE951A093B; Fri, 22 Aug 2014 12:45:19 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:53799 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XKumB-000C6P-QF; Fri, 22 Aug 2014 15:45:32 -0400 Message-ID: <53F79DCD.4020309@bbn.com> Date: Fri, 22 Aug 2014 15:45:17 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org, "ietf@ietf.org" References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <20140821160402.GT14392@mournblade.imrryr.org> <20140822053503.GD14392@mournblade.imrryr.org> In-Reply-To: <20140822053503.GD14392@mournblade.imrryr.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/OS370RXrWHGaw3-XqSq97Ve_S4g Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:45:25 -0000 I concur with Viktor's reply. I even like his metaphor :-). OSteve > On Fri, Aug 22, 2014 at 05:25:17AM +0000, l.wood@surrey.ac.uk wrote: > >> Okay, so with opportunistic security, all a man in the middle >> has to do is block any communications he can't decrypt, and it >> automatically downgrades to select something he can break? > And without OS, he need not do anything at all, because the vast > majority of the traffic is cleartext. However OS can support > downgrade resistant modes of operation, given appropriately secure > out-of-band signalling, (possibly DANE/DNSSEC). > > OS is not an effort to displace already working authenticated > encrypted traffic. Rather, it is an effort to upgrade currently > unencrypted traffic to encryption or currently unauthenticated > traffic to authentication. > > Hence, "Opportunistic TLS" with SMTP for the former, and "Opportunistic > DANE TLS" with the latter. > > You can point fingers at the shabby clothing of the OS emperor, > but at least he's not naked. > > -- > Viktor. From nobody Fri Aug 22 12:51:40 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7361A0936; Fri, 22 Aug 2014 12:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3xPwh00SuBm; Fri, 22 Aug 2014 12:51:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 645841A0747; Fri, 22 Aug 2014 12:51:34 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:36764 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XKus1-0000f4-B4; Fri, 22 Aug 2014 15:51:33 -0400 Message-ID: <53F79F44.50707@bbn.com> Date: Fri, 22 Aug 2014 15:51:32 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ietf@ietf.org, saag References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <20140821160402.GT14392@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/JTag0aDouffGwWKuW12sMxXPrDw Subject: Re: [saag] Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:51:36 -0000 Nico, > On Fri, Aug 22, 2014 at 12:25 AM, wrote: >> Okay, so with opportunistic security, all a man in the middle has to do is block any communications he can't decrypt, and it automatically downgrades to select something he can break? >> >> Ah, there's the opportunity. Got it. > Eh? The idea is to be downgrade resistant. > > Nico It's nice if the OS mechanism is downgrade resistant, but that is not required by the current set of design principles. Steve From nobody Fri Aug 22 12:56:12 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692EE1A061D for ; Fri, 22 Aug 2014 12:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBcTNhLxJB3a for ; Fri, 22 Aug 2014 12:56:09 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15FAC1A059F for ; Fri, 22 Aug 2014 12:56:08 -0700 (PDT) X-AuditID: 1209190c-f795e6d000006c66-af-53f7a057763e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 2B.7C.27750.750A7F35; Fri, 22 Aug 2014 15:56:07 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s7MJu7Bq027185; Fri, 22 Aug 2014 15:56:07 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7MJu5cj017049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Aug 2014 15:56:06 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7MJu4QO010549; Fri, 22 Aug 2014 15:56:04 -0400 (EDT) Date: Fri, 22 Aug 2014 15:56:04 -0400 (EDT) From: Benjamin Kaduk To: dcrocker@bbiw.net In-Reply-To: <53F56802.9080907@dcrocker.net> Message-ID: References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> <53F41581.2030508@dcrocker.net> <53F56802.9080907@dcrocker.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixG6nohu+4HuwQdd/I4vfnz6wWUzp72Ry YPK4tPMkm8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIuz+phKliuXvH7aA97A+Ma+S5GTg4JAROJ PTO7mCFsMYkL99azdTFycQgJzGaSePltIzOEs5FRomHVXyYI5xCTxJwZL6DKGhglFj34ygrS zyKgLXHrwmF2EJtNQEVi5puNbCC2iICoRM+9PUwgNrOAoMSl/i1gtrBAscTTK2tZuhg5ODgF dCQ61liAhHkFHCU2NFxlgZi/mU3icN8psJmiQDWr909hgSgSlDg58wkLxEwtieXTt7FMYBSc hSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1DvdzMEr3UlNJNjKBg5ZTk2cH45qDS IUYBDkYlHl4Fq+/BQqyJZcWVuYcYJTmYlER5RaYChfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nw ys8FyvGmJFZWpRblw6SkOViUxHnfWlsFCwmkJ5akZqemFqQWwWRlODiUJHjd5wM1ChalpqdW pGXmlCCkmTg4QYbzAA1PA6nhLS5IzC3OTIfIn2JUlBLntZgHlBAASWSU5sH1wpLJK0ZxoFeE eb1A2nmAiQiu+xXQYCagwdNnfAUZXJKIkJJqYCw/mL9S8veEpoZ3vcmWDYaFyhfCP+SePmGu 3vBD+IT/3avCmZtehevdeTaDr625NUMn/7Oqd/aRmQIpf481SlgwVfpyP1KQqj5dF11xcPH9 LP75p20ebltt/vTAz7ClVWqGU+8tX+mu+eLJ6rKExQo/orW9Jbm3i2u3u0VlPZ/JGHDl0BO1 yUosxRmJhlrMRcWJAOLAT28BAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/saag/UWwuf48UxasQzB5XGFcZdYQOC3k Cc: saag@ietf.org Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:56:11 -0000 I see that ianG has already replied to some points, saving me the trouble. This message is twice as long as the previous one I replied to (which took me forty minutes to compose); I could not afford that kind of time yesterday. On Wed, 20 Aug 2014, Dave Crocker wrote: > On 8/20/2014 10:42 AM, Benjamin Kaduk wrote: > > On Tue, 19 Aug 2014, Dave Crocker wrote: > > My guess is that folk are confusing the common term "design pattern" > with "protocol design pattern". The former is a nice innovation of > perhaps 30+ years ago, but it's a very general concept. The latter has > little or no established use, I believe, and the lack of online examples > encourages this view. Yes, I think people are saying that "design pattern" is in common use, and "protocol design pattern" clearly is equivalent to "design pattern for protocols". ianG said a bit more on this, so I won't. > Once again, to the extent that the phrase 'protocol design pattern' is > essential, it needs to be defined carefully and practically. The draft > does not do it. I am somewhat indifferent to whether the text of the document includes the string "protocol design pattern" or "design pattern for protocols". I see "protocol design pattern" as being of greatest utility for talking about this document (or other ones) in other places; it is not particularly used internally within the document. Since the document itself does not rely on the term for matters of much substance, I am not very convinced that a rigorous definition need be included in the document itself. > > I guess I did not particularly note Steve Kent's statement at the time (I > > assume you refer to > > http://www.ietf.org/mail-archive/web/saag/current/msg05369.html). > > yup. > > And its essential point about this is that the term 'protocol design > pattern' is not essential to this draft. It become just another term > tossed in, without being used productively. [See my previous paragraph.] > >> Sorry for my confusion, but it appears you are suggesting that the way > >> to improve a document is to ignore its problems? > > > > No, of course not. I'm saying that there is no need to point out the same > > problems repeatedly using different language, once those problems have > > been acknowledged. > > First, they mostly have been either ignored or summarily rejected. > (It's been amusing to see my assertions of this also get summarily > rejected, rather than discussed.) I do not dispute this claim. Indeed, having once been rejected/ignored, one might expect that similar actions would get similar reactions, causing only more email to the list for no real change. > What is needed when someone raises a concern is to engage in ensuring a > shared understanding of the issue. That is, engaging in a process that > is often called "discussion". With few exceptions, there has been very > little of that. Rather, folk have tended to consider responses like "I > don't agree" or "That's not true" as substantive and sufficient. This is unfortunate. Alas, I can only be responsible for my own behavior. > > But, > > per RFC 7282 as you noted in a separate message, I expect our ADs to take > > note regardless.) > > By the time ADs deliberate, the community process is over and should > have established a very clear track record of engaging in resolving > differences in views. I did not refer to intra-AD deliberations, rather to when the ADs call the consensus of the group. Outstanding unresolved issues should preclude a decision that there is consensus. > Encryption w/ or w/out authentication is the real topic of immediate > concern, is the concrete topic of discussion in the draft, and is (IMO) > entirely sufficient to justify the document. > > So the real problem (IMO) is a scope creep infection that is affecting > folks' vision. > > The document does not need to do a better job of explaining the > applicability of the 'pattern' for security functions other than > encryption. > > It needs to stick with the actual substance already in the draft, and > drop the claim that it is covering more. I claimed that Steve K's new text is an adequate representation of what has been fleshed out on the list. It does appear to only cover encryption and authentication, so perhaps you are right. I don't think this need preclude couching the proposal in a more general light if that can be done while maintaining an adequate treatment. > Sorry I wasn't clear. I wasn't commenting on my concerns (about this) > but that I hadn't noticed concern amongst /others/ with that specific > term. Perhaps some debate about nuances (eg, does TOFU qualify as an > acceptable example of authenticated encryption) but nothing major. Okay. My claim was based solely on memory, and it is hard to keep track of all of the discussions in memory. Perhaps my memory was faulty in this case; it doesn't seem like a big deal, regardless. -Ben From nobody Fri Aug 22 13:04:58 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A541A064C; Fri, 22 Aug 2014 13:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHWscXWaez57; Fri, 22 Aug 2014 13:04:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90871A056D; Fri, 22 Aug 2014 13:04:54 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58920 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XKv59-000CH6-LX; Fri, 22 Aug 2014 16:05:07 -0400 Message-ID: <53F7A265.9000607@bbn.com> Date: Fri, 22 Aug 2014 16:04:53 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org, "ietf@ietf.org" References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> <53F4B8D8.2080808@bbn.com> <53F73271.3040900@iang.org> In-Reply-To: <53F73271.3040900@iang.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/iaxDM2YOdiBHbgNCqmJEy28-HZo Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 20:04:56 -0000 Ian, > On 20/08/2014 16:03 pm, Stephen Kent wrote: >> Ben, >> >> You noted my use of the phrase "Opportunistic Crypto-Secruity" instead >> of "Opportunistic Secruity." >> I made the change after someone else suggested it as a more precise >> description of what we're >> doing, > It's not more precise, it's either a distinction of no difference or a > mistake. so says the man with how many RFCs and other publications to his credit? > What we are doing is Opportunistic Security. That is, we are securing > the users' interests using an opportunistic approach. > > We are then applying this approach to protocols. Now, obviously, when > we are doing protocols, most security ends up being crypto in nature. a lot of security is not at all crypto-based: non-Ipsec firewalls, IDS's, ... > So in this sense of high-level viewpoint, the distinction is no > distinction, OS is crypto-security. I agree that what we are discussing is crypto security. I am not wedded to the OCS name alternative; I proposed OS and someone else suggested OCS. > But, at a more detailed level, this simplification is reversed: > sometimes we come across a technique that isn't crypto-related. For > example, TOFU. This is based on the limited time/space window, the > knowledge of the human operators, and the economics of attacking every > possibility all the time. TOFU is a key management mechanism, i.e., it is used to distribute a public key, which is then cached along with the proffered ID. I'd say that any key management mechanism is crypto-related. > TOFU is not crypto, yet it is OS. TOFU is one key management mechanism that MAY be part of an OS solution. DANE is another; unauthenticated Diffie-Hellman is another, ... > So, by saying crypto-security we are in danger of eliminating one of our > best and most successful techniques [0]. And, as we are talking > opportunistically, we indeed want to not be so prejudicial. We'll take > a benefit where we find it. we disagree on whether TOFU is crypto-related. > and because it has the advantage of being represented by an > acronym that isn't so common > (OCS vs. OS) in our arena. yes. > Yeah, overloading is a nice to avoid, but not essential. How about > opp-sec? Of if someone points out a clash with operational security, > then oppo-sec. opp-sec is not an acronym, so I don't see the parallel. Steve From nobody Fri Aug 22 13:31:24 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADB71A6F54 for ; Fri, 22 Aug 2014 13:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttmm1tlYvqF1 for ; Fri, 22 Aug 2014 13:31:21 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5A11A6F4B for ; Fri, 22 Aug 2014 13:31:20 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 4860C6D6F9; Fri, 22 Aug 2014 16:31:17 -0400 (EDT) Message-ID: <53F7A894.2090804@iang.org> Date: Fri, 22 Aug 2014 21:31:16 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> , <20140821160402.GT14392@mournblade.imrryr.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/NwgzubnEfffH1BkNwlkBv4u1d9M Subject: Re: [saag] Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 20:31:22 -0000 On 22/08/2014 06:25 am, l.wood@surrey.ac.uk wrote: > Okay, so with opportunistic security, all a man in the middle has to do is block any communications he can't decrypt, and it automatically downgrades to select something he can break? > > Ah, there's the opportunity. Got it. Sarcasm aside, yes. The opportunity here is to force the attacker to move from passive to active. Passive is more or less free at the margin/unit. Hence the term 'pervasive'. Active is not free. For the NSA it involves targetting, controls, options, permission, reviews, risks of compromise, etc. These carry a cost. So it will, given our current state of knowledge, reduce pervasive monitoring to an occasional nuisance. iang From nobody Fri Aug 22 13:31:45 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE741A6F6B for ; Fri, 22 Aug 2014 13:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Jfj6u-0jr-4 for ; Fri, 22 Aug 2014 13:31:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FBB91A6F4A for ; Fri, 22 Aug 2014 13:31:42 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:50210 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XKvUr-0001Ml-59 for saag@ietf.org; Fri, 22 Aug 2014 16:31:41 -0400 Message-ID: <53F7A8AB.1050107@bbn.com> Date: Fri, 22 Aug 2014 16:31:39 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> <53F41581.2030508@dcrocker.net> <53F56802.9080907@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/XEgufLibM2wpEVeywWk-FowuPpk Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 20:31:44 -0000 Ben, > ... > Yes, I think people are saying that "design pattern" is in common use, and > "protocol design pattern" clearly is equivalent to "design pattern for > protocols". ianG said a bit more on this, so I won't. A more relevant issue, in my view, is whether we have tended to use these terms in RFCs and whether we have appropriate terms that we do use in RFCs instead. I think the answer to the first question is NO, and to the second is YES, as illustrated by my revised text. Steve From nobody Fri Aug 22 13:59:13 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5F31A6F42 for ; Fri, 22 Aug 2014 13:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ty7zDgTAC3_5 for ; Fri, 22 Aug 2014 13:59:06 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848071A6F57 for ; Fri, 22 Aug 2014 13:59:06 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s7MKwqqX029053; Fri, 22 Aug 2014 13:59:03 -0700 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0a-0016f401.pphosted.com with ESMTP id 1nwwucj0ht-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Aug 2014 13:59:03 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([fe80::5efe:10.93.76.24%18]) with mapi; Fri, 22 Aug 2014 13:59:03 -0700 From: Paul Lambert To: ianG , "saag@ietf.org" Date: Fri, 22 Aug 2014 13:59:02 -0700 Thread-Topic: [saag] Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) Thread-Index: Ac++SA3qxDOiPcI6RqePRILlsWM4IgAAeOpQ Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01EE5576DF3@SC-VEXCH2.marvell.com> References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> , <20140821160402.GT14392@mournblade.imrryr.org> <53F7A894.2090804@iang.org> In-Reply-To: <53F7A894.2090804@iang.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-08-22_06:2014-08-22,2014-08-22,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1408220238 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/PCa8A0qf0zou0mo4YBvsZ59QiJs Subject: Re: [saag] Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 20:59:11 -0000 ]On 22/08/2014 06:25 am, l.wood@surrey.ac.uk wrote: ]> Okay, so with opportunistic security, all a man in the middle has to ]do is block any communications he can't decrypt, and it automatically ]downgrades to select something he can break? ]> ]> Ah, there's the opportunity. Got it. ] ] ]Sarcasm aside, yes. The opportunity here is to force the attacker to ]move from passive to active. ] ]Passive is more or less free at the margin/unit. Hence the term ]'pervasive'. ] ]Active is not free. For the NSA it involves targetting, controls, ]options, permission, reviews, risks of compromise, etc. ] ]These carry a cost. So it will, given our current state of knowledge, ]reduce pervasive monitoring to an occasional nuisance. I disagree. We should not be assuming that MiTM attacks are difficult. =20 OS type encryption without authentication will provide some protection=20 from pervasive monitoring that is not targeted but grabs all=20 plain-text for later analysis. =20 For the NSA, targeted monitoring requires permission, reviews, etc. Other Potential threats will not be so restricted. Paul ] ] ] ]iang ] ]_______________________________________________ ]saag mailing list ]saag@ietf.org ]https://www.ietf.org/mailman/listinfo/saag From nobody Fri Aug 22 14:12:44 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298B61A06E1 for ; Fri, 22 Aug 2014 14:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwsh8nJuvPTw for ; Fri, 22 Aug 2014 14:12:42 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 48D681A06AD for ; Fri, 22 Aug 2014 14:12:42 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 2824B20047B6A; Fri, 22 Aug 2014 14:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=+aheczH3ArxgXI ImEaU3NMUfLgA=; b=w79BDtb3hJA9ivSi4kcP1FYRedObctCb0MJKpRZCdKantb MSGYsiA43sbQLHNI8L1dNJgjLVmnYOHh2GtTnVF4JB7M/ITwnSY9sQCFbZG2yBrb UkdsOQPoftEMazJXLy+CLOIN8InNihzZfx+l1/mXyhQHNJTgI3keaK0JT4Auc= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPA id C904220047B5D; Fri, 22 Aug 2014 14:12:41 -0700 (PDT) Date: Fri, 22 Aug 2014 16:12:41 -0500 From: Nico Williams To: Paul Lambert Message-ID: <20140822211239.GG5909@localhost> References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <20140821160402.GT14392@mournblade.imrryr.org> <53F7A894.2090804@iang.org> <7BAC95F5A7E67643AAFB2C31BEE662D01EE5576DF3@SC-VEXCH2.marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01EE5576DF3@SC-VEXCH2.marvell.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/H-0phtXbzTcMv0HsOi9W3ePvJPs Cc: "saag@ietf.org" Subject: Re: [saag] Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 21:12:43 -0000 On Fri, Aug 22, 2014 at 01:59:02PM -0700, Paul Lambert wrote: > I disagree. We should not be assuming that MiTM attacks are difficult. They are most certainly more difficult (costly) than passive attacks. In the long term active attacks might only be marginally more difficult than passive attacks, but I doubt it. When the attacker doesn't know a priori that they will be able to succeed they risk detection -- that's a huge cost right there, and it's difficult to overcome. Only the hardware infrastructure for active attacks can reach the low marginal costs of passive attacks, but the other ways in which active attacks are more costly are difficult to overcome. > OS type encryption without authentication will provide some protection > from pervasive monitoring that is not targeted but grabs all > plain-text for later analysis. OS does not preclude authentication when you can get it, and it encourages downgrade resistant upgrades (DANE, TOFU). > For the NSA, targeted monitoring requires permission, reviews, etc. Other > Potential threats will not be so restricted. Massive active attack capability is decidedly not cheap -- not as cheap as passive. Non-state actors/agents will always have a hard time constructing massive active attack capabilities. Even if a router botnet was built, it'd be relatively simple to take it down, by comparison to PC botnets. Re-read Viktor's analogy: the clothes on OS may be shabby, but OS is not naked. It's true. It's a big deal. Nico -- From nobody Fri Aug 22 14:31:18 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630171A6F80 for ; Fri, 22 Aug 2014 14:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcZEMwZ85Sl0 for ; Fri, 22 Aug 2014 14:31:14 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CB92B1A6F73 for ; Fri, 22 Aug 2014 14:31:14 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 8143920024944 for ; Fri, 22 Aug 2014 14:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=vpg0H3XjbTfL3coAgF18 IwzskzE=; b=JxOKDgy2To9hCMjLRLfiMNXJ13JV2Wt1hhASv4tRg67yx+OAilBR cySICNhnZoQ4DBaKawSISOdNcJxY16LD6coYCKyQl8dZv0ymQ6ZFbUrtwcEoHNAM XhEuw5JQlU5z4RuSpXxVWrzUE01AahUPou4GwazVh1PubKLFbzuLlYg= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 314E520024943 for ; Fri, 22 Aug 2014 14:31:14 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so255664wib.10 for ; Fri, 22 Aug 2014 14:31:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.75.17 with SMTP id y17mr862936wiv.3.1408743073199; Fri, 22 Aug 2014 14:31:13 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Fri, 22 Aug 2014 14:31:13 -0700 (PDT) In-Reply-To: <20140822211239.GG5909@localhost> References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <20140821160402.GT14392@mournblade.imrryr.org> <53F7A894.2090804@iang.org> <7BAC95F5A7E67643AAFB2C31BEE662D01EE5576DF3@SC-VEXCH2.marvell.com> <20140822211239.GG5909@localhost> Date: Fri, 22 Aug 2014 16:31:13 -0500 Message-ID: From: Nico Williams To: Paul Lambert Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Fhi2BdbhNu6CgZ-9MPh8MbRz9qE Cc: "saag@ietf.org" Subject: Re: [saag] Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 21:31:15 -0000 Paul, Besides, the only alternative to OS is what we have today. Look around: it's a mess of mostly plaintext traffic. The all-or-nothing strategy we've taken so far hasn't worked yet. Nico -- From nobody Fri Aug 22 15:33:51 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F313C1A0B7C for ; Fri, 22 Aug 2014 15:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdvthbVG9dJu for ; Fri, 22 Aug 2014 15:33:47 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6462C1A0B11 for ; Fri, 22 Aug 2014 15:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=0PJqdq83asmhQIPXEkwBBnZqkRojYCvwa+fK2CD4dmA=; b=Z0QIEouKbl4lI4ZhhIcuaJk3+CgIvCP0JJhqaSOody3/ksjLZvjzQrx6g6k0jt2qsPK9nJiSSrvhgABL2qWipWd8ozyWK2b0whTYXAuXyL9zwLK+rSuGvQqJFuHDtza0+XF7i9I/tiWk9tcFU7S2/SYFUrf+P3L3O0ryUWanzko=; Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1XKxOy-0006yP-5t; Fri, 22 Aug 2014 22:33:44 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 3037A581134; Fri, 22 Aug 2014 18:33:42 -0400 (EDT) Date: Fri, 22 Aug 2014 18:33:42 -0400 From: Theodore Ts'o To: Paul Lambert Message-ID: <20140822223342.GR11085@thunk.org> References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <20140821160402.GT14392@mournblade.imrryr.org> <53F7A894.2090804@iang.org> <7BAC95F5A7E67643AAFB2C31BEE662D01EE5576DF3@SC-VEXCH2.marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01EE5576DF3@SC-VEXCH2.marvell.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/saag/6ZrrBli_P7xZM28W_SXtjqSB48s Cc: "saag@ietf.org" Subject: Re: [saag] Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 22:33:49 -0000 On Fri, Aug 22, 2014 at 01:59:02PM -0700, Paul Lambert wrote: > > For the NSA, targeted monitoring requires permission, reviews, etc. Other > Potential threats will not be so restricted. It's not clear that how much permissions and reviews are needed for monitoring done under 12333. See claims that all phone calls for at least one particular country may be monitored by the NSA. And no one has said that MITM attacks are _difficult_. Just that if you are going to be inserting or deleting bytes into the middle of a TCP stream, and doing so for all connections on an OC-12 pipe, it might require more equipment (and power/cooling) than can be easily hidden in a small phone closet somewhere in an AT&T facility.... - Ted From nobody Fri Aug 22 16:28:14 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADCC1A6F91; Fri, 22 Aug 2014 16:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EUVkOWA9SvW; Fri, 22 Aug 2014 16:28:06 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.171]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8371A6F8A; Fri, 22 Aug 2014 16:28:05 -0700 (PDT) Received: from [85.158.137.99:24523] by server-11.bemta-3.messagelabs.com id A4/19-12220-402D7F35; Fri, 22 Aug 2014 23:28:04 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-9.tower-217.messagelabs.com!1408750081!21652674!13 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10385 invoked from network); 22 Aug 2014 23:28:04 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-9.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 22 Aug 2014 23:28:04 -0000 Received: from EXHY012V.surrey.ac.uk (131.227.201.103) by EXHT012P.surrey.ac.uk (131.227.200.39) with Microsoft SMTP Server (TLS) id 8.3.348.2; Sat, 23 Aug 2014 00:28:03 +0100 Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.201.241) by EXHY012v.surrey.ac.uk (131.227.201.103) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 23 Aug 2014 00:28:03 +0100 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB437.eurprd06.prod.outlook.com (10.242.23.11) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Fri, 22 Aug 2014 23:28:02 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.1010.016; Fri, 22 Aug 2014 23:28:02 +0000 From: To: , , Thread-Topic: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) Thread-Index: AQHPuY+Nm7Pkbzx7KkOt3ckflPEqF5vUH0mAgAABRQCAAKh5gIAITRQigAA3Bhw= Date: Fri, 22 Aug 2014 23:28:02 +0000 Message-ID: <9d5c27fbf536472aaadd76ec1e85b610@AMSPR06MB439.eurprd06.prod.outlook.com> References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> <53F4B8D8.2080808@bbn.com> <53F73271.3040900@iang.org>,<53F7A265.9000607@bbn.com> In-Reply-To: <53F7A265.9000607@bbn.com> Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [124.170.214.211] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199003)(189002)(24454002)(377454003)(51704005)(479174003)(93886004)(83072002)(77982001)(15975445006)(15202345003)(80022001)(81342001)(15198665003)(4396001)(92566001)(33646002)(95666004)(83322001)(66066001)(74316001)(2656002)(46102001)(85306004)(21056001)(64706001)(20776003)(101416001)(107046002)(76176999)(50986999)(74502001)(85852003)(86362001)(19580395003)(87936001)(19580405001)(107886001)(31966008)(79102001)(99396002)(106116001)(74482001)(76576001)(108616004)(15395725005)(90102001)(105586002)(81542001)(54356999)(106356001)(2201001)(74662001)(76482001)(2501001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB437; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB437.eurprd06.prod.outlook.com X-CrossPremisesHeadersFiltered: EXHY012v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/saag/XCdh7_LSmMcF-eFsVXqJ9KSoyPs Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 23:28:09 -0000 > so says the man with how many RFCs and other publications to his credit? that is very ad hominem. I fail to see the relevance of the question. are you capable of formulating a better argument? Lloyd Wood http://about.me/lloydwood you say crypto, I think cryptosporidium ________________________________________ From: ietf on behalf of Stephen Kent Sent: Saturday, 23 August 2014 6:04:53 AM To: saag@ietf.org; ietf@ietf.org Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportuni= stic Security -03 preview for comment) Ian, > On 20/08/2014 16:03 pm, Stephen Kent wrote: >> Ben, >> >> You noted my use of the phrase "Opportunistic Crypto-Secruity" instead >> of "Opportunistic Secruity." >> I made the change after someone else suggested it as a more precise >> description of what we're >> doing, > It's not more precise, it's either a distinction of no difference or a > mistake. so says the man with how many RFCs and other publications to his credit? > What we are doing is Opportunistic Security. That is, we are securing > the users' interests using an opportunistic approach. > > We are then applying this approach to protocols. Now, obviously, when > we are doing protocols, most security ends up being crypto in nature. a lot of security is not at all crypto-based: non-Ipsec firewalls, IDS's, ... > So in this sense of high-level viewpoint, the distinction is no > distinction, OS is crypto-security. I agree that what we are discussing is crypto security. I am not wedded to the OCS name alternative; I proposed OS and someone else suggested OCS. > But, at a more detailed level, this simplification is reversed: > sometimes we come across a technique that isn't crypto-related. For > example, TOFU. This is based on the limited time/space window, the > knowledge of the human operators, and the economics of attacking every > possibility all the time. TOFU is a key management mechanism, i.e., it is used to distribute a public key, which is then cached along with the proffered ID. I'd say that any key management mechanism is crypto-related. > TOFU is not crypto, yet it is OS. TOFU is one key management mechanism that MAY be part of an OS solution. DANE is another; unauthenticated Diffie-Hellman is another, ... > So, by saying crypto-security we are in danger of eliminating one of our > best and most successful techniques [0]. And, as we are talking > opportunistically, we indeed want to not be so prejudicial. We'll take > a benefit where we find it. we disagree on whether TOFU is crypto-related. > and because it has the advantage of being represented by an > acronym that isn't so common > (OCS vs. OS) in our arena. yes. > Yeah, overloading is a nice to avoid, but not essential. How about > opp-sec? Of if someone points out a clash with operational security, > then oppo-sec. opp-sec is not an acronym, so I don't see the parallel. Steve From nobody Fri Aug 22 19:14:04 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3B91A702D; Fri, 22 Aug 2014 19:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.668 X-Spam-Level: X-Spam-Status: No, score=-0.668 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Txr3BROb5J6w; Fri, 22 Aug 2014 19:13:56 -0700 (PDT) Received: from BLU004-OMC4S26.hotmail.com (blu004-omc4s26.hotmail.com [65.55.111.165]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FA11A7026; Fri, 22 Aug 2014 19:13:55 -0700 (PDT) Received: from BLU181-W84 ([65.55.111.137]) by BLU004-OMC4S26.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Fri, 22 Aug 2014 19:13:55 -0700 X-TMN: [SIea+3UaYSSLPoFoZAl+PC8nytlxN4uO] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_17a9aeeb-4068-4189-9be6-f13591c80e37_" From: Bernard Aboba To: "saag@ietf.org" , "ietf@ietf.org" Date: Fri, 22 Aug 2014 19:13:54 -0700 Importance: Normal In-Reply-To: <20140822140000.GE14392@mournblade.imrryr.org> References: , , <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Aug 2014 02:13:55.0306 (UTC) FILETIME=[E406A4A0:01CFBE77] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/SkR5Szrl-A3tQyK83mT_gt6j0Yk Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 02:13:58 -0000 --_17a9aeeb-4068-4189-9be6-f13591c80e37_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > It used to be easy to dismiss opportunistic security as a waste of time= =2C it is now clear to most that it is .... [BA] Merely a waste of money.=20 "Opportunistic unauthenticated encryption" that does not defend against man= -in-the-middle attacks has no value against targeted surveillance. So if t= he goal is to protect dissidents=2C look elsewhere. Unfortunately=2C the l= ine between "targeted surveillance" and "mass surveillance" is a thin one.= =20 The value against mass surveillance is predicated on the assumption that "l= arge scale targeted surveillance" is infeasible or that the cost of large s= cale meta-data collection can be increased to the point where it is too cos= tly even for a nation-state. =20 The first assertion=2C is likely to be proven false by the first gear to in= clude built-in man-in-the-middle attack support. Care to wager which appea= rs first=2C carrier-class gear supporting man-in-the-middle attacks=2C or s= ignificant deployment of "opportunistic" encryption? =20 The second assertion is likely to be proven false as soon as "opportunistic= " is deployed widely enough to necessitate a surveillance budget increase (= based on purchases of the above gear) necessary to defeat it. = --_17a9aeeb-4068-4189-9be6-f13591c80e37_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B It used to be easy t= o dismiss opportunistic security as a waste of =3Btime=2C it is now cle= ar to most that it is ....

[BA] Merely a waste of money.&= nbsp=3B

"Opportunistic unauthenticated encryption"= that does not defend against man-in-the-middle attacks has no value agains= t targeted surveillance.  =3BSo if the goal is to protect dissidents=2C= look elsewhere.  =3BUnfortunately=2C the line between "targeted survei= llance" and  =3B"mass surveillance" is a thin one.  =3B =3B

The value against mass surveillance is predicated on = the assumption that "large scale targeted surveillance" is infeasible or th= at the cost of large scale meta-data collection can be increased to the poi= nt where it is too costly even for a nation-state.  =3B =3B

The first assertion=2C is likely to be proven false by th= e first gear to include built-in man-in-the-middle attack support.  =3B= Care to wager which appears first=2C carrier-class gear supporting man-in-t= he-middle attacks=2C or significant deployment of "opportunistic" encryptio= n?  =3B

The second assertion is likely to be p= roven false as soon as "opportunistic" is deployed widely enough to necessi= tate a surveillance budget increase (based on purchases of the above gear) = necessary to defeat it. =3B
= --_17a9aeeb-4068-4189-9be6-f13591c80e37_-- From nobody Fri Aug 22 20:02:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8451A70E2; Fri, 22 Aug 2014 20:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZIHo4IkGEOL; Fri, 22 Aug 2014 20:02:53 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D17891A0B10; Fri, 22 Aug 2014 20:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=POCRjPGjJrBraYNsQSyzRZQmQ2A5nFynmOjtztlVJBA=; b=R2Yhv48yHwBUIFt7HyXX7cRYTPZKVZ3fkBtYWsMdnJNPoL323qjV5Neu9xnSEap6WljJUUkb7CXF0EzT1hVAEgUuQkVt1v83LqhF3XfBqbSyLg0NQizMTlglgee6W6gCoqesAfZrqnLmwgX3DIDOEWdVVT21UUs/wZBTO6qRxPk=; Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1XL1bO-0000J8-GF; Sat, 23 Aug 2014 03:02:50 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 18ABD5801DD; Fri, 22 Aug 2014 23:02:50 -0400 (EDT) Date: Fri, 22 Aug 2014 23:02:50 -0400 From: Theodore Ts'o To: Bernard Aboba Message-ID: <20140823030250.GT11085@thunk.org> References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <20140821160402.GT14392@mournblade.imrryr.org> <20140822140000.GE14392@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/saag/oi6Y2hhIFKsd3X3OraAJJMb3oQw Cc: "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 03:02:56 -0000 On Fri, Aug 22, 2014 at 07:13:54PM -0700, Bernard Aboba wrote: > The first assertion, is likely to > be proven false by the first gear to include built-in > man-in-the-middle attack support. Care to wager which appears > first, carrier-class gear supporting man-in-the-middle attacks, or > significant deployment of "opportunistic" encryption? This assumes that the telecom carriers and/or the suppliers of the carrier grade equipment would cooperate with the nation-states in question. That could happen, certainly, but it becomes much more difficult to do this surreptitiously. This won't help in a totalitarian regime, certainly, but in democratic societies having law enforcement agencies engaging in mass, surreptitious surveilance might be less likely to be tolerated. Cheers, - Ted From nobody Fri Aug 22 20:57:37 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC171A03B1; Fri, 22 Aug 2014 20:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svhlGuAPEtPs; Fri, 22 Aug 2014 20:57:24 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD4D1A0149; Fri, 22 Aug 2014 20:57:24 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (25.160.96.17) by DM2PR0301MB0654.namprd03.prod.outlook.com (25.160.96.16) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Sat, 23 Aug 2014 03:57:23 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([25.160.96.17]) with mapi id 15.00.1015.017; Sat, 23 Aug 2014 03:57:22 +0000 From: Christian Huitema To: Theodore Ts'o , Bernard Aboba Thread-Topic: [saag] Is opportunistic unauthenticated encryption a waste of time? Thread-Index: AQHPvhF40HplM2hILkOzAbbw4a9vopvdc6MAgAANrACAAA6XoA== Date: Sat, 23 Aug 2014 03:57:22 +0000 Message-ID: <52b6dc3d1e9a43a48b3e05fb48bd2599@DM2PR0301MB0655.namprd03.prod.outlook.com> References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <20140821160402.GT14392@mournblade.imrryr.org> <20140822140000.GE14392@mournblade.imrryr.org> <20140823030250.GT11085@thunk.org> In-Reply-To: <20140823030250.GT11085@thunk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [24.16.156.113] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 031257FE13 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199003)(74662001)(21056001)(2171001)(81342001)(74316001)(80022001)(83322001)(107046002)(85306004)(99396002)(99286002)(74502001)(66066001)(101416001)(2656002)(20776003)(54356999)(95666004)(92566001)(77096002)(50986999)(81542001)(108616004)(76176999)(33646002)(106356001)(76576001)(79102001)(83072002)(76482001)(86362001)(87936001)(31966008)(4396001)(64706001)(85852003)(46102001)(105586002)(77982001)(106116001)(90102001)(93886004)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR0301MB0654; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/saag/WuYGha0QK-EaO0-5AzG6EBnc6Iw Cc: "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 03:57:26 -0000 > This assumes that the telecom carriers and/or the suppliers of the > carrier grade equipment would cooperate with the nation-states in > question. That could happen, certainly, but it becomes much more > difficult to do this surreptitiously. It is also fairly easy for OS conscious applications to use channel binding= schemes and detect the MITM. At that point, the spies have to move from co= vert monitoring to overt surveillance, which should have some noticeable po= litical consequences. -- Christian Huitema From nobody Fri Aug 22 21:05:58 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDA31A6FF5; Fri, 22 Aug 2014 21:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOq17MANXcJA; Fri, 22 Aug 2014 21:05:53 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9DC1A6FED; Fri, 22 Aug 2014 21:05:53 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 3F93C26C063; Fri, 22 Aug 2014 21:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=cBy02uYXMZytlJ voogNnClkF0a0=; b=m6QyjLa6rLQrzlkipE6uS670//KFCIiNB2qhpvz2UVRPKd UNDwN5OoqpLHZ0WC/8Pq+I777TPAuMTFN3PYyafuj65q4xSF4BZ8so/mf4GRYKDm MVz3db8l8az9aD7wWk8cy53iQ37QJWiTQLkWQaRQFJcBuTf9zlF14ZcPcsHJQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPA id D691426C05E; Fri, 22 Aug 2014 21:05:52 -0700 (PDT) Date: Fri, 22 Aug 2014 23:05:52 -0500 From: Nico Williams To: Bernard Aboba Message-ID: <20140823040550.GQ5909@localhost> References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <20140821160402.GT14392@mournblade.imrryr.org> <20140822140000.GE14392@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/5UNu5ZN0h4fuEKUy0NQsDGJzgB8 Cc: "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 04:05:56 -0000 On Fri, Aug 22, 2014 at 07:13:54PM -0700, Bernard Aboba wrote: > > It used to be easy to dismiss opportunistic security as a waste of time, it is now clear to most that it is .... > > [BA] Merely a waste of money. > "Opportunistic unauthenticated encryption" that does not defend > against man-in-the-middle attacks has no value against targeted > surveillance. So if the goal is to protect dissidents, look > elsewhere. Unfortunately, the line between "targeted surveillance" > and "mass surveillance" is a thin one. For me OS is not about anti-PM, or at least not mainly anti-PM. See below. > The value against mass surveillance is predicated on the assumption > that "large scale targeted surveillance" is infeasible or that the > cost of large scale meta-data collection can be increased to the point > where it is too costly even for a nation-state. > > The first assertion, is likely to be proven false by the first gear to > include built-in man-in-the-middle attack support. Care to wager > which appears first, carrier-class gear supporting man-in-the-middle > attacks, or significant deployment of "opportunistic" encryption? MITM HW, if need be, will materialize and will be deployed. I don't doubt this. That doesn't mean that active attacks are not more costly than passive ones, or that it's not worth providing protection against passive attacks. Attackers not operating under the color of law can only really build a massive PM active attack system by building edge-most router botnets, which seems unlikely to go unnoticed, those routers almost certainly lacking the necessary CPU oomph... Therefore OS can go a long distance relative to criminals in many situations. Sovereign powers will be able to do build active PM systems, no doubt. But if the end-state for OS is something like DANE then the sovereigns will either have to MITM DNSSEC or force services to furnish them with authentication keys. Both of those are potentially very expensive politically (because they will be noticeable intrusions). If not, then they will at least be clarifying. If a nation's people don't mind their government monitoring them, they still ought to be able to get protection relative to third parties (routers, criminals, foreign powers). Nico -- From nobody Fri Aug 22 21:32:12 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5EF1A854D; Fri, 22 Aug 2014 21:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnezDh0fT0gR; Fri, 22 Aug 2014 21:32:05 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD0881A802E; Fri, 22 Aug 2014 21:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1408768325; x=1440304325; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=apGvh1GUGBhU12ALt6+bamBI1AbwDsZQel4HUR1gIfU=; b=Z/dQ5W0Ti8t5keqAH4vxImJ1DFLoBOKETy3YsWAQTQ5YQ/gcVq2/Ln1c pmM1Hc1x3PcFKyI1MCqX1na9sPc3o0yGw9WdgYo+xbS5qDQSp3vmi2Pwp U4fqOi4m66VST6P6ZYoPgWDIhvSjNTBuOCdVB12uIcCjJlFfBqpYAZu2N 0=; X-IronPort-AV: E=Sophos;i="5.04,385,1406548800"; d="scan'208";a="271717059" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 23 Aug 2014 16:32:00 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Sat, 23 Aug 2014 16:32:00 +1200 From: Peter Gutmann To: "ietf@ietf.org" , "kent@bbn.com" , "l.wood@surrey.ac.uk" , "saag@ietf.org" Thread-Topic: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) Thread-Index: Ac++iy2ulBeyTirzR3uaIJr1HsHrCQ== Date: Sat, 23 Aug 2014 04:31:59 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9A34F6@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/IFF59Y35Op59btq31MTs1gGIVcU Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 04:32:10 -0000 l.wood@surrey.ac.uk writes:=0A= =0A= >> so says the man with how many RFCs and other publications to his credit?= =0A= >=0A= >that is very ad hominem. I fail to see the relevance of the question.=0A= =0A= It's also somewhat amusing when you consider that it's coming from the pers= on=0A= who's given us such RFC gems of design as the ones for IPsec and PKIX. Tal= k=0A= about people in glass houses...=0A= =0A= Peter.=0A= From nobody Sat Aug 23 04:19:38 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FBB1A029C; Sat, 23 Aug 2014 04:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9svSaOMG5ot; Sat, 23 Aug 2014 04:19:34 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C6E01A00CA; Sat, 23 Aug 2014 04:19:34 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id i50so11093506qgf.20 for ; Sat, 23 Aug 2014 04:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uPWHJX8f6PVV/mfAsN4bVA2QjFx3Uy89PIucnvZV8R4=; b=xjxYOSxAwGMpnMksw9nVcSTGSMEeI5Byi1kQWBWU+ek7T+AzA1Gwi7v+I0noApMJkC IUYjHrhAmEB0zINfI2mJCMKxHj6wUz2Lh04Rmw3nGOA//HIq3es/GTRLyn8vKhPqM7Bp 8TRLPFN8MnzxOBRhqJWZdL+OoYpTFZikhu0Xr9Fep4AqAhQLrmUUDVrU14rXnU57yHTR RGO96+CbuUxLJ+52ju9SEgD7V3W+RIlTmFayXN+yZh1M89ZzOZSbtuaSAvIgB74M6qhw mNcu4F/wXix5YJKez/AyPm3g9NgGMtoSRSrlAvcjOPTFQ5ibkWICBWbKui3H6JoPzI/X HdYA== X-Received: by 10.140.85.74 with SMTP id m68mr15482739qgd.50.1408792773527; Sat, 23 Aug 2014 04:19:33 -0700 (PDT) Received: from [192.168.1.4] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id u14sm63189366qac.15.2014.08.23.04.19.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Aug 2014 04:19:31 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9A34F6@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Sat, 23 Aug 2014 07:19:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7422ECA5-51A3-42EB-B1B1-A4A434FEE976@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C739B9A34F6@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann Archived-At: http://mailarchive.ietf.org/arch/msg/saag/e13UsgodP5gGjhZgyhnBojnpyRA Cc: "saag@ietf.org" , "ietf@ietf.org" , "l.wood@surrey.ac.uk" Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 11:19:36 -0000 Sent from my iPhone > On Aug 23, 2014, at 12:31 AM, Peter Gutmann wr= ote: >=20 > l.wood@surrey.ac.uk writes: >=20 >>> so says the man with how many RFCs and other publications to his credit?= >>=20 >> that is very ad hominem. I fail to see the relevance of the question. >=20 > It's also somewhat amusing when you consider that it's coming from the per= son > who's given us such RFC gems of design as the ones for IPsec and PKIX. Ta= lk > about people in glass houses... We as a community are working to improve communications and encourage newcom= ers to stay. Please do not continue to post jabs at others and I don't care= of they started it. It is also a waste of time for everyone who is trying t= o get real work done and has to read this since they are following a discuss= ion. Thank you. >=20 > Peter. >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Sat Aug 23 04:35:01 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1941A8751 for ; Sat, 23 Aug 2014 04:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApFmtWlxSu_O for ; Sat, 23 Aug 2014 04:34:57 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1F7B1A028B for ; Sat, 23 Aug 2014 04:34:56 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 64FFB6D666; Sat, 23 Aug 2014 07:34:54 -0400 (EDT) Message-ID: <53F87C5D.5080302@iang.org> Date: Sat, 23 Aug 2014 12:34:53 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Lambert , "saag@ietf.org" References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> , <20140821160402.GT14392@mournblade.imrryr.org> <53F7A894.2090804@iang.org> <7BAC95F5A7E67643AAFB2C31BEE662D01EE5576DF3@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01EE5576DF3@SC-VEXCH2.marvell.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/EkGqJjeIsjM0WkPQ7wgOYkSK8XQ Subject: Re: [saag] Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 11:34:58 -0000 On 22/08/2014 21:59 pm, Paul Lambert wrote: > > ]On 22/08/2014 06:25 am, l.wood@surrey.ac.uk wrote: > ]> Okay, so with opportunistic security, all a man in the middle has to > ]do is block any communications he can't decrypt, and it automatically > ]downgrades to select something he can break? > ]> > ]> Ah, there's the opportunity. Got it. > ] > ] > ]Sarcasm aside, yes. The opportunity here is to force the attacker to > ]move from passive to active. > ] > ]Passive is more or less free at the margin/unit. Hence the term > ]'pervasive'. > ] > ]Active is not free. For the NSA it involves targetting, controls, > ]options, permission, reviews, risks of compromise, etc. > ] > ]These carry a cost. So it will, given our current state of knowledge, > ]reduce pervasive monitoring to an occasional nuisance. > > I disagree. We should not be assuming that MiTM attacks are difficult. We aren't. We're assuming that PM is 'free' whereas active attacks are not free. Which is very different to difficult or not difficult. One's a distinction of business which asks how many, the other is a distinction of science which asks whether it's possible. NSA is probably running 1000s of active attacks a day. But, their passive count is probably in the billions. They can probably run double that number easily enough, it isn't difficult. Maybe 10 times? But it is costly at some level, they have limits. E.g., they can't run active attacks on say millions at the same time. > OS type encryption without authentication will provide some protection > from pervasive monitoring that is not targeted but grabs all > plain-text for later analysis. > > For the NSA, targeted monitoring requires permission, reviews, etc. Other > Potential threats will not be so restricted. Oh, true -- other attackers such as scammers, phishers, and so forth will be also able to inject and defeat. It will definitely change the threat ratios. But they will also have a cost, will also take on a risk, and by doing that attack, we can potentially respond. Again, it comes back to your point of view. What was delivered in the way of security is mostly cleartext, no matter the promises. That's what PM snarfs up. We're looking to improve the security delivery from mostly nothing to mostly encrypted. Later on, we can add other stuff. iang From nobody Sat Aug 23 04:45:30 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043071A6F9D for ; Sat, 23 Aug 2014 04:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jm8WE7nURfuV for ; Sat, 23 Aug 2014 04:45:27 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142811A0AE8 for ; Sat, 23 Aug 2014 04:45:27 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 37CB46D659; Sat, 23 Aug 2014 07:45:26 -0400 (EDT) Message-ID: <53F87ED5.3030802@iang.org> Date: Sat, 23 Aug 2014 12:45:25 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140812060833.GD14392@mournblade.imrryr.org> <53EE2D2A.5020000@dcrocker.net> <20140815173440.GR5476@mournblade.imrryr.org> <53EE61D3.3000208@dcrocker.net> <53EE6CFF.3060406@bbiw.net> <20140815211457.GY5476@mournblade.imrryr.org> <2B5D865E-4405-4730-B318-8CBDAC00E431@csail.mit.edu> <20140816044854.GB5476@mournblade.imrryr.org> <20140816201945.GC8110@localhost> <53F0AC37.4040701@dcrocker.net> <53F0B39F.90003@iang.org> <53F3611B.3060208@dcrocker.net> <53F4B8D8.2080808@bbn.com> <53F73271.3040900@iang.org> <53F7A265.9000607@bbn.com> In-Reply-To: <53F7A265.9000607@bbn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/gCp9JEnIMue5hKPMNzHbbZy_Qzs Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 11:45:29 -0000 Hi Stephen, On 22/08/2014 21:04 pm, Stephen Kent wrote: > Ian, > >> On 20/08/2014 16:03 pm, Stephen Kent wrote: >>> Ben, >>> >>> You noted my use of the phrase "Opportunistic Crypto-Secruity" instead >>> of "Opportunistic Secruity." >>> I made the change after someone else suggested it as a more precise >>> description of what we're >>> doing, >> It's not more precise, it's either a distinction of no difference or a >> mistake. > so says the man with how many RFCs and other publications to his credit? I thought everyone knew me, but let me explain: I do counter-cultural writing. You'll not find my name on an RFC, maybe by definition? Strictly for amusement, here's one: http://iang.org/ssl/reliable_connections_are_not.html Please take this in the spirit of amusing saturday reading, not as an actual call to arms to disband TCP and start again :) >> What we are doing is Opportunistic Security. That is, we are securing >> the users' interests using an opportunistic approach. >> >> We are then applying this approach to protocols. Now, obviously, when >> *we are doing protocols* , most security ends up being crypto in nature. > a lot of security is not at all crypto-based: non-Ipsec firewalls, > IDS's, ... Indeed, that was the subtlety I was getting at. In protocols, it ends up being almost mostly crypto, but not 100%. Rhyming for Internet security, it seems as though it is a crypto task, but there are some areas where it decidedly is not. >> So in this sense of high-level viewpoint, the distinction is no >> distinction, OS is crypto-security. > I agree that what we are discussing is crypto security. > I am not wedded to the OCS name alternative; I proposed OS > and someone else suggested OCS. >> But, at a more detailed level, this simplification is reversed: >> sometimes we come across a technique that isn't crypto-related. For >> example, TOFU. This is based on the limited time/space window, the >> knowledge of the human operators, and the economics of attacking every >> possibility all the time. > TOFU is a key management mechanism, i.e., it is used to distribute a > public key, which is then cached along with the proffered ID. I'd > say that any key management mechanism is crypto-related. Of course, the protocol needs a key. How to deliver it is the question. Model- or policy-based security says that the key has to be reliable/authentic or your model or policy is broken. In contrast, TOFU says the reliability can be non-deterministic (?) if you take that risk. That choice is what this is about, not whether it's a cryptographic key, a password or one of those new-fangled grainy photos of numbers they use in CAPTCHAs these days. >> TOFU is not crypto, yet it is OS. > TOFU is one key management mechanism that MAY be part of an OS solution. > DANE is another; unauthenticated Diffie-Hellman is another, ... Right, full agreement. But if we use TOFU with a password, is that still crypto? >> So, by saying crypto-security we are in danger of eliminating one of our >> best and most successful techniques [0]. And, as we are talking >> opportunistically, we indeed want to not be so prejudicial. We'll take >> a benefit where we find it. > we disagree on whether TOFU is crypto-related. TOFU is also human-related. When you drive to a new town, and go into a store, did you need anyone to tell you "that is a store" ? No, you will use your own internalised methods to take a risk on an open door with a bunch of ads and parked cars out the front. Same with SSH. When a sysadm connects to a box the first time, she knows that nobody is trying to MITM her to a very high reliability, because because. So if we agree that TOFU comes into the OS bailiwick, and we agree that risk taking based on human learning is a part too, then we'd also have to expand the new term to be 'opportunistic crypto-human-risk-probabilistic-security.' >> and because it has the advantage of being represented by an >> acronym that isn't so common >> (OCS vs. OS) in our arena. > yes. >> Yeah, overloading is a nice to avoid, but not essential. How about >> opp-sec? Of if someone points out a clash with operational security, >> then oppo-sec. > opp-sec is not an acronym, so I don't see the parallel. Anyway, to summarise my position. IMHO, trying to refine the term OS further isn't helpful, because although at the protocol level security is mostly about crypto, it isn't 100%. OS is as much about opening minds to things outside the cultural norms as it is about the design pattern of encrypt-if-possible-then-auth-if-possible. On the other hand, it is granted by pretty much everyone here, that regardless of good work done, the draft speaks more to encryption than to the title. I'm not sure what to do about that. Add an example on DANE? iang From nobody Sat Aug 23 04:54:09 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE031A875E for ; Sat, 23 Aug 2014 04:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z323uLJ210Bl for ; Sat, 23 Aug 2014 04:54:07 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573621A0AE7 for ; Sat, 23 Aug 2014 04:54:07 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 5F0836D660; Sat, 23 Aug 2014 07:54:06 -0400 (EDT) Message-ID: <53F880DD.5060301@iang.org> Date: Sat, 23 Aug 2014 12:54:05 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: , , <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/yZ9G1hRFbw0dWl-F722jbGF5rwc Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 11:54:09 -0000 On 23/08/2014 03:13 am, Bernard Aboba wrote: >> It used to be easy to dismiss opportunistic security as a waste > of time, it is now clear to most that it is .... > > [BA] Merely a waste of money. > > "Opportunistic unauthenticated encryption" that does not defend against > man-in-the-middle attacks has no value against targeted surveillance. > So if the goal is to protect dissidents, look elsewhere. > Unfortunately, the line between "targeted surveillance" and "mass > surveillance" is a thin one. Maybe, but we don't know because we can't see that line. > The value against mass surveillance is predicated on the assumption that > "large scale targeted surveillance" is infeasible or that the cost of > large scale meta-data collection can be increased to the point where it > is too costly even for a nation-state. > > The first assertion, is likely to be proven false by the first gear to > include built-in man-in-the-middle attack support. Care to wager which > appears first, carrier-class gear supporting man-in-the-middle attacks, > or significant deployment of "opportunistic" encryption? > > The second assertion is likely to be proven false as soon as > "opportunistic" is deployed widely enough to necessitate a surveillance > budget increase (based on purchases of the above gear) necessary to > defeat it. Agreed on both points. And this is a big win. Because then we know what they are doing and can provide evidence. Then, those who care can start deploying better protection, instead of living in the "false sense of security" which is the norm of the net. If one considers say TCPInc to be an OS-inspired competitor of the existing TLS franchise, then I'd humbly suggest that is wrong. With TCPinc in place, doing OS-inspired encryption, there will be some protection for many *and* a lot of attacks on many. That latter will cause an increase in usage of TLS. What we know about, we can respond to. What we don't know, we can only wheelspin over. iang From nobody Sat Aug 23 13:27:59 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6501A88DD; Sat, 23 Aug 2014 13:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJnqmN9hVBYY; Sat, 23 Aug 2014 13:27:53 -0700 (PDT) Received: from BLU004-OMC4S27.hotmail.com (blu004-omc4s27.hotmail.com [65.55.111.166]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943321A06A4; Sat, 23 Aug 2014 13:27:53 -0700 (PDT) Received: from BLU181-W30 ([65.55.111.136]) by BLU004-OMC4S27.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Sat, 23 Aug 2014 13:27:52 -0700 X-TMN: [p342fPnBVwEo0pVbRgVKCEfOgHDYSjfE] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_373daf7d-75a6-4849-bd11-854c0ae9876e_" From: Bernard Aboba To: Nico Williams Date: Sat, 23 Aug 2014 13:27:52 -0700 Importance: Normal In-Reply-To: <20140823040550.GQ5909@localhost> References: <53F548E5.2070208@cs.tcd.ie>, <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org>, , <20140823040550.GQ5909@localhost> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Aug 2014 20:27:52.0934 (UTC) FILETIME=[B719D860:01CFBF10] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/gDufMbzQ5GiInZhFQ0XgeemNYL8 Cc: "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 20:27:55 -0000 --_373daf7d-75a6-4849-bd11-854c0ae9876e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nico said:=20 > For me OS is not about anti-PM=2C or at least not mainly anti-PM. See be= low. =20 [BA] I agree - but IMHO it would be useful if we were clear about this in p= roblem statement documents. =20 >Therefore OS can go a long distance relative to criminals in many situatio= ns. =20 [BA] We certainly do have a problem with criminals targeting payment networ= ks to great effect. However=2C given the urgency and potential deployment = lags=2C is OS the most timely potential response to that problem?=20 > Sovereign powers will be able to do build active PM systems=2C no doubt. =20 [BA] In many cases (and certainly in the case of virtually all oppressive r= egimes)=2C major portions of the Internet infrastructure are under control = of the state. So if the issue is oppressive regimes (and protection of dis= sidents)=2C something considerably more comprehensive than OS is needed (e.= g. more along the lines of Tor).=20 =20 [nico] But if the end-state for OS is something like DANE=20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= [Huitema] It is also fairly easy for OS conscious applications to use chann= el binding schemes and detect the MITM.=20 [BA] If we are talking about DANE and channel binding schemes=2C aren't we = out of the realm of "unauthenticated" opportunistic encryption? =20 =20 [IanG] "Agreed on both points. And this is a big win. Because then we kno= w what they are doing and can provide evidence." [Ted] This won't help in a totalitarian regime=2C certainly=2C but in democ= ratic=0A= societies having law enforcement agencies engaging in mass=2C=0A= surreptitious surveilance might be less likely to be tolerated.=0A= =20 [BA] AFAIK=2C the surveillance budget is not a matter of public record in m= ost nations of the world. And as far as "toleration" in democratic societi= es is concerned=2C are there democratic societies in which there are compre= hensive reform proposals that have a good chance of passage? Just wondered= if I was missing something.=20 = --_373daf7d-75a6-4849-bd11-854c0ae9876e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Nico said:

>=3B For me= OS is not about anti-PM=2C or at least not mainly anti-PM. See below.
=  =3B
[BA] I agree - but =3BIMHO it would be useful if we were cl= ear about this in problem statement documents. =3B =3B

>= =3BTherefore OS can go a long distance relative to criminals in many situat= ions.
 =3B
[BA] We certainly do =3Bhave a problem with crimin= als targeting payment networks to great effect. =3B However=2C given th= e urgency and potential deployment lags=2C is OS the most timely potential = response to that problem? =3B

>=3B Sovereign powers will be ab= le to do build active PM systems=2C no doubt.
 =3B
[BA] In many c= ases (and certainly in the case of virtually all oppressive regimes)=2C maj= or portions of the Internet infrastructure are under control of the state.&= nbsp=3B So if the issue is oppressive regimes (and protection of dissidents= )=2C something considerably more =3Bcomprehensive than OS is needed (e.= g. more along the lines of Tor).
 =3B
[nico]  =3BBut if the = end-state for OS is something like DANE
=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A= =0A= =0A= =0A=
=0A= =0A= [Huitema] It is also fairly easy for OS conscious applications to use chann= el binding schemes and detect the MITM.
 =3B
= [BA] If we are talking about DANE and channel binding schemes=2C aren't we = out of the realm of "unauthenticated" opportunistic encryption? =3B  =3B
[IanG] "Agreed on both points. And this is a big win. Becaus= e then we know what they are doing and can provide evidence."
[Ted] This= won't help in a totalitarian regime=2C certainly=2C but in democratic=0A= societies having law enforcement agencies engaging in mass=2C=0A= surreptitious surveilance might be less likely to be tolerated.=0A=
 =3B
[BA] AFAIK=2C the surveillance budget is not a matter of pu= blic record in most nations of the world. =3B And as far as "toleration= " in democratic societies =3Bis concerned=2C are there =3Bdemocrati= c societies =3Bin which there are comprehensive reform proposals that h= ave a good chance of passage? =3B Just wondered if I was missing someth= ing.

= --_373daf7d-75a6-4849-bd11-854c0ae9876e_-- From nobody Sat Aug 23 13:33:38 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2311A88E2; Sat, 23 Aug 2014 13:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RyJbuEvCJzX; Sat, 23 Aug 2014 13:33:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 174761A88E0; Sat, 23 Aug 2014 13:33:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 60ACBBE11; Sat, 23 Aug 2014 21:33:29 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTXUf0NN6sSW; Sat, 23 Aug 2014 21:33:28 +0100 (IST) Received: from [10.87.48.6] (unknown [86.41.54.100]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 589E3BDD7; Sat, 23 Aug 2014 21:33:28 +0100 (IST) Message-ID: <53F8FA97.2020607@cs.tcd.ie> Date: Sat, 23 Aug 2014 21:33:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Bernard Aboba , Nico Williams References: <53F548E5.2070208@cs.tcd.ie>, <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org>, , <20140823040550.GQ5909@localhost> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/TMsQvIFplDS7V43eVCBuQlHyPVg Cc: "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 20:33:34 -0000 Hi Bernard, For myself, I do think there's value in OS, as do others. That can and should be debated of course. However, say we're wrong and someone who thinks OS is a waste of time is actually correct, what would such a person recommend that we do as well as, or instead of, OS? Cheers, S. From nobody Sat Aug 23 14:05:13 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003F91A06DD; Sat, 23 Aug 2014 14:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_sFfwkZMTSi; Sat, 23 Aug 2014 14:05:08 -0700 (PDT) Received: from BLU004-OMC4S4.hotmail.com (blu004-omc4s4.hotmail.com [65.55.111.143]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31831A0689; Sat, 23 Aug 2014 14:05:08 -0700 (PDT) Received: from BLU181-W66 ([65.55.111.136]) by BLU004-OMC4S4.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Sat, 23 Aug 2014 14:05:08 -0700 X-TMN: [U09urDfR1vL/VuGIlO7HtFagPL74cN3l] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_a71e8999-16ac-4a7b-a6de-830cbbe2c32f_" From: Bernard Aboba To: Stephen Farrell , Nico Williams Date: Sat, 23 Aug 2014 14:05:07 -0700 Importance: Normal In-Reply-To: <53F8FA97.2020607@cs.tcd.ie> References: <53F548E5.2070208@cs.tcd.ie>, <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org>, , <20140823040550.GQ5909@localhost> ,<53F8FA97.2020607@cs.tcd.ie> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Aug 2014 21:05:08.0246 (UTC) FILETIME=[EB736360:01CFBF15] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/qzPkwq8F4EnetF2b0x5bSm0aVvs Cc: "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 21:05:10 -0000 --_a71e8999-16ac-4a7b-a6de-830cbbe2c32f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stephen Farrell: > However=2C say we're wrong and someone who thinks OS is a waste > of time is actually correct=2C what would such a person recommend > that we do as well as=2C or instead of=2C OS? [BA] It depends on who we are trying to protect=2C and from what (or whom).= =20 If the target is protection of dissidents from oppressive regimes=2C then y= ou need something much more comprehensive than 'unauthenticated opportunist= ic encryption" (e.g. along the lines of Tor).=20 If the target is protection against PM within wealthy nations=2C then you'd= need something that can't be rendered harmless by a modest budget increase= .A number of MITM protection mechanisms have been suggested (e.g. DANE=2C c= hannel binding=2C etc.).=20 Also=2C in this category should be mechanisms for protecting privacy agains= t private-sector adversaries. As long as private companies can amass huge = dociers without resort to PM (or without the need to subvert OS)=2C and are= willing to sell that personal information to third parties (dodgy ones=2C = let alone governments)=2C one wonders whether government agencies would ma= ke better use of their funds by "buying" surveillance=2C rather than trying= to "build" it. = --_a71e8999-16ac-4a7b-a6de-830cbbe2c32f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Stephen Farrell:
=
>=3B However=2C say we're wrong and someone who thinks OS is a waste<= br>>=3B of time is actually correct=2C what would such a person recommend=
>=3B that we do as well as=2C or instead of=2C OS?

= [BA] It depends on who we are trying to protect=2C and from what (or whom).=  =3B

If the target is protection of dissident= s from oppressive regimes=2C then you need something much more comprehensiv= e than 'unauthenticated opportunistic encryption" (e.g. along the lines of = Tor). =3B

If the target is protection against = PM within wealthy nations=2C then you'd need something that can't be render= ed harmless by a modest budget increase.
A number of MITM protect= ion mechanisms have been suggested (e.g. DANE=2C channel binding=2C etc.).&= nbsp=3B

Also=2C in this category should be mechani= sms for protecting privacy against private-sector adversaries.  =3BAs long as private companies can amass huge = dociers without resort to PM (or without the need to subvert OS)=2C and are= willing to sell that personal information to third parties (dodgy ones=2C = let alone governments)=2C  =3Bone wonders whether government agencies w= ould make better use of their funds by "buying" surveillance=2C rather than= trying to "build" it. =3B
= --_a71e8999-16ac-4a7b-a6de-830cbbe2c32f_-- From nobody Sat Aug 23 14:06:02 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266F81A0B7E; Sat, 23 Aug 2014 14:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNt6a7lj8ciF; Sat, 23 Aug 2014 14:05:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB0F1A0B7F; Sat, 23 Aug 2014 14:05:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8D3B02AB2C2; Sat, 23 Aug 2014 21:05:50 +0000 (UTC) Date: Sat, 23 Aug 2014 21:05:50 +0000 From: Viktor Dukhovni To: ietf@ietf.org, "saag@ietf.org" Message-ID: <20140823210550.GP14392@mournblade.imrryr.org> References: <20140821160402.GT14392@mournblade.imrryr.org> <20140822140000.GE14392@mournblade.imrryr.org> <20140823040550.GQ5909@localhost> <53F8FA97.2020607@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53F8FA97.2020607@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/pHnI7HP_8tnChB_tdm8Y-BZW8kQ Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, ietf@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 21:06:00 -0000 On Sat, Aug 23, 2014 at 09:33:27PM +0100, Stephen Farrell wrote: > However, say we're wrong and someone who thinks OS is a waste > of time is actually correct, what would such a person recommend > that we do as well as, or instead of, OS? For the record I started work on "opportunistic DANE TLS", in March 2013, well before PM became a major concern. It was designed as a way to scalably enable authentication in SMTP, by making that opportunistic (enabled peer by peer as DANE TLSA RRs are deployed). So I see OS as a strategy to incrementally broaden both the use of encryption AND the use of authentication. Whether protocols other than MTA-to-MTA SMTP can implement OS *with* authentication remains to be seen. I hope that will prove possible over time. For mobile device applications, we may have to wait for the DNSSEC "last mile problem" to be largely addressed before significant progress in that direction can be made. -- Viktor. From nobody Sat Aug 23 14:33:31 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD34B1A0747; Sat, 23 Aug 2014 14:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKYf1hxYhGHX; Sat, 23 Aug 2014 14:33:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 56F2A1A0745; Sat, 23 Aug 2014 14:33:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4B2D0BE12; Sat, 23 Aug 2014 22:33:23 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nw-8DLtngu9; Sat, 23 Aug 2014 22:33:21 +0100 (IST) Received: from [10.87.48.6] (unknown [86.41.54.100]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 88FDDBE11; Sat, 23 Aug 2014 22:33:21 +0100 (IST) Message-ID: <53F908A1.6040207@cs.tcd.ie> Date: Sat, 23 Aug 2014 22:33:21 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Bernard Aboba , Nico Williams References: <53F548E5.2070208@cs.tcd.ie>, <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org>, , <20140823040550.GQ5909@localhost> , <53F8FA97.2020607@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/qo22GCONa5nW9eYUlEyyD0UlSrc Cc: "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 21:33:26 -0000 Hiya, On 23/08/14 22:05, Bernard Aboba wrote: > Stephen Farrell: >> However, say we're wrong and someone who thinks OS is a waste of >> time is actually correct, what would such a person recommend that >> we do as well as, or instead of, OS? > > [BA] It depends on who we are trying to protect, and from what (or > whom). Sure. > If the target is protection of dissidents from oppressive > regimes, then you need something much more comprehensive than > 'unauthenticated opportunistic encryption" (e.g. along the lines of > Tor). Right. That's a hard target and involves far more than crypto, whether OS or not. One thing clearly involved there is that traffic analysis is a threat, and I'd fully accept that we should be thinking about ways in which we could make our protocols better against that in general, even if we're not tackling the specific problems of dissidents. For example, if my toilet emits packets with every flush, encryption of any sort isn't going to disguise that so traffic analysis will also be relevant for the Internet-of-Toilets. > If the target is protection against PM within wealthy nations, > then you'd need something that can't be rendered harmless by a modest > budget increase. A number of MITM protection mechanisms have been > suggested (e.g. DANE, channel binding, etc.). But isn't that what the IETF and security folks within the IETF have been aiming for for a couple of decades? I mean aiming for an end-state where we have mutual-auth more-or-less everywhere. I don't consider that we've succeeded wildly to be honest;-) What should we be doing differently is really my question. > Also, in this category > should be mechanisms for protecting privacy against private-sector > adversaries. As long as private companies can amass huge dociers > without resort to PM (or without the need to subvert OS), and are > willing to sell that personal information to third parties (dodgy > ones, let alone governments), one wonders whether government > agencies would make better use of their funds by "buying" > surveillance, rather than trying to "build" it. As it happens we had some discussion about e2e email security in Toronto. Current plan is to start a new mailing list for that - a bunch of us are chatting about how to scope that so we're less likely to mess up. (More on that next week I hope.) Now email is of course just one application (though a cornerstone application). Which other applications/mechanisms should we be considering that'd help here? FWIW, I'm very open to us trying to help anywhere we could credibly do that. (Credibility requiring that stuff be technically doable, be something that should be done in the IETF and have enough warm bodies interested in doing work.) Cheers, S. PS: If you or someone has a specific suggestion for a thing on which we should be working, then maybe these lists are too broad for detailed discussion of that. In such cases, the perpass@ietf.org list is probably a good place to triage whether a topic is one we should try pursue in the IETF. From nobody Sun Aug 24 04:37:25 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F451A891B for ; Sun, 24 Aug 2014 04:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWifr686xpJw for ; Sun, 24 Aug 2014 04:37:18 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A6D1A891A for ; Sun, 24 Aug 2014 04:37:18 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id DC9B56D673; Sun, 24 Aug 2014 07:37:15 -0400 (EDT) Message-ID: <53F9CE6A.9020004@iang.org> Date: Sun, 24 Aug 2014 12:37:14 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53F548E5.2070208@cs.tcd.ie>, <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org>, , <20140823040550.GQ5909@localhost> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/6iWGuWUh-WtC76gnMkOAQdzo38I Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 11:37:20 -0000 Some thoughts. On 23/08/2014 21:27 pm, Bernard Aboba wrote: > Nico said: > >> For me OS is not about anti-PM, or at least not mainly anti-PM. See below. > > [BA] I agree - but IMHO it would be useful if we were clear about this > in problem statement documents. > >>Therefore OS can go a long distance relative to criminals in many > situations. > > [BA] We certainly do have a problem with criminals targeting payment > networks to great effect. However, given the urgency and potential > deployment lags, is OS the most timely potential response to that problem? Payment networks should take greater responsibility already. OS / TCPInc etc isn't for them unless they are lazy. Not a lot we can do about that. >> Sovereign powers will be able to do build active PM systems, no doubt. > > [BA] In many cases (and certainly in the case of virtually all > oppressive regimes), major portions of the Internet infrastructure are > under control of the state. So if the issue is oppressive regimes (and > protection of dissidents), something considerably more comprehensive > than OS is needed (e.g. more along the lines of Tor). Yes. Can't address that comprehensively. But the power of the democratic industries will count for something. Do not slow down just because you haven't got a solution yet for every circumstances. > [nico] But if the end-state for OS is something like DANE > [Huitema] It is also fairly easy for OS conscious applications to use > channel binding schemes and detect the MITM. > > [BA] If we are talking about DANE and channel binding schemes, aren't we > out of the realm of "unauthenticated" opportunistic encryption? For something like TCPInc, it's a ramp, by which we walk up, step by step. 1. add some unauthenticated encryption. 2. have that system spit out some channel binding numbers. 3. wait for apps to decide they can use that, change their code to opportunistically ask for it. You could think of it as versions of the protocol, or phases of a project. You can't get the later phases until the first phase is done, so concentrate on it, with an eye to later requirements. > [IanG] "Agreed on both points. And this is a big win. Because then we > know what they are doing and can provide evidence." > [Ted] This won't help in a totalitarian regime, certainly, but in > democratic societies having law enforcement agencies engaging in mass, > surreptitious surveilance might be less likely to be tolerated. Right. We are going to see some broken eggs in making this omelette. > [BA] AFAIK, the surveillance budget is not a matter of public record in > most nations of the world. And as far as "toleration" in democratic > societies is concerned, are there democratic societies in which there > are comprehensive reform proposals that have a good chance of passage? > Just wondered if I was missing something. It's all secret because in secret they can do anything. Put the sunlight on it, and the mystery is stripped away. Put in encryption everywhere, and force them to attack actively. Once in active attack, sunlight will reveal. Democratic societies only respond to what they can see. Or are told. Or believe. Or fear. Better to show them facts. Totalitarian states are an omelette to a different recipe. iang From nobody Sun Aug 24 07:12:23 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4371A02C2; Sun, 24 Aug 2014 07:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWNYi5LwnQZ4; Sun, 24 Aug 2014 07:12:18 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA711A01F9; Sun, 24 Aug 2014 07:12:17 -0700 (PDT) Received: from 48-136-17-190.fibertel.com.ar ([190.17.136.48] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XLYWg-0001Wu-Ft; Sun, 24 Aug 2014 16:12:10 +0200 Message-ID: <53F9F268.1030407@si6networks.com> Date: Sun, 24 Aug 2014 11:10:48 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Bernard Aboba , Stephen Farrell , Nico Williams References: <53F548E5.2070208@cs.tcd.ie>, <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org>, , <20140823040550.GQ5909@localhost> , <53F8FA97.2020607@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/mzkhMCpnLS1-xnm2v4T26EQsnPg Cc: "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 14:12:20 -0000 On 08/23/2014 06:05 PM, Bernard Aboba wrote: > >> However, say we're wrong and someone who thinks OS is a waste >> of time is actually correct, what would such a person recommend >> that we do as well as, or instead of, OS? > > [BA] It depends on who we are trying to protect, and from what (or whom). > > If the target is protection of dissidents from oppressive regimes, then > you need something much more comprehensive than 'unauthenticated > opportunistic encryption" (e.g. along the lines of Tor). It is quite often the case that, under oppressive regimes, using encryption technology will already flag you as "suspect" (if not "guilty"). So in that case, you'd probably want to use something probably want something more like a cover channel in those scenarios. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Aug 24 09:31:45 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5DD1A8786 for ; Sun, 24 Aug 2014 09:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLx2wAw-SHTH for ; Sun, 24 Aug 2014 09:31:39 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E971A87D4 for ; Sun, 24 Aug 2014 09:31:39 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id D5AC36D637; Sun, 24 Aug 2014 12:31:36 -0400 (EDT) Message-ID: <53FA1367.8020801@iang.org> Date: Sun, 24 Aug 2014 17:31:35 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <53F548E5.2070208@cs.tcd.ie>, <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org>, , <20140823040550.GQ5909@localhost> , <53F8FA97.2020607@cs.tcd.ie> <53F9F268.1030407@si6networks.com> In-Reply-To: <53F9F268.1030407@si6networks.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/q6wfE6ytRxV6H3CZ7O7QtJ02sho Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 16:31:44 -0000 On 24/08/2014 15:10 pm, Fernando Gont wrote: > On 08/23/2014 06:05 PM, Bernard Aboba wrote: >> >>> However, say we're wrong and someone who thinks OS is a waste >>> of time is actually correct, what would such a person recommend >>> that we do as well as, or instead of, OS? >> >> [BA] It depends on who we are trying to protect, and from what (or whom). >> >> If the target is protection of dissidents from oppressive regimes, then >> you need something much more comprehensive than 'unauthenticated >> opportunistic encryption" (e.g. along the lines of Tor). > > It is quite often the case that, under oppressive regimes, using > encryption technology will already flag you as "suspect" (if not > "guilty"). So in that case, you'd probably want to use something > probably want something more like a cover channel in those scenarios. Or, TCPInc which will deploy on mass, rather than by individuals. iang From nobody Sun Aug 24 12:15:52 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8EF1A0683; Sun, 24 Aug 2014 12:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngYjZMGUhV95; Sun, 24 Aug 2014 12:15:47 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8119B1A0679; Sun, 24 Aug 2014 12:15:47 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7OJFWsM028862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 24 Aug 2014 12:15:36 -0700 Message-ID: <53FA3936.6060802@dcrocker.net> Date: Sun, 24 Aug 2014 12:12:54 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Fernando Gont , Bernard Aboba , Stephen Farrell , Nico Williams References: <53F548E5.2070208@cs.tcd.ie>, <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org>, , <20140823040550.GQ5909@localhost> , <53F8FA97.2020607@cs.tcd.ie> <53F9F268.1030407@si6networks.com> In-Reply-To: <53F9F268.1030407@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 24 Aug 2014 12:15:36 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zRL7dCYNBMmMeche51FNoT6eVMs Cc: "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 19:15:49 -0000 On 8/24/2014 7:10 AM, Fernando Gont wrote: > It is quite often the case that, under oppressive regimes, using > encryption technology will already flag you as "suspect" (if not > "guilty"). A premise of trying to move Internet services over to "encrypt everything for everyone" is to eliminate that flag. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Aug 24 13:42:28 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90131A883C; Sun, 24 Aug 2014 13:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztFpq9EYVCrn; Sun, 24 Aug 2014 13:42:25 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6681A87A2; Sun, 24 Aug 2014 13:42:25 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s7OKgIDt016541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 24 Aug 2014 20:42:19 GMT (envelope-from joelja@bogus.com) Message-ID: <53FA4E25.6070700@bogus.com> Date: Sun, 24 Aug 2014 13:42:13 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Thunderbird/32.0 MIME-Version: 1.0 To: Fernando Gont , Bernard Aboba , Stephen Farrell , Nico Williams References: <53F548E5.2070208@cs.tcd.ie>, <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org>, , <20140823040550.GQ5909@localhost> , <53F8FA97.2020607@cs.tcd.ie> <53F9F268.1030407@si6networks.com> In-Reply-To: <53F9F268.1030407@si6networks.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EPkIlonWVHDngsXJE2oQIHaRFD7PVAqu9" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Sun, 24 Aug 2014 20:42:20 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ijLyDi2-jHhtS_2HlSKQYs27AD4 Cc: "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 20:42:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EPkIlonWVHDngsXJE2oQIHaRFD7PVAqu9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/24/14 7:10 AM, Fernando Gont wrote: > On 08/23/2014 06:05 PM, Bernard Aboba wrote: >> >>> However, say we're wrong and someone who thinks OS is a waste >>> of time is actually correct, what would such a person recommend >>> that we do as well as, or instead of, OS? >> >> [BA] It depends on who we are trying to protect, and from what (or who= m). =20 >> >> If the target is protection of dissidents from oppressive regimes, the= n >> you need something much more comprehensive than 'unauthenticated >> opportunistic encryption" (e.g. along the lines of Tor).=20 >=20 > It is quite often the case that, under oppressive regimes, using > encryption technology will already flag you as "suspect" (if not > "guilty"). So in that case, you'd probably want to use something > probably want something more like a cover channel in those scenarios. it's already implausible in many cases to seperate the sheep from the goats. When was the last time you did a google search or accessed a twitter feed in the clear? > Cheers, >=20 --EPkIlonWVHDngsXJE2oQIHaRFD7PVAqu9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlP6TiUACgkQ8AA1q7Z/VrJOawCfRCjlxETtcWM6/S5HbnLB14Hf mDYAn0cH7ewxTRQteM5jbOuug5kxdIQf =DAsq -----END PGP SIGNATURE----- --EPkIlonWVHDngsXJE2oQIHaRFD7PVAqu9-- From nobody Sun Aug 24 16:59:00 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307BE1A88BA; Sun, 24 Aug 2014 16:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ds7EwzUd5zcO; Sun, 24 Aug 2014 16:58:52 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3841A88B8; Sun, 24 Aug 2014 16:58:51 -0700 (PDT) Received: from 48-136-17-190.fibertel.com.ar ([190.17.136.48] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XLhgN-0003uG-8k; Mon, 25 Aug 2014 01:58:47 +0200 Message-ID: <53FA7BE8.3070307@si6networks.com> Date: Sun, 24 Aug 2014 20:57:28 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: joel jaeggli , Bernard Aboba , Stephen Farrell , Nico Williams References: <53F548E5.2070208@cs.tcd.ie>, <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org>, , <20140823040550.GQ5909@localhost> , <53F8FA97.2020607@cs.tcd.ie> <53F9F268.1030407@si6networks.com> <53FA4E25.6070700@bogus.com> In-Reply-To: <53FA4E25.6070700@bogus.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4zUsZYD0SbM4TzsYI0zoPdhiua0 Cc: "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 23:58:54 -0000 On 08/24/2014 05:42 PM, joel jaeggli wrote: > On 8/24/14 7:10 AM, Fernando Gont wrote: >> On 08/23/2014 06:05 PM, Bernard Aboba wrote: [...] >> >> It is quite often the case that, under oppressive regimes, using >> encryption technology will already flag you as "suspect" (if not >> "guilty"). So in that case, you'd probably want to use something >> probably want something more like a cover channel in those >> scenarios. > > it's already implausible in many cases to seperate the sheep from > the goats. > > When was the last time you did a google search or accessed a > twitter feed in the clear? Good luck explaining that to the oppressive regime. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Aug 24 17:09:48 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55621A88BD; Sun, 24 Aug 2014 17:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vr65BasrR6o; Sun, 24 Aug 2014 17:09:44 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009DE1A88BF; Sun, 24 Aug 2014 17:09:43 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s7P09ViU017408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 Aug 2014 00:09:32 GMT (envelope-from joelja@bogus.com) Message-ID: <53FA7EB7.60207@bogus.com> Date: Sun, 24 Aug 2014 17:09:27 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Thunderbird/32.0 MIME-Version: 1.0 To: Fernando Gont , Bernard Aboba , Stephen Farrell , Nico Williams References: <53F548E5.2070208@cs.tcd.ie>, <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org>, , <20140823040550.GQ5909@localhost> , <53F8FA97.2020607@cs.tcd.ie> <53F9F268.1030407@si6networks.com> <53FA4E25.6070700@bogus.com> <53FA7BE8.3070307@si6networks.com> In-Reply-To: <53FA7BE8.3070307@si6networks.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nhr0TAGLKsCGE7UqtAPCQkjejFCp0fcSK" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 25 Aug 2014 00:09:32 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HS-KvBvK2dahDSjyUxpfq7sdiR4 Cc: "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 00:09:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Nhr0TAGLKsCGE7UqtAPCQkjejFCp0fcSK Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8/24/14 4:57 PM, Fernando Gont wrote: > On 08/24/2014 05:42 PM, joel jaeggli wrote: >> On 8/24/14 7:10 AM, Fernando Gont wrote: >>> On 08/23/2014 06:05 PM, Bernard Aboba wrote: > [...] >>> >>> It is quite often the case that, under oppressive regimes, using=20 >>> encryption technology will already flag you as "suspect" (if not=20 >>> "guilty"). So in that case, you'd probably want to use something=20 >>> probably want something more like a cover channel in those >>> scenarios. >> >> it's already implausible in many cases to seperate the sheep from >> the goats. >> >> When was the last time you did a google search or accessed a >> twitter feed in the clear? >=20 > Good luck explaining that to the oppressive regime. I don't have to. They are aware for example that all twitter api calls had a deadline over ssl since jan 1 2014. You cannot distinguish the intentions of the user by their (involuntary) use of encryption. --Nhr0TAGLKsCGE7UqtAPCQkjejFCp0fcSK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlP6frcACgkQ8AA1q7Z/VrKIdgCZAe95XhdSs0+be0WtiABIDYt8 LvkAn3GYYjd/amES1HTFSqoWJmty5fz+ =KwmS -----END PGP SIGNATURE----- --Nhr0TAGLKsCGE7UqtAPCQkjejFCp0fcSK-- From nobody Sun Aug 24 17:56:14 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D361A88D5; Sun, 24 Aug 2014 17:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmT8s8Z0YHfJ; Sun, 24 Aug 2014 17:56:04 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA4F01A88D1; Sun, 24 Aug 2014 17:56:03 -0700 (PDT) Received: from 48-136-17-190.fibertel.com.ar ([190.17.136.48] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XLiZl-00041F-Hh; Mon, 25 Aug 2014 02:56:01 +0200 Message-ID: <53FA8995.3050609@si6networks.com> Date: Sun, 24 Aug 2014 21:55:49 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: joel jaeggli , Bernard Aboba , Stephen Farrell , Nico Williams References: <53F548E5.2070208@cs.tcd.ie>, <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org>, , <20140823040550.GQ5909@localhost> , <53F8FA97.2020607@cs.tcd.ie> <53F9F268.1030407@si6networks.com> <53FA4E25.6070700@bogus.com> <53FA7BE8.3070307@si6networks.com> <53FA7EB7.60207@bogus.com> In-Reply-To: <53FA7EB7.60207@bogus.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/BAxH7vWP4xhGj4eQ8QaXbR5fNrc Cc: "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 00:56:06 -0000 On 08/24/2014 09:09 PM, joel jaeggli wrote: > On 8/24/14 4:57 PM, Fernando Gont wrote: >> On 08/24/2014 05:42 PM, joel jaeggli wrote: >>> On 8/24/14 7:10 AM, Fernando Gont wrote: >>>> On 08/23/2014 06:05 PM, Bernard Aboba wrote: [...] >> >> Good luck explaining that to the oppressive regime. > > I don't have to. They are aware for example that all twitter api calls > had a deadline over ssl since jan 1 2014. You cannot distinguish the > intentions of the user by their (involuntary) use of encryption. I suggest you talk to someone that's suffering from an oppressive regime (both in terms of the stuff that they suffer, and what their regimes are supposedly aware of). My response is based on the lesson that I learned when I offered (a few years ago) one of such folks an encrypted tunnel such that they could avoid both censorship and monitoring. Any technical explanation that you can give (no matter how correct or true it is) is of no use if the guy suffering from an oppressive regime is still going to have a hard time with their regime. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Aug 24 19:36:33 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F72D1A89C5; Sun, 24 Aug 2014 19:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWcWjeBQO91n; Sun, 24 Aug 2014 19:36:29 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26CCF1A88CE; Sun, 24 Aug 2014 19:36:29 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 7C5C51FCB20; Mon, 25 Aug 2014 02:36:25 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id EBBE1160057; Mon, 25 Aug 2014 02:48:00 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id BB01C160056; Mon, 25 Aug 2014 02:48:00 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A28411D724E3; Mon, 25 Aug 2014 12:36:19 +1000 (EST) To: Eric Burger From: Mark Andrews References: <53F548E5.2070208@cs.tcd.ie>, <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org>, , <20140823040550.GQ5909@localhost> , <53F8FA97.2020607@cs.tcd.ie> <53F908A1.6040207@cs.tcd.ie> <8BBAE4BE-F816-4170-9533-6400ACE463EA@cs.georgetown.edu> <6461D9C5-8B0B-42D3-9877-32DB3E6150C6@standardstrack.com> In-reply-to: Your message of "Sun, 24 Aug 2014 12:32:15 -0400." <6461D9C5-8B0B-42D3-9877-32DB3E6150C6@standardstrack.com> Date: Mon, 25 Aug 2014 12:36:19 +1000 Message-Id: <20140825023619.A28411D724E3@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/saag/WoDamwx1UdcJOM_f1sXZir2i1nI Cc: "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] Is traffic analysis really a target (was Re: Is opportunistic unauthenticated encryption a waste of time?) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 02:36:30 -0000 In message <6461D9C5-8B0B-42D3-9877-32DB3E6150C6@standardstrack.com>, Eric Burger writes: > > I am concerned with the drive to make all traffic totally opaque. I'll be > brief: we have an existence proof of the mess that happens when we make > all traffic look benign. It is called "everything over port 80." That > `practical' approach drove the development of deep packet inspection, > because everything running over port 80 was no longer HTTP traffic. It > meant we could no longer prioritize traffic (in a good sense - *I* want > to make sure my VoIP gets ahead of my Web surfing ahead of my FTP). It > meant we could no longer apply enterprise policy on different > applications. It drove `investment' in the tools that today dominate > pervasive monitoring. > > Good job folks for unintended consequences. And everyone went to port 80 because people put up blocks for other ports often for no other reason than "we can". You have idiots with firewalls blocking access to submission yet allowing access to webmail services. You have idiots with firewalls blocking access to imaps/pops yet allowing access to webmail services. You have idiots with firewalls blocking access to ... yet allowing https through. As for VIOP traffic, have the originating device set TOS/TCLASS. It really isn't that hard having set both TOS and TCLASS in the application sometimes on a per packet basis. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Aug 24 20:11:00 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9481A89DE; Sun, 24 Aug 2014 20:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsPBK8WcW1gU; Sun, 24 Aug 2014 20:10:56 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370E91A89DB; Sun, 24 Aug 2014 20:10:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 5E75BDFB6; Sun, 24 Aug 2014 23:10:53 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyQ+QTRIneUL; Sun, 24 Aug 2014 23:10:52 -0400 (EDT) Received: from [172.20.12.170] (unknown [12.206.184.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 9142DDF9B; Sun, 24 Aug 2014 23:10:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: Date: Sun, 24 Aug 2014 23:10:50 -0400 Content-Transfer-Encoding: 7bit Message-Id: <514639A6-9EBA-48EE-8C5A-DEA90AFEFDA6@oxy.edu> References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com> <53EEA46F.80006@bbiw.net> <20140816200706.GA8110@localhost> <53F26D8A.1050304@bbn.com> <53F27065.9030902@cs.tcd.ie> <53F36E34.7020701@bbn.com> <53F36FB1.4020008@cs.tcd.ie> <53F371CC.7020106@dcrocker.net> <53F376BF.6080701@bbn.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/eTzyd3vdnonIHsWqVxaGRnMHhi8 Cc: saag@ietf.org, "ietf@ietf.org" Subject: Re: [saag] Protocol Design Pattern (was Re: Last Call: ) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 03:10:57 -0000 On Aug 22, 2014, at 3:30 PM, Benjamin Kaduk wrote: > I forget if I have opined on the list about OS vs. OCS or OE or other > terms already, but I will just say that I prefer OS over any of the other > proposals I have seen. +1 Personal email. hbhotz@oxy.edu From nobody Sun Aug 24 22:22:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25601A8A1F; Sun, 24 Aug 2014 22:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGFIBkpHA6_1; Sun, 24 Aug 2014 22:22:07 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D136A1A8A15; Sun, 24 Aug 2014 22:22:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 0A3B1DFB9; Mon, 25 Aug 2014 01:22:05 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzpUXRalMMIN; Mon, 25 Aug 2014 01:22:04 -0400 (EDT) Received: from [172.20.12.170] (unknown [12.206.184.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 05781DFB4; Mon, 25 Aug 2014 01:22:03 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: <20140825023619.A28411D724E3@rock.dv.isc.org> Date: Mon, 25 Aug 2014 01:22:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9E04F9BB-BEAD-4B97-B07A-0A3A4E5ADF69@oxy.edu> References: <53F548E5.2070208@cs.tcd.ie>, <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org>, , <20140823040550.GQ5909@localhost> , <53F8FA97.2020607@cs.tcd.ie> <53F908A1.6040207@cs.tcd.ie> <8BBAE4BE-F816-4170-9533-6400ACE463EA@cs.georgetown.edu> <6461D9C5-8B0B-42D3-9877-32DB3E6150C6@standardstrack.com> <20140825023619.A28411D724E3@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Zgz1uX7AXjw_ZttjlIJcIUvfSg4 Cc: "saag@ietf.org" , Eric Burger , "ietf@ietf.org" Subject: Re: [saag] Is traffic analysis really a target (was Re: Is opportunistic unauthenticated encryption a waste of time?) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 05:22:09 -0000 On Aug 24, 2014, at 10:36 PM, Mark Andrews wrote: > In message <6461D9C5-8B0B-42D3-9877-32DB3E6150C6@standardstrack.com>, = Eric Burger writes: >=20 >> we have an existence proof of the mess that happens when we make >> all traffic look benign. By its nature all non-benign traffic will want to *look* benign. What makes me sad are the idiots with firewalls blocking access to all = traffic other than TCP and UDP. We keep trying to make ourselves secure = by limiting the standards support of the network instead of using a mix = of techniques (defense in depth). Sorry. Preaching to the choir I=92m sure. Personal email. hbhotz@oxy.edu From nobody Mon Aug 25 01:09:16 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019881A6FEB; Mon, 25 Aug 2014 01:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMe-dpjJya4C; Mon, 25 Aug 2014 01:09:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6575B1A0047; Mon, 25 Aug 2014 01:09:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIR88849; Mon, 25 Aug 2014 08:09:08 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.03.0158.001; Mon, 25 Aug 2014 09:09:05 +0100 From: Hosnieh Rafiee To: "saag@ietf.org" , "ietf@ietf.org" Thread-Topic: [saag] Is opportunistic unauthenticated encryption a waste of time? Thread-Index: AQHPvhF6o3esl+HxrEicw4IqjGmjzJvdYuAAgAAfSACAARJeAIAAAY+AgAAI2YCAAR6TAIABN0BA Date: Mon, 25 Aug 2014 08:09:04 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A290F5@lhreml513-mbb.china.huawei.com> References: <53F548E5.2070208@cs.tcd.ie>, <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org>, , <20140823040550.GQ5909@localhost> , <53F8FA97.2020607@cs.tcd.ie> <53F9F268.1030407@si6networks.com> In-Reply-To: <53F9F268.1030407@si6networks.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/saag/GNAgsLnTB5SzEUyNZrjqEYSo_5o Subject: Re: [saag] Is opportunistic unauthenticated encryption a waste of time? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 08:09:12 -0000 > It is quite often the case that, under oppressive regimes, using > encryption technology will already flag you as "suspect" (if not > "guilty"). So in that case, you'd probably want to use something > probably want something more like a cover channel in those scenarios. >=20 To some extend I agree with Fernando since I have the practical experience = of such places. To be clear, if the purpose of the encryption is to avoid s= uch places to access users' data or try to harden this process, actually it= fails because the users force to use their devices and the main internet s= tream to those countries passed by their devices (where all traffic filtere= d and analyses and then sent to the users). Therefore, you cannot help them= , especially, if you're talking about unauthenticated source of data. When = OS or other ways try to help to authenticate this data, then maybe you can = be 1% successful. Because this also helps that the users do not recognize t= his MITM attack. They can recognize this when they receive any warning mess= age. (I am not talking about professional users that might trace their traf= fic. But about 80% of internet users.) Nevertheless, In my opinion, encryption, in general, is good. But it depend= s on what our target users or services are and who we want to hide this tra= ffic from. Whether those people have access to the main internet stream and= the user have no way to avoid them? Whether they have a power to apply reg= ulation for internet in a country and user MUST follow them? Or whether the= y only want to sniff data passively in a way that user do not recognize it.= In last case, encryption conditionally can be successful but I do not thin= k it works in the first two cases.=20 The conditions are that 1- whether those places can be easily recognized if= they do active attacks? (it might be yes if they want to do this attack wi= th the whole internet data stream that belongs to different countries but t= his is not true if it is only a small portion of traffic such as an enterpr= ise or etc.) I hope that I could explain my point clearly. Best, Hosnieh=20 From nobody Mon Aug 25 11:21:07 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349451A0267 for ; Mon, 25 Aug 2014 11:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVROZE-UgAP6 for ; Mon, 25 Aug 2014 11:20:58 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1191A0263 for ; Mon, 25 Aug 2014 11:20:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AB85DBDD8 for ; Mon, 25 Aug 2014 19:20:42 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPO-S390e3GI for ; Mon, 25 Aug 2014 19:20:41 +0100 (IST) Received: from [10.87.48.7] (unknown [86.41.56.186]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 546ACBDD7 for ; Mon, 25 Aug 2014 19:20:41 +0100 (IST) Message-ID: <53FB7E79.3040608@cs.tcd.ie> Date: Mon, 25 Aug 2014 19:20:41 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "saag@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/G1VArnZMU8NpOqId6okX6uOn4fU Subject: [saag] new list for discussion of end-to-end email security/privacy improvements X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 18:21:00 -0000 Hi all, Following on from discussion in Toronto in appaswg and saag, and a subsequent request, we've created a mailing list for discussing this topic. Pete Resnick and I will initially manage the list. If you're interested, please subscribe. Once Pete and I figure there's a good enough set of folks subscribed we'll fire off a starter email. That usually takes a few days, so probably Wed-Thu this week. The list [1] description is: There is significant interest in improving the privacy-related properties of Internet mail. One focus of current efforts is on the per-hop (connection-based) protections provided by TLS. However a wide range of other work has a focus on end-to-end protection, at the Internet scale of billions of end users and perhaps millions of operators. Such work typically involves new forms of mail header or body protection, new public key management (compared to S/MIME or PGP), and security mechanisms more appropriate for mobile/web user-agents. Other security-relevant approaches may be discussed if needed. Various proposals and development efforts on this topic are underway outside the IETF. This mailing list provides an IETF venue for discussion of elements that might be commonly needed by such efforts and to identify work that the IETF could do to aid in achieving better end-to-end security deployed for Internet email. Cheers, S. [1] https://www.ietf.org/mailman/listinfo/endymail From nobody Mon Aug 25 22:44:12 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA251A0487; Mon, 25 Aug 2014 22:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXaRl5x8N7j6; Mon, 25 Aug 2014 22:44:10 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C388C1A03EA; Mon, 25 Aug 2014 22:44:10 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 2F13C20047B88; Mon, 25 Aug 2014 22:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=UEOORRp4rCFPgq7oeMO1rioRqaQ=; b=vKqE+DXxaGV xnzByc0QTi+AJt1QjIupKRBezJ86dqWmY7GvRwRxf/QzHjgZYuyGZVREkJHRILWw vrrzLO62TUzJ9gRtovE0WzTZImhN/OIGGl9E/SYGjaAmZJor1lcc28y7FxVyOlHv AahuDtVcyRDQUpbZWV3+KCpVBpPSDg6Q= Received: from localhost (unknown [38.125.62.68]) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id C428D20047B89; Mon, 25 Aug 2014 22:44:09 -0700 (PDT) Date: Tue, 26 Aug 2014 00:44:08 -0500 From: Nico Williams To: Eric Burger Message-ID: <20140826054406.GA20264@localhost> References: <20140822140000.GE14392@mournblade.imrryr.org> <20140823040550.GQ5909@localhost> <53F8FA97.2020607@cs.tcd.ie> <53F908A1.6040207@cs.tcd.ie> <8BBAE4BE-F816-4170-9533-6400ACE463EA@cs.georgetown.edu> <6461D9C5-8B0B-42D3-9877-32DB3E6150C6@standardstrack.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6461D9C5-8B0B-42D3-9877-32DB3E6150C6@standardstrack.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/saag/bQSlpBmmxeVXay3HMGpiKkSI7XU Cc: "saag@ietf.org" , "ietf@ietf.org" Subject: Re: [saag] Is traffic analysis really a target (was Re: Is opportunistic unauthenticated encryption a waste of time?) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 05:44:11 -0000 On Sun, Aug 24, 2014 at 12:32:15PM -0400, Eric Burger wrote: > I am concerned with the drive to make all traffic totally opaque. > I=E2=80=99l be brief: we have an existence proof of the mess that happe= ns > when we make all traffic look benign. It is called =E2=80=9Ceverything = over > port 80.=E2=80=9D That =E2=80=98practical=E2=80=99 approach drove the d= evelopment of deep Benign? No, that's not it. Ports 80 and 443 (*not* just 80) are used for everything for a variety of reasons, one of which is that no one could block them entirely, so every site with a firewall simply had to have the capability to, and processes for permitting HTTP/HTTPS traffic -- they could NOT afford not to! Whereas protocols on other ports... See below. > packet inspection, because everything running over port 80 was no > longer HTTP traffic. It meant we could no longer prioritize traffic > (in a good sense - *I* want to make sure my VoIP gets ahead of my Web > surfing ahead of my FTP). It meant we could no longer apply enterprise > policy on different applications. It drove =E2=80=98investment=E2=80=99= in the tools > that today dominate pervasive monitoring. It's true that using HTTP as the IP of the 'Net hurt all sorts of things, but it was driven by the massive adoption of HTTP. Remember the term "application gateway"? What a throwback to the late 80s, early 90s. Application gateways are unheard of now because they're ETOOHARD. Firewalls can't cope with a raft of arbitrary, custom protocols, whether over IP or over HTTP, but with HTTP they get somewhat more metadata to examine. If you really want to draw a lesson here it is this: application protocols need a firewall-friendly substrate of metadata. That's HTTP -- no other such substrate exists. Sure, it's a bit of a mirage: the HTTP metadata can be faked. But at least with HTTP the firewalls^Wproxies can make sure to get hostnames every time, not just IP addresses. That's my take. Maybe it's wrong, but it seems at least plausible. If VoIPs and such used different port numbers but still HTTP... they'd get through firewalls eventually and you could get your traffic prioritization. It's not so much ports 80/443 that matter. It's the HTTP headers request line, status line, and headers that do. You could do WebSockets or otherwise tunnel anything over HTTP and the firewalls will be happy to let you, IF they like your metadata. Nico --=20 From nobody Tue Aug 26 03:12:17 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570821A6F1D for ; Tue, 26 Aug 2014 03:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zZHkRSpz5kK for ; Tue, 26 Aug 2014 03:12:10 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 55D1D1A6F14 for ; Tue, 26 Aug 2014 03:12:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1761FBDFC for ; Tue, 26 Aug 2014 11:12:09 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cj6w472EOxr for ; Tue, 26 Aug 2014 11:12:08 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E8034BDFB for ; Tue, 26 Aug 2014 11:12:08 +0100 (IST) Message-ID: <53FC5D78.2030206@cs.tcd.ie> Date: Tue, 26 Aug 2014 11:12:08 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <20140826095923.19894.44221.idtracker@ietfa.amsl.com> In-Reply-To: <20140826095923.19894.44221.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140826095923.19894.44221.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/YN3AhfbLcRtHcnN1ER2XdC1dfWs Subject: [saag] Fwd: Evaluation: to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 10:12:14 -0000 Hi all, I've put Viktor's draft on the IESG telechcat for Sep 4th. As an experiment, I've added this list to the set of email addresses that will get notifications. That means that IESG comments and discuss points and any haggling that happens between IESG folk, authors and shepherds will be cc'd to this list. A couple of notes about that: - Please don't respond unless you really must. The IESG will make comments some of which may be repeats from earlier discussion etc. That's just fine and you should leave it to the sponsoring AD (me in this case), the shepherd and authors to handle that. One good reason to not have loads of responses will be that this will be just one of a dozen or so similar conversations about drafts that are going on in parallel for that IESG telechat, so its best if we can try to keep the mails to stuff that really really needs to be said. - Please let Kathleen and I know if you think its useful to see these mails (not now, but afterwards:-). I think for AD sponsored stuff it might be good to provide some transparency for any changes that get suggested during IESG evaluation. We plan to also start cc'ing WG lists in future - the IESG figure that that's probably a good idea, and it seems to work ok for APPS WGs where its been tried. (To be honest I meant to try that out before but forgot - will next time though;-) Thanks, Stephen. -------- Forwarded Message -------- Subject: Evaluation: to Informational RFC Date: Tue, 26 Aug 2014 02:59:23 -0700 From: IESG Secretary Reply-To: IESG Secretary To: Internet Engineering Steering Group Evaluation for can be found at http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ Last call to expire on: 2014-08-05 00:00 Please return the full line with your position. Yes No-Objection Discuss Abstain Stephen Farrell [ X ] [ ] [ ] [ ] Has enough positions to pass. DISCUSSES AND COMMENTS ====================== ---- following is a DRAFT of message to be sent AFTER approval --- From: The IESG To: IETF-Announce Cc: RFC Editor Subject: Document Action: 'Opportunistic Security: some protection most of the time' to Informational RFC (draft-dukhovni-opportunistic-security-01.txt) The IESG has approved the following document: - 'Opportunistic Security: some protection most of the time' (draft-dukhovni-opportunistic-security-01.txt) as Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ Technical Summary This document defines the concept "Opportunistic Security" in the context of communications protocols. Protocol designs based on Opportunistic Security remove barriers to the widespread use of encryption on the Internet by using encryption even when authentication is not available, and using authentication when Working Group Summary This is an AD sponsored document and not the product of a WG. It was extensively debated on the saag list and during an extended IETF LC. The concept was also debated at the STRINT workshop. The shepherd write-up has more to say: "The document and its predecessors were discussed with great gusto over many months on the SAAG mailing list, in the UTA WG, and at two IETF meetings. There is a great deal of interest in having a common set of definitions for the ideas related ot opportunistic security, even where there might be disagreement about where it should and should not be used. The IETF Last Call on the -03 draft produced a lot of suggestions for major improvements to the language in the draft, and the author did a significant revision based on them, all without changing the design philosophy. There are probably still some people who think that the wording is not what they would want, and some who think that the whole idea is a bad one, but there was rough consensus that the document was useful and should be published. The document has had more review, and ended up getting stronger consensus for the eventual definition, than the products of many security WGs. Because this document does not define how to implement opportunistic security, there is some disagreement about its applicability to existing and future IETF protocols, but there was strong agreement that the definition was good enough for many protocols." Document Quality One would not directly implement this as its a design pattern. There are Internet-drafts that are using this already in DANE, HTTPBIS and some individual drafts. Personnel Paul Hoffman is the document shepherd. Stephen Farrell is the irresponsible AD. RFC Editor Note (Insert RFC Editor Note here or remove section) IRTF Note (Insert IRTF Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note There is no IANA considerations section and no need for one. It'll be interesting to see if this note gets noticed or if folks complain about the lack of a redundant section. I hope the former and not the latter:-) From nobody Tue Aug 26 03:21:28 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91211A6F1D for ; Tue, 26 Aug 2014 03:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6a2BwVQSfctx for ; Tue, 26 Aug 2014 03:21:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE3A1A6F14 for ; Tue, 26 Aug 2014 03:21:20 -0700 (PDT) Received: from [172.16.254.100] ([80.92.114.249]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LzKmP-1WIaR40CRt-014Utc for ; Tue, 26 Aug 2014 12:21:19 +0200 Message-ID: <53FC5F9F.6060501@gmx.net> Date: Tue, 26 Aug 2014 12:21:19 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: saag References: <53F88813.8060403@gmx.net> In-Reply-To: <53F88813.8060403@gmx.net> OpenPGP: id=4D776BC9 X-Forwarded-Message-Id: <53F88813.8060403@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KvCS6NbSahv8gw8RHwi4DTXoR3Q7qAwcK" X-Provags-ID: V03:K0:NiqTeWwi+44DYaWSq5tzqra/YHa2fp9eOwyvUfLtYu7lvfJPqxU xJQxmUn5kK80ONVQjoSx7EbZdeGFHFmSkjgTmfNWlp+7ZpXVCf5yxiZQV8F4QDxUBdIPEnW 1GCjDKKMr0IKTF7SlXJkfZRrkWje64o4vwlwLkW3fc722RGeDuYVKMYZci8CpS7AdxxNsmC ZbSQCQ8z1YzyoptelZFYw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/saag/6E3tbEqnJ1pSifdjbRSkVI5HvG4 Subject: [saag] Fwd: [Ace] Webex Conference Call about "How to Select Hardware for IoT Systems?" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 10:21:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KvCS6NbSahv8gw8RHwi4DTXoR3Q7qAwcK Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable FYI: In case you are not on the ACE mailing list and still interested in these types of discussions. Needless to say that security protocols consume a fair part of the available resources on an IoT platform. -------- Forwarded Message -------- Subject: [Ace] Webex Conference Call about "How to Select Hardware for IoT Systems?" Date: Sat, 23 Aug 2014 14:24:51 +0200 From: Hannes Tschofenig To: Ace@ietf.org Hi all, Various groups in the IETF currently standardize technology for use with constrained devices and the choice of hardware impacts the design of Internet of Things (IoT) systems. To provide guidance RFC 7228 "Terminology for Constrained-Node Networks" defines three classes of devices depending on their RAM and flash memory size. Class 0 characterizes devices that have less than 10 KiB of RAM and less than 100 KiB of flash memory and RFC 7228 adds "... most likely they will not have the resources required to communicate directly with the Internet in a secure manner." For others even class 2 with ~ 50 KiB of RAM and ~ 250 KiB of flash memory is too constrained. With the increasing commercial interest in IoT the question about a reasonable hardware configuration surfaces again and again. At IETF#90 I offered to bring a hardware expert along. Peter Aldworth, a hardware engineer with more than 19 years of experience, will lead the discussion at an upcoming webinar. Please indicate your availability here: http://moreganize.com/bzTrVxhqaHp Ciao Hannes --KvCS6NbSahv8gw8RHwi4DTXoR3Q7qAwcK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJT/F+fAAoJEGhJURNOOiAtRn4H/1mEUxX6kVSm50UY/1ecztYW IdA9kz9HHzokSYuSVvpzNtHnmE62xy41DmLZQwFaDh4yZmpYUGixuAA28tNG0J+n 8pYgaTSd33R/w0sBe4NN8RljoNWKUGTPGHlZSftGaUUMW4QT5Hkp/sEAjw7cC9WP sGfzkPZ39/LzkDFhLAbC6YOS0JMyvis03AGG3JBSFoqnPzkyAMBvUFYmW6OnuMF/ 47G+q/3FkPyz0r7JKTHimV+CtcIPap22K11oqhY2/HFbS6Mjqo/Kv50ZHilatvTk GavTwMjR7JzTDSXf9vFaBETRFz3FLdUy5zFYNa8HuEs2vR9Cz/5eqClGuz6VdW8= =DC0L -----END PGP SIGNATURE----- --KvCS6NbSahv8gw8RHwi4DTXoR3Q7qAwcK-- From nobody Tue Aug 26 04:58:22 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A9E1A6FA0 for ; Tue, 26 Aug 2014 04:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcGVAMTZfc4X for ; Tue, 26 Aug 2014 04:58:20 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7021A6F86 for ; Tue, 26 Aug 2014 04:58:19 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id CF35A6D74A; Tue, 26 Aug 2014 07:58:15 -0400 (EDT) Message-ID: <53FC7657.8060309@iang.org> Date: Tue, 26 Aug 2014 12:58:15 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140822140000.GE14392@mournblade.imrryr.org> <20140823040550.GQ5909@localhost> <53F8FA97.2020607@cs.tcd.ie> <53F908A1.6040207@cs.tcd.ie> <8BBAE4BE-F816-4170-9533-6400ACE463EA@cs.georgetown.edu> <6461D9C5-8B0B-42D3-9877-32DB3E6150C6@standardstrack.com> <20140826054406.GA20264@localhost> In-Reply-To: <20140826054406.GA20264@localhost> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ggf0zt2zggtz4oWuEf4GU_eQnsA Subject: Re: [saag] Is traffic analysis really a target (was Re: Is opportunistic unauthenticated encryption a waste of time?) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 11:58:21 -0000 > On Sun, Aug 24, 2014 at 12:32:15PM -0400, Eric Burger wrote: >> I am concerned with the drive to make all traffic totally opaque. >> I’l be brief: we have an existence proof of the mess that happens >> when we make all traffic look benign. It is called “everything over >> port 80.†That ‘practical’ approach drove the development of deep >> packet inspection, because everything running over port 80 was no >> longer HTTP traffic. This is more a corporate concern, whereas PM is more of an individual concern. Whatever you think of that particular tussle of corporate v. individual, and noted that the IETF prioritises one over the other, the corporate world is changing again: it's becoming BYOD. In a world of BYOD, there isn't really any sense in worrying too much about the port 80 syndrome, because users will bypass the entire local net if they need to. >> It meant we could no longer prioritize traffic >> (in a good sense - *I* want to make sure my VoIP gets ahead of my Web >> surfing ahead of my FTP). If we were to move all TCP & UDP traffic to opacity, to use the term, then I'm pretty sure there would be QOS methods developed to cope, or users would purchase fatter deals to get their VOIP through. It all comes out in the wash. >> It meant we could no longer apply enterprise >> policy on different applications. It drove ‘investment’ in the tools >> that today dominate pervasive monitoring. Yup, actions have reactions. We're dealing with the consequences of too much success, not a lot of point bemoaning old assumptions & mistakes. iang From nobody Tue Aug 26 08:04:57 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82621A87DE; Sun, 24 Aug 2014 09:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbGRHCl9F6Sw; Sun, 24 Aug 2014 09:32:20 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD341A87D8; Sun, 24 Aug 2014 09:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=BS59WOAmZ2c+sFSj1Uic9/+2QAh99p2Xq9rC7186mNQ=; b=PExcF+A3Y+txDfQM+GMl46dxcwRW5mL/CIaINa/lQyqecJyZznO7Rz3JUrWUE2soXu4cIjan7IwOc5nS9x/3VhWc+sq5JBaT1gYYck/MNsuKkLA9Jktk14tbVqBbjXiaQFFoMrwLU3hTzvyaNnkfR3UukbdgOV2E9fG90qActrY=; Received: from ip68-100-74-115.dc.dc.cox.net ([68.100.74.115]:65007 helo=[192.168.15.115]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XLaiA-0004Hu-M4; Sun, 24 Aug 2014 09:32:19 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_40791B45-E040-4BB9-995F-94F15C92BF80"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Eric Burger In-Reply-To: <8BBAE4BE-F816-4170-9533-6400ACE463EA@cs.georgetown.edu> Date: Sun, 24 Aug 2014 12:32:15 -0400 Message-Id: <6461D9C5-8B0B-42D3-9877-32DB3E6150C6@standardstrack.com> References: <53F548E5.2070208@cs.tcd.ie>, <53F54F1C.1060405@dcrocker.net>, <53F5D303.1090400@cs.tcd.ie>, , <20140821160402.GT14392@mournblade.imrryr.org>, , , , <20140822140000.GE14392@mournblade.imrryr.org>, , <20140823040550.GQ5909@localhost> , <53F8FA97.2020607@cs.tcd.ie> <53F908A1.6040207@cs.tcd.ie> <8BBAE4BE-F816-4170-9533-6400ACE463EA@cs.georgetown.edu> To: "saag@ietf.org" X-Mailer: Apple Mail (2.1878.6) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/saag/vqJbD9_EHaoAn8Li8MU7zgWO_ck X-Mailman-Approved-At: Tue, 26 Aug 2014 08:04:55 -0700 Cc: "ietf@ietf.org" Subject: Re: [saag] Is traffic analysis really a target (was Re: Is opportunistic unauthenticated encryption a waste of time?) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 16:32:22 -0000 --Apple-Mail=_40791B45-E040-4BB9-995F-94F15C92BF80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I am concerned with the drive to make all traffic totally opaque. I=92ll = be brief: we have an existence proof of the mess that happens when we = make all traffic look benign. It is called =93everything over port 80.=94 = That =91practical=92 approach drove the development of deep packet = inspection, because everything running over port 80 was no longer HTTP = traffic. It meant we could no longer prioritize traffic (in a good sense = - *I* want to make sure my VoIP gets ahead of my Web surfing ahead of my = FTP). It meant we could no longer apply enterprise policy on different = applications. It drove =91investment=92 in the tools that today dominate = pervasive monitoring. Good job folks for unintended consequences. On Aug 23, 2014, at 5:33 PM, Stephen Farrell = wrote: >=20 > Hiya, >=20 > On 23/08/14 22:05, Bernard Aboba wrote: >> Stephen Farrell: >>> However, say we're wrong and someone who thinks OS is a waste of >>> time is actually correct, what would such a person recommend that >>> we do as well as, or instead of, OS? >>=20 >> [BA] It depends on who we are trying to protect, and from what (or >> whom).=20 >=20 > Sure. >=20 >> If the target is protection of dissidents from oppressive >> regimes, then you need something much more comprehensive than >> 'unauthenticated opportunistic encryption" (e.g. along the lines of >> Tor).=20 >=20 > Right. That's a hard target and involves far more than crypto, > whether OS or not. >=20 > One thing clearly involved there is that traffic analysis is > a threat, and I'd fully accept that we should be thinking about > ways in which we could make our protocols better against that > in general, even if we're not tackling the specific problems of > dissidents. For example, if my toilet emits packets with every > flush, encryption of any sort isn't going to disguise that so > traffic analysis will also be relevant for the Internet-of-Toilets. >=20 >> If the target is protection against PM within wealthy nations, >> then you'd need something that can't be rendered harmless by a modest >> budget increase. A number of MITM protection mechanisms have been >> suggested (e.g. DANE, channel binding, etc.).=20 >=20 > But isn't that what the IETF and security folks within the > IETF have been aiming for for a couple of decades? I mean aiming > for an end-state where we have mutual-auth more-or-less everywhere. > I don't consider that we've succeeded wildly to be honest;-) >=20 > What should we be doing differently is really my question. >=20 >> Also, in this category >> should be mechanisms for protecting privacy against private-sector >> adversaries. As long as private companies can amass huge dociers >> without resort to PM (or without the need to subvert OS), and are >> willing to sell that personal information to third parties (dodgy >> ones, let alone governments), one wonders whether government >> agencies would make better use of their funds by "buying" >> surveillance, rather than trying to "build" it. >=20 > As it happens we had some discussion about e2e email security in > Toronto. Current plan is to start a new mailing list for that - a > bunch of us are chatting about how to scope that so we're less > likely to mess up. (More on that next week I hope.) >=20 > Now email is of course just one application (though a cornerstone > application). Which other applications/mechanisms should we be > considering that'd help here? FWIW, I'm very open to us trying to > help anywhere we could credibly do that. (Credibility requiring > that stuff be technically doable, be something that should be done > in the IETF and have enough warm bodies interested in doing work.) >=20 > Cheers, > S. >=20 > PS: If you or someone has a specific suggestion for a thing on > which we should be working, then maybe these lists are too broad > for detailed discussion of that. In such cases, the perpass@ietf.org > list is probably a good place to triage whether a topic is one we > should try pursue in the IETF. >=20 --Apple-Mail=_40791B45-E040-4BB9-995F-94F15C92BF80 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJT+hOPAAoJEDY/T2tCIPW3FqEP/0nAkYNw4AXxgNNEB3joc+is F+QUlOe5qtU/uOn5gSiut3O/6/0Q17Tx97vwVdshPm0/GIQnZm6QroWC2EV2N8LL Hu2vnN33Qhbw9D3llF/Una3zfX2jMGLlkm9xNhR2HAqgfPiIjLt7vbR856DxX+Ne /s+513CE8P+eUBDk1BlLDXC+Gv+WPqw3wXHg/Ud2+T1gf75fZ0FdvL/4tQh7Ui+U ZjBuny7Spwcn6Wb5j3d5WT5DYGn7aioylMn3ZTRlA8byydbmHvwH1NzClTKhjSiA AVmNNTc7fAEQURiy509nJgx79Jle8PwhIUnPLbv0IO+ziD8JuyzxQkJm6MtuB5bB H+yJZR1kp0jI0M1HEjv1MVZqd2ypyKD0Gymw/CHZIMie0hhIppn+XCRkZ0/yjVCq q2s7GyvXWWgYPyu29OYJ/O2ETfqe6Q82lGBf6Ic630hIZ9ByVeZGyWk6xkJ8jCan XGzey5SosFARLANiPW82SG1dgD0H15NkUOfccvvvRkdAzxCqHqAeBVCpno/C1YjU gK9jvAxjfT4lvWlb1Qb22m+283nHBz3FDhCbIvlWH/jfY91MS/3fipipyWwwaIjj PvSvtXmNmdkk0uns9ESpzFxDBQEkxi0SMCjTDobcKg5sedW6ozrMjRSjQm30D/ds Sh6BLovzp6xl1U6Tz6vt =Bjz/ -----END PGP SIGNATURE----- --Apple-Mail=_40791B45-E040-4BB9-995F-94F15C92BF80-- From nobody Tue Aug 26 08:04:59 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401131A0686 for ; Sun, 24 Aug 2014 12:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MISSING_MID=0.497, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s53NymF9zILA for ; Sun, 24 Aug 2014 12:06:31 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 472A11A0684 for ; Sun, 24 Aug 2014 12:06:31 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta10.westchester.pa.mail.comcast.net with comcast id iiBd1o0020SCNGk5Aj6W4P; Sun, 24 Aug 2014 19:06:30 +0000 Received: from Mike-T530ssd.comcast.net ([68.34.113.195]) by omta09.westchester.pa.mail.comcast.net with comcast id ij6W1o0014D0RQL3Vj6WCP; Sun, 24 Aug 2014 19:06:30 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 24 Aug 2014 15:06:29 -0400 To: Eric Burger ,"saag@ietf.org" From: Michael StJohns In-Reply-To: <6461D9C5-8B0B-42D3-9877-32DB3E6150C6@standardstrack.com> References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <20140821160402.GT14392@mournblade.imrryr.org> <20140822140000.GE14392@mournblade.imrryr.org> <20140823040550.GQ5909@localhost> <53F8FA97.2020607@cs.tcd.ie> <53F908A1.6040207@cs.tcd.ie> <8BBAE4BE-F816-4170-9533-6400ACE463EA@cs.georgetown.edu> <6461D9C5-8B0B-42D3-9877-32DB3E6150C6@standardstrack.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1408907190; bh=go0GsjJpNrpHMEFxaVFWBi5vqNxQrIuf8cbmg7omUmo=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=SsjhuoqT65t+LFEwgu2EEtzyxPhP4Bg86mAxgGS6n1SW+rHuKbaY+E4XtHGYXbh5E wsbkG7kA09Q3f4cmGR8USwLOXpv/dV1U+wDzVS5m/BDq5XVpDZGvC9jP6JVVnebcS6 x/9v3HUi+tVXwU0LJOaChXVK3B+73Mq6FRXpnQUvCBTytrBZ/0L0ABUjzhquT9V87j huJY9v1CxvI7ouxiUp8BCVuXnKfQSWksHxayJ3AFYHyrPggMIRVxm5SpndwJNqDPnI guVEBy3BYci0k87gyxySSFlyOrA7KON2wh4pyX3aSWBleE1uRJ/PPKugw1KXQ9qGpe CbrHje3EFuByQ== Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_x5SiqB93jhLyMCwkQg-IwpccCo X-Mailman-Approved-At: Tue, 26 Aug 2014 08:04:55 -0700 Cc: "ietf@ietf.org" Subject: Re: [saag] Is traffic analysis really a target (was Re: Is opportunistic unauthenticated encryption a waste of time?) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 19:06:33 -0000 At 12:32 PM 8/24/2014, Eric Burger wrote: >I am concerned with the drive to make all traffic totally opaque. I’ll be brief: we have an existence proof of the mess that happens when we make all traffic look benign. It is called “everything over port 80.” That ‘practical’ approach drove the development of deep packet inspection, because everything running over port 80 was no longer HTTP traffic. It meant we could no longer prioritize traffic (in a good sense - *I* want to make sure my VoIP gets ahead of my Web surfing ahead of my FTP). It meant we could no longer apply enterprise policy on different applications. It drove ‘investment’ in the tools that today dominate pervasive monitoring. > >Good job folks for unintended consequences. For a longer and more complete discussion on this, please see also RFC3639. It was drafted at a time a national actor was contemplating blocking VoIP traffic at the actor's borders so it could tariff voice traffic by forcing it onto the PTT POTS system. There will be unintended consequences for whatever this OS thing ends up getting called. It would be nice if we could do enough design and analysis prior to deployment to turn them into "carefully considered, more good for the user than harm to the network" consequences. Later, Mike >On Aug 23, 2014, at 5:33 PM, Stephen Farrell wrote: > >> >> Hiya, >> >> On 23/08/14 22:05, Bernard Aboba wrote: >>> Stephen Farrell: >>>> However, say we're wrong and someone who thinks OS is a waste of >>>> time is actually correct, what would such a person recommend that >>>> we do as well as, or instead of, OS? >>> >>> [BA] It depends on who we are trying to protect, and from what (or >>> whom). >> >> Sure. >> >>> If the target is protection of dissidents from oppressive >>> regimes, then you need something much more comprehensive than >>> 'unauthenticated opportunistic encryption" (e.g. along the lines of >>> Tor). >> >> Right. That's a hard target and involves far more than crypto, >> whether OS or not. >> >> One thing clearly involved there is that traffic analysis is >> a threat, and I'd fully accept that we should be thinking about >> ways in which we could make our protocols better against that >> in general, even if we're not tackling the specific problems of >> dissidents. For example, if my toilet emits packets with every >> flush, encryption of any sort isn't going to disguise that so >> traffic analysis will also be relevant for the Internet-of-Toilets. >> >>> If the target is protection against PM within wealthy nations, >>> then you'd need something that can't be rendered harmless by a modest >>> budget increase. A number of MITM protection mechanisms have been >>> suggested (e.g. DANE, channel binding, etc.). >> >> But isn't that what the IETF and security folks within the >> IETF have been aiming for for a couple of decades? I mean aiming >> for an end-state where we have mutual-auth more-or-less everywhere. >> I don't consider that we've succeeded wildly to be honest;-) >> >> What should we be doing differently is really my question. >> >>> Also, in this category >>> should be mechanisms for protecting privacy against private-sector >>> adversaries. As long as private companies can amass huge dociers >>> without resort to PM (or without the need to subvert OS), and are >>> willing to sell that personal information to third parties (dodgy >>> ones, let alone governments), one wonders whether government >>> agencies would make better use of their funds by "buying" >>> surveillance, rather than trying to "build" it. >> >> As it happens we had some discussion about e2e email security in >> Toronto. Current plan is to start a new mailing list for that - a >> bunch of us are chatting about how to scope that so we're less >> likely to mess up. (More on that next week I hope.) >> >> Now email is of course just one application (though a cornerstone >> application). Which other applications/mechanisms should we be >> considering that'd help here? FWIW, I'm very open to us trying to >> help anywhere we could credibly do that. (Credibility requiring >> that stuff be technically doable, be something that should be done >> in the IETF and have enough warm bodies interested in doing work.) >> >> Cheers, >> S. >> >> PS: If you or someone has a specific suggestion for a thing on >> which we should be working, then maybe these lists are too broad >> for detailed discussion of that. In such cases, the perpass@ietf.org >> list is probably a good place to triage whether a topic is one we >> should try pursue in the IETF. >> > > > From nobody Tue Aug 26 08:05:00 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351E31A06FC; Sun, 24 Aug 2014 13:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs_0m84SbuZj; Sun, 24 Aug 2014 13:02:02 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE491A06FA; Sun, 24 Aug 2014 13:02:01 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id hz1so19229294pad.8 for ; Sun, 24 Aug 2014 13:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8wwe29sKgIQ/ufUSZQFSTNVl4L05KlkBxU+fU92y20Q=; b=1HNPPDt9w+VehOfckRXCqIti2IevB0ZoO48IdP/KVgitLmbUBbJ/zXMMdQEPkVrjg0 LSVX6jigQGgUaUvNhPWJYvM3/e6CrE8GPj4usvN0Od2UuP5s70RpA66GsZZ+jydNlmzU xgKVXwZOGOJHq1bWAzST/yo6Mw1xjlZ4LJxPNoIInPc3AqoX2EGFuREL9g99zTeq2Qgk +0qAqB8dVkNXOsiSM5X/DG5F3pWKzZ1QL+E/i+eS9PgNNUSdjKuz59XjTvVMu/62m3sP TOMLLIzYzX+8igBTXC4fyHxYxoRBF7lLYrd3XoqsMOM/NmkJmQB87uv5CoNXpndCLZAY C3EA== X-Received: by 10.66.121.137 with SMTP id lk9mr23042837pab.86.1408910521484; Sun, 24 Aug 2014 13:02:01 -0700 (PDT) Received: from [192.168.178.23] (246.195.69.111.dynamic.snap.net.nz. [111.69.195.246]) by mx.google.com with ESMTPSA id vz7sm35226110pbc.95.2014.08.24.13.01.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Aug 2014 13:02:00 -0700 (PDT) Message-ID: <53FA44AF.4070504@gmail.com> Date: Mon, 25 Aug 2014 08:01:51 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael StJohns References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <20140821160402.GT14392@mournblade.imrryr.org> <20140822140000.GE14392@mournblade.imrryr.org> <20140823040550.GQ5909@localhost> <53F8FA97.2020607@cs.tcd.ie> <53F908A1.6040207@cs.tcd.ie> <8BBAE4BE-F816-4170-9533-6400ACE463EA@cs.georgetown.edu> <6461D9C5-8B0B-42D3-9877-32DB3E6150C6@standardstrack.com> <20140824190636.5BD1C1A0686@ietfa.amsl.com> In-Reply-To: <20140824190636.5BD1C1A0686@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/saag/m1lmORtAcpqCFqENh5cv1UZoXzA X-Mailman-Approved-At: Tue, 26 Aug 2014 08:04:55 -0700 Cc: "saag@ietf.org" , Eric Burger , "ietf@ietf.org" Subject: Re: [saag] Is traffic analysis really a target (was Re: Is opportunistic unauthenticated encryption a waste of time?) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 20:02:04 -0000 On 25/08/2014 07:06, Michael StJohns wrote: > At 12:32 PM 8/24/2014, Eric Burger wrote: >> I am concerned with the drive to make all traffic totally opaque. I=E2= =80=99ll be brief: we have an existence proof of the mess that happens wh= en we make all traffic look benign. It is called =E2=80=9Ceverything over= port 80.=E2=80=9D That =E2=80=98practical=E2=80=99 approach drove the de= velopment of deep packet inspection, because everything running over port= 80 was no longer HTTP traffic. It meant we could no longer prioritize tr= affic (in a good sense - *I* want to make sure my VoIP gets ahead of my W= eb surfing ahead of my FTP). It meant we could no longer apply enterprise= policy on different applications. It drove =E2=80=98investment=E2=80=99 = in the tools that today dominate pervasive monitoring. >> >> Good job folks for unintended consequences. >=20 >=20 > For a longer and more complete discussion on this, please see also RFC3= 639. =20 RFC3205 (BCP56) said some of it a bit earlier, and was ignored. I'd say t= hat RFC3639 was ignored too. For a practical lesson on the same topic, I sugg= est a critical study of all the RTCWEB drafts and of draft-ietf-dart-dscp-rtp= =2E I think they show the depth of the hole we are in. Brian > It was drafted at a time a national actor was contemplating blocking Vo= IP traffic at the actor's borders so it could tariff voice traffic by for= cing it onto the PTT POTS system.=20 >=20 > There will be unintended consequences for whatever this OS thing ends u= p getting called. It would be nice if we could do enough design and anal= ysis prior to deployment to turn them into "carefully considered, more go= od for the user than harm to the network" consequences. >=20 > Later, Mike >=20 >=20 >=20 >=20 >=20 >> On Aug 23, 2014, at 5:33 PM, Stephen Farrell wrote: >> >>> Hiya, >>> >>> On 23/08/14 22:05, Bernard Aboba wrote: >>>> Stephen Farrell: >>>>> However, say we're wrong and someone who thinks OS is a waste of >>>>> time is actually correct, what would such a person recommend that >>>>> we do as well as, or instead of, OS? >>>> [BA] It depends on who we are trying to protect, and from what (or >>>> whom).=20 >>> Sure. >>> >>>> If the target is protection of dissidents from oppressive >>>> regimes, then you need something much more comprehensive than >>>> 'unauthenticated opportunistic encryption" (e.g. along the lines of >>>> Tor).=20 >>> Right. That's a hard target and involves far more than crypto, >>> whether OS or not. >>> >>> One thing clearly involved there is that traffic analysis is >>> a threat, and I'd fully accept that we should be thinking about >>> ways in which we could make our protocols better against that >>> in general, even if we're not tackling the specific problems of >>> dissidents. For example, if my toilet emits packets with every >>> flush, encryption of any sort isn't going to disguise that so >>> traffic analysis will also be relevant for the Internet-of-Toilets. >>> >>>> If the target is protection against PM within wealthy nations, >>>> then you'd need something that can't be rendered harmless by a modes= t >>>> budget increase. A number of MITM protection mechanisms have been >>>> suggested (e.g. DANE, channel binding, etc.).=20 >>> But isn't that what the IETF and security folks within the >>> IETF have been aiming for for a couple of decades? I mean aiming >>> for an end-state where we have mutual-auth more-or-less everywhere. >>> I don't consider that we've succeeded wildly to be honest;-) >>> >>> What should we be doing differently is really my question. >>> >>>> Also, in this category >>>> should be mechanisms for protecting privacy against private-sector >>>> adversaries. As long as private companies can amass huge dociers >>>> without resort to PM (or without the need to subvert OS), and are >>>> willing to sell that personal information to third parties (dodgy >>>> ones, let alone governments), one wonders whether government >>>> agencies would make better use of their funds by "buying" >>>> surveillance, rather than trying to "build" it. >>> As it happens we had some discussion about e2e email security in >>> Toronto. Current plan is to start a new mailing list for that - a >>> bunch of us are chatting about how to scope that so we're less >>> likely to mess up. (More on that next week I hope.) >>> >>> Now email is of course just one application (though a cornerstone >>> application). Which other applications/mechanisms should we be >>> considering that'd help here? FWIW, I'm very open to us trying to >>> help anywhere we could credibly do that. (Credibility requiring >>> that stuff be technically doable, be something that should be done >>> in the IETF and have enough warm bodies interested in doing work.) >>> >>> Cheers, >>> S. >>> >>> PS: If you or someone has a specific suggestion for a thing on >>> which we should be working, then maybe these lists are too broad >>> for detailed discussion of that. In such cases, the perpass@ietf.org >>> list is probably a good place to triage whether a topic is one we >>> should try pursue in the IETF. >>> >> >> >=20 >=20 >=20 From nobody Tue Aug 26 08:05:01 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CFC1A8AAD; Mon, 25 Aug 2014 00:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ELQZd2FwCLA; Mon, 25 Aug 2014 00:19:57 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A271A8AB7; Mon, 25 Aug 2014 00:19:56 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id rl12so9006934iec.24 for ; Mon, 25 Aug 2014 00:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eTPLsdf17PJxKC2Pj7FB687Mbge5imOo44hbAj6NAO4=; b=x7neNK4jEMVMeVufLGzYyNl5kC14pTzgzjQ8i81/oHlPDOONBmdn1HU20m18Vo00Cn igVnGJkpDCcg9rA4s8HRsmzJloESeIRvRiUU/hOdtIEZNxZWEW5H4kIe/ZRmsKxmH7gG CJ5Aee5vGDa1n4rGawwlG3SGqd1eG1d5wxxmLp13MB/LW5LuXD+GaIe0EnDFhPB/iZ90 SzTebuoMU9epIvpJbRRC5KSGbZ3CNt+GiJ+kJWbILtkvdcfrtIAeKlaVHRUkUOldA7dL Fhc+cY2y15YpYX0HIt/d3eF8jLJb2hLLIcFfbD93NYN7M7UguJc7m2Eldz9Kw5gvmT5z yZJw== MIME-Version: 1.0 X-Received: by 10.50.111.112 with SMTP id ih16mr13651095igb.30.1408951196313; Mon, 25 Aug 2014 00:19:56 -0700 (PDT) Received: by 10.43.154.80 with HTTP; Mon, 25 Aug 2014 00:19:56 -0700 (PDT) In-Reply-To: <53FA44AF.4070504@gmail.com> References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <20140821160402.GT14392@mournblade.imrryr.org> <20140822140000.GE14392@mournblade.imrryr.org> <20140823040550.GQ5909@localhost> <53F8FA97.2020607@cs.tcd.ie> <53F908A1.6040207@cs.tcd.ie> <8BBAE4BE-F816-4170-9533-6400ACE463EA@cs.georgetown.edu> <6461D9C5-8B0B-42D3-9877-32DB3E6150C6@standardstrack.com> <20140824190636.5BD1C1A0686@ietfa.amsl.com> <53FA44AF.4070504@gmail.com> Date: Mon, 25 Aug 2014 00:19:56 -0700 Message-ID: From: Ted Hardie To: Brian E Carpenter Content-Type: multipart/alternative; boundary=089e0149be408fefab05016f030a Archived-At: http://mailarchive.ietf.org/arch/msg/saag/yn3x3q9B0dCtv8Ib_9iWsZbtg-c X-Mailman-Approved-At: Tue, 26 Aug 2014 08:04:55 -0700 Cc: Michael StJohns , "saag@ietf.org" , Eric Burger , "ietf@ietf.org" Subject: Re: [saag] Is traffic analysis really a target (was Re: Is opportunistic unauthenticated encryption a waste of time?) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 07:19:59 -0000 --089e0149be408fefab05016f030a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Aug 24, 2014 at 1:01 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > RFC3205 (BCP56) said some of it a bit earlier, and was ignored. I'd say > that > RFC3639 was ignored too. For a practical lesson on the same topic, I > suggest > a critical study of all the RTCWEB drafts and of draft-ietf-dart-dscp-rtp= . > I think they show the depth of the hole we are in. > > Brian > > =E2=80=8BJust so I don't rudely put words in your mouth, I'd appreciate you= r unpacking what you practical lesson you anticipate learning there. regards, Ted=E2=80=8B --089e0149be408fefab05016f030a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Aug 24, 2014 at 1:01 PM= , Brian E Carpenter <brian.e.carpenter@gmail.com> = wrote:
<= br>
RFC3205 (BCP56) said some of it a bit earlier, and was ignored. I'= ;d say that
RFC3639 was ignored too. For a practical lesson on the same topic, I sugges= t
a critical study of all the RTCWEB drafts and of draft-ietf-dart-dscp-rtp.<= br> I think they show the depth of the hole we are in.

=C2=A0 =C2=A0Brian


=E2=80=8BJust so I don't rudely = put words in your mouth, I'd appreciate your unpacking what you practic= al lesson you anticipate learning there.

regards,

Ted=E2=80=8B
=C2=A0
--089e0149be408fefab05016f030a-- From nobody Tue Aug 26 08:05:03 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08221A04BC; Mon, 25 Aug 2014 17:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDe_gfpVJZ3q; Mon, 25 Aug 2014 17:09:55 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B891A04AB; Mon, 25 Aug 2014 17:09:55 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id rd3so21943321pab.0 for ; Mon, 25 Aug 2014 17:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vGQUmSMGUuOZ62naHkkJvQCKWyq1atlG5jYHH+7fOrM=; b=i2zB1MhCGTwt591ZAoQaHbSuExhY9EfegYJJXrKWatUZIJ7nvyy7rxOvlS4kuzvavr yZm8jT5zbsO8+msO7uYZX4TFIAhPO9K9ixloVVu/TKrSSeZbflCXpERKxXKSA0wOt2zN nzuDMD1RxHcVEO4efPRGqjiTrTtWOUZkCFt0RrzApRR2L/sa3pgQb/cuL3hD8HXhhoD/ lcDSBsd7viDePc4E/vAEZNWPqU/p+laHIKjSxoAxw56J9EZXbYKp9eFC4mHnoxFpnNeR B9uGaPj3MmndwoJWr2GhgdqR4r6vTpnCyBrumsclGUeupbM27JRMRymIh8dkyND0yvKA +eNQ== X-Received: by 10.70.123.163 with SMTP id mb3mr27001178pdb.37.1409011795339; Mon, 25 Aug 2014 17:09:55 -0700 (PDT) Received: from [192.168.178.23] (100.195.69.111.dynamic.snap.net.nz. [111.69.195.100]) by mx.google.com with ESMTPSA id xj9sm4233884pab.40.2014.08.25.17.09.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Aug 2014 17:09:54 -0700 (PDT) Message-ID: <53FBD051.4010508@gmail.com> Date: Tue, 26 Aug 2014 12:09:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Hardie References: <53F548E5.2070208@cs.tcd.ie> <53F54F1C.1060405@dcrocker.net> <53F5D303.1090400@cs.tcd.ie> <20140821160402.GT14392@mournblade.imrryr.org> <20140822140000.GE14392@mournblade.imrryr.org> <20140823040550.GQ5909@localhost> <53F8FA97.2020607@cs.tcd.ie> <53F908A1.6040207@cs.tcd.ie> <8BBAE4BE-F816-4170-9533-6400ACE463EA@cs.georgetown.edu> <6461D9C5-8B0B-42D3-9877-32DB3E6150C6@standardstrack.com> <20140824190636.5BD1C1A0686@ietfa.amsl.com> <53FA44AF.4070504@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/saag/M3l5AlnSBiYaPYVqdZtBv04BKps X-Mailman-Approved-At: Tue, 26 Aug 2014 08:04:55 -0700 Cc: Michael StJohns , "saag@ietf.org" , Eric Burger , "ietf@ietf.org" Subject: Re: [saag] Is traffic analysis really a target (was Re: Is opportunistic unauthenticated encryption a waste of time?) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 00:09:58 -0000 On 25/08/2014 19:19, Ted Hardie wrote: > On Sun, Aug 24, 2014 at 1:01 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: >=20 >> RFC3205 (BCP56) said some of it a bit earlier, and was ignored. I'd sa= y >> that >> RFC3639 was ignored too. For a practical lesson on the same topic, I >> suggest >> a critical study of all the RTCWEB drafts and of draft-ietf-dart-dscp-= rtp. >> I think they show the depth of the hole we are in. >> >> Brian >> >> > =E2=80=8BJust so I don't rudely put words in your mouth, I'd appreciate= your > unpacking what you practical lesson you anticipate learning there. Actually I think my brain was a bit fuzzy when I wrote that, but the poin= t is that when we start bundling up things that don't naturally belong toge= ther, because we are trying to defeat middleboxes that perform DPI (for traffic= analysis or any other reason) and/or IP header munging, we end up with artificial complexity that is unlikely to result in reliable, efficient communication. An old story, I know. Since before RFC 2775 at least. Brian From nobody Tue Aug 26 08:05:04 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BDD1A6F1A for ; Tue, 26 Aug 2014 03:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYwafG1w2E6J; Tue, 26 Aug 2014 03:00:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA46C1A6F0F; Tue, 26 Aug 2014 03:00:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ietf-dane@dukhovni.org, draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140826100039.17629.99779.idtracker@ietfa.amsl.com> Date: Tue, 26 Aug 2014 03:00:39 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/saag/IwvyWbXUsAZNbJVnFnvHCJJj4Xw X-Mailman-Approved-At: Tue, 26 Aug 2014 08:04:55 -0700 Subject: [saag] ID Tracker State Update Notice: X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 10:00:41 -0000 IESG state changed to IESG Evaluation from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ From nobody Tue Aug 26 08:05:06 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC341A6F62; Tue, 26 Aug 2014 03:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.908 X-Spam-Level: X-Spam-Status: No, score=0.908 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zw19hmk7Wy9I; Tue, 26 Aug 2014 03:54:19 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E165B1A03FF; Tue, 26 Aug 2014 03:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=JyKiFKNEBFd5HnqKzVV/upx3uNcwacLONGO27IH7Qx4=; b=EMAyIebOIE0CK9ASn0cGHjip4cH4P8dd0/djH+8FihQM/EUJXm0ct3RVrbiLDEXsRRaSQpcagf21QI2xyPChJrUGsu3KXf98EZQBTWHBba1b0NwKWqggmyAWHj74dWMMaCTIIIxU6yD05zX2zHTTdJbHHRK/0s9YluSKbpyVYgo=; Received: from ip68-100-74-115.dc.dc.cox.net ([68.100.74.115]:59351 helo=[192.168.15.115]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XMEOC-00067i-9L; Tue, 26 Aug 2014 03:54:15 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_16B27E60-E314-447F-A0C1-EDF3170ED908"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Eric Burger In-Reply-To: <20140826054406.GA20264@localhost> Date: Tue, 26 Aug 2014 06:54:10 -0400 Message-Id: References: <20140822140000.GE14392@mournblade.imrryr.org> <20140823040550.GQ5909@localhost> <53F8FA97.2020607@cs.tcd.ie> <53F908A1.6040207@cs.tcd.ie> <8BBAE4BE-F816-4170-9533-6400ACE463EA@cs.georgetown.edu> <6461D9C5-8B0B-42D3-9877-32DB3E6150C6@standardstrack.com> <20140826054406.GA20264@localhost> To: "ietf@ietf.org" X-Mailer: Apple Mail (2.1878.6) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/saag/dmkDNoqxK0wcblPu8aqA1uNm3qQ X-Mailman-Approved-At: Tue, 26 Aug 2014 08:04:55 -0700 Cc: "saag@ietf.org" Subject: Re: [saag] Is traffic analysis really a target (was Re: Is opportunistic unauthenticated encryption a waste of time?) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 10:54:21 -0000 --Apple-Mail=_16B27E60-E314-447F-A0C1-EDF3170ED908 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 My first reaction to the proposal of having traffic carry metadata to = describe the protocol was that it would be a lot more efficient for = middle box manufacturers to read RFCs. That way they would know all they = needed to know about the protocol without having to analyze the metadata = for each session. Moreover, sessions would not need all of that metadata = just to describe themselves. Then I thought that there is a simplicity and elegance to = self-describing protocols. Then I realized that people would complain about the chattiness and = overheads of self-describing protocols, and we would end up publishing = profiles of metadata. Like SERVICE_PROFILE=3D25 for mail retrieval, = SERVICE_PROFILE=3D587 for mail submission, SERVICE_PROFILE=3D5060 for = VoIP, SERVICE_PROFILE=3D389 for directory lookup, etc. We might even = call those profiles RFC 5321, RFC 6409, RFC 3261, and RFC 4511, to save = IETF work. On Aug 26, 2014, at 1:44 AM, Nico Williams = wrote: > On Sun, Aug 24, 2014 at 12:32:15PM -0400, Eric Burger wrote: >> I am concerned with the drive to make all traffic totally opaque. >> I=92l be brief: we have an existence proof of the mess that happens >> when we make all traffic look benign. It is called =93everything over >> port 80.=94 That =91practical=92 approach drove the development of = deep >=20 > Benign? No, that's not it. Ports 80 and 443 (*not* just 80) are used > for everything for a variety of reasons, one of which is that no one > could block them entirely, so every site with a firewall simply had to > have the capability to, and processes for permitting HTTP/HTTPS = traffic > -- they could NOT afford not to! >=20 > Whereas protocols on other ports... See below. >=20 >> packet inspection, because everything running over port 80 was no >> longer HTTP traffic. It meant we could no longer prioritize traffic >> (in a good sense - *I* want to make sure my VoIP gets ahead of my Web >> surfing ahead of my FTP). It meant we could no longer apply = enterprise >> policy on different applications. It drove =91investment=92 in the = tools >> that today dominate pervasive monitoring. >=20 > It's true that using HTTP as the IP of the 'Net hurt all sorts of > things, but it was driven by the massive adoption of HTTP. Remember = the > term "application gateway"? What a throwback to the late 80s, early > 90s. Application gateways are unheard of now because they're = ETOOHARD. >=20 > Firewalls can't cope with a raft of arbitrary, custom protocols, = whether > over IP or over HTTP, but with HTTP they get somewhat more metadata to > examine. If you really want to draw a lesson here it is this: > application protocols need a firewall-friendly substrate of metadata. > That's HTTP -- no other such substrate exists. >=20 > Sure, it's a bit of a mirage: the HTTP metadata can be faked. But at > least with HTTP the firewalls^Wproxies can make sure to get hostnames > every time, not just IP addresses. >=20 > That's my take. Maybe it's wrong, but it seems at least plausible. >=20 > If VoIPs and such used different port numbers but still HTTP... they'd > get through firewalls eventually and you could get your traffic > prioritization. It's not so much ports 80/443 that matter. It's the > HTTP headers request line, status line, and headers that do. You = could > do WebSockets or otherwise tunnel anything over HTTP and the firewalls > will be happy to let you, IF they like your metadata. >=20 > Nico > --=20 >=20 --Apple-Mail=_16B27E60-E314-447F-A0C1-EDF3170ED908 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJT/GdSAAoJEDY/T2tCIPW3s9UQAIAOyxexIVrkN4yn8DHuIU48 CpcLLhq09pXo7kt4UVozYY2kaE8dKeclMm6huZiWpnIN8Rr3UM1dVbUx17s/0MBr kne9NMnPRn0GImp7SSpiQs7xYFe4EAIbCVYgY997pgBkh2kikwol11KVVqLAVNb/ NspBRJHHWtXs8Pkw1JShpdaLL20Wtje0vvicKxj14jJNHMry6FC4m/MOkPF8vPey 3nB/zVrIwm6E6AdTKJfoeroal1wELd+GC4QOxNWUdnhCZZsW87XirpExPyL1JrhA LSBbqnyhg48eSuSECw82sY8PAq5I3ITMtlwxBOW+tqq1oeWg/9VoVAoQlXEvQ4TH KdFWibZkQnLNcRlBchD17D6gs5styOICSE0hqhfZDEt80QghT60AwwbgaQqslvW6 h2wol8Xdrj7coGmlDUYz0MaxkBjfqcMtJ1Pmueg/AJQOX3jdJN/GE3ruPfiQOD1k VCHwAe1i4TKNnqvI/JmZE8NG4JfQsx/vCAcjKrc3RzYgkFhvfuQAS0Tl9hOxSMRT wyABy0dsYxnck3DKMW33hoyAH/KrkCzFCVkgtBlvBk0KIlcwIWjXKtCu+ht6osDk 9VhCIPJN5VT/H1CsU9szX1RqEy62+T6V9PZnTfgiyf4o+FxQsnFPLlVAEd4/lzXD 2afSwXfLp4tDEOmG4hYf =OWOM -----END PGP SIGNATURE----- --Apple-Mail=_16B27E60-E314-447F-A0C1-EDF3170ED908-- From nobody Tue Aug 26 09:07:11 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00051A8777; Tue, 26 Aug 2014 09:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlYYDt6Eyi50; Tue, 26 Aug 2014 09:07:07 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6997D1A878C; Tue, 26 Aug 2014 09:07:06 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7QG6rpc031035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 Aug 2014 09:06:56 -0700 Message-ID: <53FCAFF8.2000603@dcrocker.net> Date: Tue, 26 Aug 2014 09:04:08 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , "saag@ietf.org" References: <20140826095923.19894.44221.idtracker@ietfa.amsl.com> <53FC5D78.2030206@cs.tcd.ie> In-Reply-To: <53FC5D78.2030206@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 26 Aug 2014 09:06:56 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/dyqoM0IZFyEBMs6S3YgxQxBFHaU Cc: iesg Subject: Re: [saag] Fwd: Evaluation: to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 16:07:08 -0000 On 8/26/2014 3:12 AM, Stephen Farrell wrote: > I've put Viktor's draft on the IESG telechcat for Sep 4th. That's significantly premature. First, consider how little convergence there was on the preceding draft -- and yes, that's contrary to your mis-characterization of it as only my having serious concerns; but I think that error of that myth has been adequately documented. Then consider how substantial the changes have been to the latest draft. Then consider that this round of changes, again, has been subject to a mystical process of offlist evaluation and decision-making, rather than any sort of interactive and incremental process with those making comments. In other words, folks again have to do their own audit, to see whether the changes resolve concerns. So please give the current draft a chance to get meaningful review, comment and possibly convergence. And then there is the August and US Labor Day vacation issue... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Aug 26 09:08:00 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F941A0002; Tue, 26 Aug 2014 09:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WO8ZGyPENa-r; Tue, 26 Aug 2014 09:07:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA8A1A8771; Tue, 26 Aug 2014 09:07:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLU45697; Tue, 26 Aug 2014 16:07:51 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.03.0158.001; Tue, 26 Aug 2014 17:07:45 +0100 From: Hosnieh Rafiee To: "secauth@ietf.org" , "saag@ietf.org" Thread-Topic: secauth - authentication and authorization - first draft Thread-Index: AQHPwUffjsVWgIryVk+i2nhztqdmkg== Date: Tue, 26 Aug 2014 16:07:44 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/saag/p9x5TUme5-0KApsqxejVWI8f7M0 Subject: [saag] secauth - authentication and authorization - first draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 16:07:57 -0000 Hi all, I have uploaded the first draft version of secauth requirements and use cas= es. I tried to apply comments I received by Viktor, Kathleen and Joel about cla= rification of the purpose of secauth. Any comments are highly appreciated. Thank you, Best, Hosnieh A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Secauth Usecases and Requirements Author : Hosnieh Rafiee Filename : draft-rafiee-secauth-usecase-00.txt Pages : 11 Date : 2014-08-26 Abstract: This document explains the use cases and requirements for secure authentication in other layers above the network layer, e.g. an application layer and the use of network layer security approaches for this purpose. It also introduces the requirement for privacy consideration. There's also a htmlized version available at: http://tools.ietf.org/html/draft-rafiee-secauth-usecase-00 From nobody Tue Aug 26 11:05:38 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0401A00FC for ; Tue, 26 Aug 2014 11:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ps2qzPRdnoxb; Tue, 26 Aug 2014 11:05:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0211A00F1; Tue, 26 Aug 2014 11:05:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ietf-dane@dukhovni.org, draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140826180529.15025.58841.idtracker@ietfa.amsl.com> Date: Tue, 26 Aug 2014 11:05:29 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/saag/1omQvnlXRiTRQq0gWikDG_76pnE Subject: [saag] ID Tracker State Update Notice: X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 18:05:36 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ From nobody Tue Aug 26 13:47:08 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9611A887D; Tue, 26 Aug 2014 13:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8Yesle-AONd; Tue, 26 Aug 2014 13:47:04 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA191A8825; Tue, 26 Aug 2014 13:47:04 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7QKkrGI004750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 Aug 2014 13:46:57 -0700 Message-ID: <53FCF198.3070603@dcrocker.net> Date: Tue, 26 Aug 2014 13:44:08 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Viktor Dukhovni Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 26 Aug 2014 13:46:57 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/bhd0vb2BDtYtMRxlVnAryhQ6cak Cc: "saag@ietf.org" , iesg Subject: [saag] Review of - draft-dukhovni-opportunistic-security-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:47:07 -0000 Review of: Opportunistic Security: Some Protection Most of the Time I-D: draft-dukhovni-opportunistic-security-04 Reviewed by: D. Crocker Review date: 26 Aug 2014 Summary: The paper defines and explains flexible approach to the use of encryption on the Internet. It assigns the term 'opportunistic security' to this term. The latest draft has extensive changes from the previous version. Although many of the changes are quite helpful, the document still suffers from confusing or unexplained terminology and some unfortunately initial organization. A number of points from previous reviews have not been addressed. The paper continues to freely make strong assertions, without providing any substantiation or even, in some cases, explanation. At a minimum, every term that is used, every assertion that is made and anything else that derives from Internet experience should be documented. Concerns with the term "opportunistic security" persist. It is both vague and overblown, given the specific technical point it is meant to address. That concern is about encryption and the term should make that clear. The paper still needs extensive revision before it should be considered for publication. A global editorial nit to consider: "Peer" is a potentially problematic term, for interactions that are mediated. The term "participant" does not suffer this exposure. So: s/peer/participant/g although "other participant" in some cases. Detailed Comments: > Abstract > > This document defines the concept "Opportunistic Security" in the > context of communications protocols. Protocol designs based on > Opportunistic Security remove barriers to the widespread use of > encryption on the Internet by using encryption even when > authentication is not available, and using authentication when > possible. The summary cites an outcome that is far from certain. Whether it will remove barriers is a hope, not a certainty. An abstract that is more in the style of a technical document and less in the style of a marketing document, requires only small changes: "Opportunistic Security" (OS) refers to the use of encryption even when authentication is not available, and use of authentication when possible. It is hoped that designing protocols and procedures to have the flexibility of an OS approach will result in more pervasive use of encryption. > 1. Introduction > > Broadly speaking, Opportunistic Security (OS) is a pragmatic risk > management approach. With Opportunistic Security, one applies the > tools at hand to mitigate the risks that can reasonably be addressed, > and accepts the rest. Delete this paragraph. First, it's wrong. It's not a 'risk management' approach. Risk management is a term of art that does not apply here. Second, the paragraph adds nothing. If anything, OS is about attacks or threats and not risks. In addition, the Introduction should do some introducing. It needs to start with a description of the problem or issue or... That is, the kind of stuff that is now in Section 1.1. I suggest making /it/ be the Introduction, with this one following it. (As an alternative, there's a less traumatic suggestion farther down.) > Definition: In the context of communications protocols, > "Opportunistic Security" is defined as the use of encryption when > possible, with authentication when possible. In the above, the > phrase "when possible" means when support for the corresponding > capability is advertised by the peer, ideally in a downgrade- > resistant manner. The definition looks pretty good. Seeing that it includes cleartext requires some thought. And the idea still seems pretty odd (ie, silly) in the context of seeking more use of encryption. > 1.1. Background For each assertion made in this section, there should be a citation to substantiate it. Since these assertions provide the justification for doing OS, it's important to /document/ a solid case against the existing choices. More broadly, when citing a technology or standard or convention, cite something that explains it in detail. As an example, TOFU (which would be nicely handled by pointing to the terminology section). > > Historically, Internet security protocols have emphasized > comprehensive "all or nothing" cryptographic protection against both > passive and active attacks. With each peer, such a protocol achieves "With each peer" does not have an obvious meaning and it isn't needed. Delete the phrase. > either full protection or else total failure to communicate (hard > fail). As a result, operators often disable these security protocols > when users have difficulty connecting, thereby degrading all > communications to cleartext transmission. > > Protection against active attacks requires authentication. The > ability to authenticate any potential peer on the Internet requires "potential" is extraneous or worse. The issue is authenticating /actual/ participants. So just say "any participant". > an authentication mechanism that encompasses all such peers. No IETF delete "authentication". > standards for authentication meet this requirement. This is written rather indirectly. Instead: Protection against active attacks requires the use of authentication. However no authentication mechanism is yet in use at Internet scale. The primary barriers are believed to be key management and human factors. > The Public Key Infrastructure (PKI) model employed by browsers to To repeat from the previous review: It's not just by browsers. > authenticate web servers (often called the "Web PKI") imposes cost > and management burdens that have limited its use. With so many "With so many" asserts a fact not introduced yet, so it presumes knowledge the reader might not have. Instead: There are many certification authorities, ... > certification authorities, which not everyone is willing to trust, trust, the -> trust, and the > the communicating parties don't always agree on a mutually trusted > CA. Without a mutually trusted CA, authentication fails, leading to > communications failure in protocols that mandate authentication. new paragraph, since you are introducing a separate point about key management. > These issues are compounded by operational difficulties. For > example, a common problem is for site operators to forget to perform > timely renewal of expiring certificates. In interactive > applications, security warnings are all too frequent, and end-users > learn to actively ignore security problems, or site administrators > decide that the maintenance cost is not worth the benefit so they > provide a cleartext-only service to their users. Typically, 'user interface design' issues are not folded into the term "operations". Usually, end-user issues are distinct from ops. > The trust-on-first-use (TOFU) authentication approach assumes that an > unauthenticated public key obtained on first contact (and retained I can't find any other occurrence of "unauthenticated public key" through google and am not exactly sure what it means. For a paper like this, that should be a significant concern... > for future use) will be good enough to secure future communication. future -> continuing [ or perhaps further ] > TOFU-based protocols do not protect against an attacker who can > hijack the first contact communication and require more care from the > end-user when systems update their cryptographic keys. TOFU can make > it difficult to distinguish routine system administration from a > malicious attack. Huh? The basis or accuracy of that last sentence isn't at all obvious to me. > DNS-Based Authentication of Named Entities (DANE [RFC6698]) defines a > way to distribute public keys bound to DNS names. It can provide an > alternative to the Web PKI. DANE needs to be used in conjunction > with DNSSEC [RFC4033]. At the time of writing, DNSSEC is not > sufficiently widely deployed to allow DANE to satisfy the Internet- > wide, any-to-any authentication requirement noted above. Protocols > that mandate authenticated communication cannot yet generally do so > via DANE (at the time of writing). > > The lack of a global key management system means that for many > protocols, only a minority of communications sessions can be > predictably authenticated. When protocols only offer a choice > between authenticated-and-encrypted communication, or no protection, > the result is that most traffic is sent in cleartext. The fact that > most traffic is not encrypted makes pervasive monitoring easier by > making it cost-effective, or at least not cost-prohibitive (see > [RFC7258] for more detail). > > For encryption to be used more broadly, authentication needs to be > optional. The use of encryption defends against pervasive monitoring against pervasive monitoring -> against some forms of pervasive monitorying As Bernard Aboba's posting observed, it's not necessarily all that strong a protection against PM... > and other passive attacks (which are employed not only by nation > states). Even unauthenticated, encrypted communication (defined > below) is preferable to cleartext. > As an alternative to moving sections around, with a tiny modification, the above two paragraphs would make an excellent opening for the Introduction. The modification is: The lack of a global key management system means -> A global key management system is essential for enabling pervasive, authenticated encryption. Its lack means... > For some applications or protocols the set of potential peers > includes a long tail of implementations that support only cleartext. > Such applications or protocols cannot set a baseline security policy > that requires encryption without losing the ability to communicate > with the cleartext-only peers. > > 1.2. A New Perspective It's hardly new. de facto use of encryption without (meaningful) authentication has been around for a very long time. > This document proposes a change of perspective. Until now, the More like: There have been ad hoc methods of allowing encryption without meaningful authentication. This paper seeks to acknowledge the efficacy of that alternative and encourage designs that permit its use in a flexible approach for encryption mechanisms. > protocol designer has viewed protection against both passive and > active attacks as the default, and anything short of that as > "degraded security" or a "fallback". Now, with OS, the new viewpoint > is that without specific knowledge of peer capabilities (or > applicable local policy), the default protection is no protection, > and anything more than that is an improvement. > > Cleartext, not comprehensive protection, is the default baseline. An > OS protocol is not falling back from comprehensive protection when > that protection is not supported by all peers; rather, OS protocols > employ the maximum protection possible. OS protocols work > transparently behind the scenes, without disrupting communication. > > When less than complete protection is negotiated, there is no need to > prompt the user with "your security may be degraded, please click OK" Even with the earlier discussion the paper needs to acknowledge, here, the significant exposure this creates. > dialogs. The negotiated protection is as good as can be expected. > Even if not comprehensive, it is often better than the traditional > outcome of either "no protection" or "communications failure". > 3. Opportunistic Security Design Principles > > OS provides a near-term approach to counter passive attacks by > removing barriers to the widespread use of encryption. OS offers an > incremental path to authenticated, encrypted communication in the > future, as suitable authentication technologies are deployed. OS > promotes the following design principles: > > Coexist with local policy: Local security policies preempt OS. > Opportunistic security never displaces or preempts local policy. > Many applications and types of data are too sensitive to use OS, > and more traditional security designs are appropriate in such > cases. > > Emphasize enabling communication: The primary goal of OS is to > enable communication and maximize the deployment of usable The 'maximize' part is probably correct. The 'enable' part is not. Any protocol 'enables' communication. OS doesn't 'enable' communication. At best, it avoids /dis/abling communication. > security. OS protocols need to be deployable incrementally, with > each peer configured independently by its administrator or user. It is not at all obvious what "deployed incrementally" means here. This needs to be explained carefully. And I believe I made this point in a previous review. > Maximize security peer by peer: OS protocols use encryption when it > is mutually supported. OS protocols enforce peer authentication > when an authenticated out-of-band channel is available to provide > the requisite keys or credentials. Communication should generally > be at least encrypted. OS should employ Perfect Forward Secrecy > (PFS) wherever possible in order to protect previously recorded > encrypted communication from decryption even after a compromise of > long-term keys. > > No misrepresentation of security: Unauthenticated, encrypted > communication must not be misrepresented to users or in > application logs of non-interactive applications as equivalent to > authenticated, encrypted communication. > > An OS protocol first determines the capabilities of the peer with > which it is attempting to communicate. Peer capabilities may be > discovered by out-of-band or in-band means. (Out-of-band mechanisms > include the use of DANE records or cached keys or credentials credentials acquired -> credentials previously acquired > acquired via TOFU. In-band determination implies negotiation between > peers.) The capability determination phase may indicate that the > peer supports authenticated, encrypted communication; > unauthenticated, encrypted communication; or only cleartext > communication. > > Opportunistic security protocols may hard-fail with peers for which a may -> might remove all RFC2119 reserved words > security capability fails to function as advertised. Security > services that work reliably (when not under attack) are more likely No kidding. Really, it does not help to have this document state points that are both secondary and obvious. For the current point, I think what is actually meant is something like: Opportunistic Security is compatible with common protocol design and operations quality criteria. > to be deployed and enabled by default. It is vital that the > capabilities advertised for an OS-compatible peer match the deployed Delete this sentence. It's somewhere between irrelevant and silly. That is, don't include basic lecture points on protocol or design fundamentals. Stay focused on the specifics of the paper's purpose. And I believe this issue, too, was raised for earlier drafts. > reality. Otherwise, OS systems will detect such a broken deployment This has literally nothing to do with OS nor with "OS" systems. > as an active attack and communication may fail. This might mean that > advertised peer capabilities are further filtered to consider only > those capabilities that are sufficiently operationally reliable. > Capabilities that can't be expected to work reliably should be > treated by an OS protocol as "not present" or "undefined". > > For greater assurance of channel security, an OS protocol may enforce > more stringent cryptographic parameters when the session is > authenticated. For example, the set of enabled Transport Layer > Security (TLS [RFC5246]) cipher suites might be more restrictive for > authenticated sessions. How is this relevant to OS, and what is it in the definition that would lead one to expect it? > OS protocols should produce authenticated, encrypted communication > when authentication of the peer is "expected". Here, "expected" > means a determination via a downgrade-resistant method that > authentication of that peer is expected to work. Huh? We've already been told that authentication is to be used when possible. The reference to "expected" doesn't make sense to me here and doesn't seem to be adding anything useful to the paper. > Downgrade-resistant > methods include: validated DANE DNS records, existing TOFU identity > information, and manual configuration. Such use of authentication is > > > > Dukhovni Expires February 26, 2015 [Page 7] > > Internet-Draft Opportunistic Security August 2014 > > > "opportunistic", in that it is performed when possible, on a per- > session basis. > > When communicating with a peer that supports encryption but not > authentication, any authentication checks enabled by default must be > disabled or configured to soft-fail in order to avoid unnecessary > communications failure or needless downgrade to cleartext. > > Cleartext is supported for backwards compatibility with systems > already deployed. Even when cleartext needs to be supported, > protocol designs based on Opportunistic Security prefer to encrypt, > employing cleartext only with peers that do not appear to be > encryption capable. Oh boy... > 4. Example: Opportunistic TLS in SMTP This example is of unclear utility, since it mostly seems to be documenting problems with the use of StartTLS and to rely on a reporting of some 'current' deployment. I'm not sure what point is being made by this section, but it seems that it could be made more simply and more directly. > Most Message Transfer Agents (MTAs, [RFC5598]) support the STARTTLS Most -> Some 'Most' is not needed and it's not substantiated. I'm even sure it's correct. > ([RFC3207]) ESMTP extension. MTAs acting as SMTP ([RFC5321]) clients > generally support cleartext transmission of email. They negotiate generally? you mean, you know of any that don't??? They -> Some > TLS encryption when the SMTP server announces STARTTLS support. > Since the initial ESMTP negotiation is not cryptographically > protected, the STARTTLS advertisement is vulnerable to MiTM downgrade > attacks. ... > 5. Operational Considerations > > OS protocol designs should minimize the possibility of failure of Does this mean that other designs don't have to worry about the issue? That is, what is it that is specific to OS that warrants making this point? > negotiated security mechanisms. OS protocols may need to employ > "fallback", to work-around a failure of a security mechanisms that is Given the earlier, forceful claim that OS is a fall-forward, not -backward, approach, this is confusing. > found in practice to encounter interoperability problems. The choice > to implement or enable fallback should only be made in response to > significant operational obstacles. ... > 6. Security Considerations > > OS supports communication that is authenticated and encrypted, > unauthenticated and encrypted, or cleartext. And yet the security > provided to communicating peers is not reduced by the use of OS > because the default OS policy employs the best security services > available based on the capabilities of the peers, and because local I'm not entirely sure I'm parsing the above correctly, but the second sentence appears to be asserting an unfounded conclusion. > security policies take precedence over the default OS policy. OS is > an improvement over the status quo; it provides better security than > the alternative of providing no security services when authentication > is not possible (and not strictly required). This sentence provides a nice example of why "security" is such an unfortunate term, given that "encryption" is what is meant: The use of the word 'security' implies a broader sense of protection than is mean. > While the use of OS is preempted by a non-OS local policy, such a is -> can be > non-OS policy can be counter-productive when it demands more than > many peers can in fact deliver. Non-OS policy should be used with > care, lest users find it too restrictive and act to disable security > entirely. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Aug 26 14:45:47 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8710C1A0176; Tue, 26 Aug 2014 14:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2idpW3JnWAf; Tue, 26 Aug 2014 14:45:44 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4AF41A009C; Tue, 26 Aug 2014 14:45:44 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7QLjdEk006079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 Aug 2014 14:45:42 -0700 Message-ID: <53FCFF5D.7030306@bbiw.net> Date: Tue, 26 Aug 2014 14:42:53 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Viktor Dukhovni References: <53FCF198.3070603@dcrocker.net> In-Reply-To: <53FCF198.3070603@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Tue, 26 Aug 2014 14:45:42 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/8MUUXKQ-SIxrWqazDzilZIHMC5k Cc: "saag@ietf.org" , iesg Subject: Re: [saag] Review of - draft-dukhovni-opportunistic-security-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 21:45:45 -0000 On 8/26/2014 1:44 PM, Dave Crocker wrote: > The latest draft has extensive changes from the previous version. Sorry I didn't think of this sooner. The wdiff between -03 and -04 is facinating. Take a look at: https://www.ietf.org/rfcdiff?url1=draft-dukhovni-opportunistic-security-03&difftype=--hwdiff&submit=Go!&url2=draft-dukhovni-opportunistic-security-04 The text that is in black is unchanged. There remarkably little black text. It's not possible for a revision to make changes that extensive and be ready for IESG processing. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Aug 26 15:48:52 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553541A00A6; Tue, 26 Aug 2014 15:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rsUgsWDywuU; Tue, 26 Aug 2014 15:48:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0D29D1A0030; Tue, 26 Aug 2014 15:48:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 99A44BDFA; Tue, 26 Aug 2014 23:48:46 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWvMUYIAjCml; Tue, 26 Aug 2014 23:48:45 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.29.44]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3772EBDF7; Tue, 26 Aug 2014 23:48:45 +0100 (IST) Message-ID: <53FD0ECC.4010607@cs.tcd.ie> Date: Tue, 26 Aug 2014 23:48:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: dcrocker@bbiw.net, "saag@ietf.org" References: <20140826095923.19894.44221.idtracker@ietfa.amsl.com> <53FC5D78.2030206@cs.tcd.ie> <53FCAFF8.2000603@dcrocker.net> In-Reply-To: <53FCAFF8.2000603@dcrocker.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/TggzHJa76RWKMafWUMFxMEJ8qNU Cc: iesg Subject: Re: [saag] Fwd: Evaluation: to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 22:48:50 -0000 Hi Dave, On 26/08/14 17:04, Dave Crocker wrote: > On 8/26/2014 3:12 AM, Stephen Farrell wrote: >> > I've put Viktor's draft on the IESG telechcat for Sep 4th. > > That's significantly premature. Clearly, I disagree, and am proceeding with the plan I set out on ietf@ietf.org on Friday last week [1] after the extended IETF LC. My evaluation was (and is) that we do have rough consensus to proceed and that from about version -02 to -04, there has been no real change to the concept but many wording changes. Those have improved things, but in particular from -03 to -04 I agree with what Christian Huitema said earlier: we are starting to go sideways instead of forward (i.e. we're not improving significantly and its good-enough). I realise that you do not agree with that assessment but I do think all your points have been considered appropriately. I also read your review of -04 and don't see new issues there to change that assessment. (Thanks for that review btw, and I'm sure the editorial comments will be useful.) On balance I think best is to move this one into IESG evaluation and see what conclusion is reached. Thanks, S. [1] https://www.ietf.org/mail-archive/web/ietf/current/msg89280.html From nobody Tue Aug 26 21:42:43 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4DB1A03D8; Tue, 26 Aug 2014 21:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-9X16rI2PLw; Tue, 26 Aug 2014 21:42:35 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33E3C1A03D7; Tue, 26 Aug 2014 21:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2289; q=dns/txt; s=iport; t=1409114555; x=1410324155; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=wNBumS6rD4/gAKhR0qMNFgPXWMC82NB75MMXDeus6Mc=; b=gfVSVBX6r6h9+HJ48wa9b+iV+KqfZA4XDDkp57fUHHG6GMDiWn9h1Yx+ myTgGFiU89X6Bdj5zg5B0UXitLSY6QjbotVoeXnFyWgdHuubSzpAzxCg3 mbjMDntVqAoKfWQ/WfE1hMsVRT68jFlZEDsTK1ZfnIn0jxw90KJ4N+2Tg s=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEACdh/VOtJssW/2dsb2JhbABbhzPRMQGBK3eEBAEBAwEjVQEQCyEWCwICCQMCAQIBRQYBDAEHAQGINgirA5RHF49MB4J5gVMBBJMxgUqDF4RChzONYYNgO4J+AQEB X-IronPort-AV: E=Sophos;i="5.04,408,1406592000"; d="asc'?scan'208";a="150352233" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 27 Aug 2014 04:42:32 +0000 Received: from [10.61.212.43] ([10.61.212.43]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7R4gWb6026962; Wed, 27 Aug 2014 04:42:32 GMT Message-ID: <53FD61B7.6060109@cisco.com> Date: Wed, 27 Aug 2014 06:42:31 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dcrocker@bbiw.net, Viktor Dukhovni References: <53FCF198.3070603@dcrocker.net> In-Reply-To: <53FCF198.3070603@dcrocker.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f5ceUOAQb7rCfePw08aa7p1GEsH7Ri4Oc" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/fPYw1OmFwg1LRSK-ZrU6gSV8H_A Cc: "saag@ietf.org" , iesg Subject: Re: [saag] Review of - draft-dukhovni-opportunistic-security-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 04:42:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f5ceUOAQb7rCfePw08aa7p1GEsH7Ri4Oc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I agree with many =E2=80=93 not all=E2=80=93 of Dave's comments. But I = wanted to add one of my own: On 8/26/14, 10:44 PM, Dave Crocker wrote: >> as an active attack and communication may fail. This might mean th= at >> advertised peer capabilities are further filtered to consider only >> those capabilities that are sufficiently operationally reliable. >> Capabilities that can't be expected to work reliably should be >> treated by an OS protocol as "not present" or "undefined". >> >> For greater assurance of channel security, an OS protocol may enfor= ce >> more stringent cryptographic parameters when the session is >> authenticated. For example, the set of enabled Transport Layer >> Security (TLS [RFC5246]) cipher suites might be more restrictive fo= r >> authenticated sessions. > How is this relevant to OS, and what is it in the definition that would= > lead one to expect it? Yes, this is somewhat confusing. I think the claim is that even if you have an authenticated channel, that's still OS. But authentication usually means that there is a signal of some form to the application or the user, and that signal can only be binary. In order for it to be so, you need to establish minimum safe cypher suites. Is that were the text was meant to go? Eliot --f5ceUOAQb7rCfePw08aa7p1GEsH7Ri4Oc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJT/WG3AAoJEIe2a0bZ0nozjz0H/3zHoAa9finFW7YHvym7xqYo i/Wl0rVXFMnxiuKlkO7Ts7RCVprCbpV7EbcS0lReSnTpVEM+Gc4mDfKSlBK/ASMR w5tTg8woM6hg3qr2zdr2HwqY3+VY0Ab1N80RResu+j2BBBkMxn+eCuhxfp4Ak7sq GbFIgj55jgsMkYsCi+oAMhnQBHzEvVDLgXUB/DgSlja54cwvPZIGU9sLiQndU+rE 70T5cpKz4dIdXd6ztUL5FVliXM6LPiGlDFcYbROUCItlogNvCtv+p1UC0TIqdrCH 5+vvmag9Bk+dKIE1TfDz01FKTAKo9mRF8ND58oRT7xm2db+MjcwoUhW0pObt9NU= =gO7T -----END PGP SIGNATURE----- --f5ceUOAQb7rCfePw08aa7p1GEsH7Ri4Oc-- From nobody Wed Aug 27 05:55:35 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F411A069E; Wed, 27 Aug 2014 05:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aU1KbCOhyBEA; Wed, 27 Aug 2014 05:55:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7971A0197; Wed, 27 Aug 2014 05:55:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLV38710; Wed, 27 Aug 2014 12:55:25 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.03.0158.001; Wed, 27 Aug 2014 13:55:23 +0100 From: Hosnieh Rafiee To: "secauth@ietf.org" , "saag@ietf.org" Thread-Topic: requirement and use cases of secauth Thread-Index: Ac/B9ik6t/V5Q4VWSuCeRDx85YxBNQ== Date: Wed, 27 Aug 2014 12:55:22 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A29969@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/saag/r7K4FKm3Bmf5SylahBzq4BXmrNI Subject: [saag] requirement and use cases of secauth X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 12:55:32 -0000 Folks, Did you have a chance to read the requirement and use case draft? Any comments either editorial or technical? Is everything clear or I need t= o work more on it?=20 I appreciate your active involvement in this topic as I'm looking forward t= o preparing something good for the upcoming IETF. So please if you haven't yet take a look on the draft, look it and send me = your comments.=20 Thanks! Hosnieh P.S. I found myself a few editorial problems such as missing words in 2 par= ts of the document. If there are anything more, I would welcome if you shar= e it.=20 From nobody Wed Aug 27 08:01:15 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F50C1A06FE; Wed, 27 Aug 2014 08:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHixNLGuOAZe; Wed, 27 Aug 2014 08:01:14 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208461A0AD4; Wed, 27 Aug 2014 08:01:14 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s7RF12o8005764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 27 Aug 2014 08:01:05 -0700 Message-ID: <53FDF207.3010704@dcrocker.net> Date: Wed, 27 Aug 2014 07:58:15 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Eliot Lear , Viktor Dukhovni References: <53FCF198.3070603@dcrocker.net> <53FD61B7.6060109@cisco.com> In-Reply-To: <53FD61B7.6060109@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 27 Aug 2014 08:01:06 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/vJEIfGAlgf5Vnw8Cd2Q-CvlCRX0 Cc: "saag@ietf.org" , iesg Subject: Re: [saag] Review of - draft-dukhovni-opportunistic-security-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 15:01:15 -0000 On 8/26/2014 9:42 PM, Eliot Lear wrote: > On 8/26/14, 10:44 PM, Dave Crocker wrote: >>> For greater assurance of channel security, an OS protocol may enforce >>> more stringent cryptographic parameters when the session is >>> authenticated. For example, the set of enabled Transport Layer >>> Security (TLS [RFC5246]) cipher suites might be more restrictive for >>> authenticated sessions. >> How is this relevant to OS, and what is it in the definition that would >> lead one to expect it? > > Yes, this is somewhat confusing. I think the claim is that even if you > have an authenticated channel, that's still OS. But authentication > usually means that there is a signal of some form to the application or > the user, and that signal can only be binary. In order for it to be so, > you need to establish minimum safe cypher suites. Is that were the text > was meant to go? I believe this demonstrates a very basic confusion in both the document and with the author, about the meaning and applicability of the term. The term is defined essentially as a style of designing flexibility into a protocol. As such, it is not possible for a particular security component mechanism, like DANE or TLS to "have" or to "be" OS. However it seems to be geting used as if it is, itself, a protocol mechanism. An OS approach might include one or another such component, but that's not the same meaning at all. At the least, this is an example of how the document needs far greater clarity than it currently has, if it is to have substantive benefit for future design efforts. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 29 08:05:58 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202E61A04B4 for ; Fri, 29 Aug 2014 08:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.133 X-Spam-Level: X-Spam-Status: No, score=0.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7xbKg50FSCh for ; Fri, 29 Aug 2014 08:05:37 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828E31A045A for ; Fri, 29 Aug 2014 08:05:36 -0700 (PDT) X-ASG-Debug-ID: 1409324734-06daaa2eda98740001-QkeUbe Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id LCvWfAzeP91jqSnO; Fri, 29 Aug 2014 11:05:34 -0400 (EDT) X-Barracuda-Envelope-From: JuanCarlos.Zuniga@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Aug 2014 11:05:32 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CFC39A.AD51DDDA" Date: Fri, 29 Aug 2014 11:05:30 -0400 X-ASG-Orig-Subj: IEEE 802 EC Privacy Recommendation SG - CFP and telcos X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IEEE 802 EC Privacy Recommendation SG - CFP and telcos Thread-Index: Ac/DmYYXzC3ac61LRfCIVjbeJfUo1w== From: "Zuniga, Juan Carlos" To: , X-OriginalArrivalTime: 29 Aug 2014 15:05:32.0597 (UTC) FILETIME=[ADD71E50:01CFC39A] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1409324734 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.8954 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/saag/3WnP87aXggP6_6tyirhD1VQ8iqY Subject: [saag] IEEE 802 EC Privacy Recommendation SG - CFP and telcos X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Zuniga, Juan Carlos" List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 15:05:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CFC39A.AD51DDDA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (sorry about cross-posting) =20 Hi all, =20 At the past SAAG meeting in Toronto the creation of a new IEEE 802 Study Group (SG) on Privacy Recommendations for Link Layer technologies was announced (http://www.ietf.org/proceedings/90/slides/slides-90-saag-1.pdf).=20 =20 The IEEE 802 EC Privacy Recommendation SG has now document repository and email reflector (i.e. email list) setup.=20 Details on how to join the email list as well as on the group in general can be found here: http://www.ieee802.org/PrivRecsg/ =20 The SG is soliciting input documentation to progress the development of the work. The Study Group particularly seeks inputs on the following topics: (1) Privacy Issues at Link Layer (2) Threat Model for Privacy at Link Layer (3) Proposals regarding functionalities in IEEE 802 protocols to improve Privacy (4) Proposals regarding measuring levels of Privacy on Internet protocols =20 The group will hold a teleconference on 3 September 2014, 10:00 ET. Teleconference connection details as well as an agenda will be distributed prior to the call on the "stds-802-privacy" email list (details on the group's web page). =20 If you have any questions, please contact me by replying privately to this email. =20 Regards, =20 Juan Carlos =20 ------_=_NextPart_001_01CFC39A.AD51DDDA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(sorry = about cross-posting)

 

Hi = all,

 

At the past SAAG meeting in Toronto the creation of a = new IEEE 802 Study Group (SG) on Privacy Recommendations for Link Layer = technologies was announced (h= ttp://www.ietf.org/proceedings/90/slides/slides-90-saag-1.pdf). =

 

The IEEE 802 EC Privacy Recommendation SG has now = document repository and email reflector (i.e. email list) setup. =

Details on how to join the email = list as well as on the group in general can be found here: http://www.ieee802.org/PrivRec= sg/

 

The SG is soliciting input documentation to progress = the development of the work. The Study Group particularly seeks inputs = on the following topics:

(1)    = Privacy Issues at Link Layer

(2)    = Threat Model for Privacy at Link = Layer

(3)    = Proposals regarding functionalities in IEEE 802 = protocols to improve Privacy

(4)    = Proposals regarding measuring levels of Privacy = on Internet protocols

 

The group = will hold a teleconference on 3 September 2014, 10:00 ET. Teleconference = connection details as well as an agenda will be distributed prior to the = call on the “stds-802-privacy” email list (details on the = group’s web page).

 

If you have = any questions, please contact me by replying privately to this = email.

 

Regards,

 

Juan Carlos

 

------_=_NextPart_001_01CFC39A.AD51DDDA-- From nobody Fri Aug 29 10:03:52 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E991A02E1 for ; Fri, 29 Aug 2014 10:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlIRX3s9SZwJ for ; Fri, 29 Aug 2014 10:03:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3AD1A06AA for ; Fri, 29 Aug 2014 10:03:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B2EADBF38 for ; Fri, 29 Aug 2014 18:03:21 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rz-MZBhQXJmv for ; Fri, 29 Aug 2014 18:03:19 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.29.77]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 82B19BF30 for ; Fri, 29 Aug 2014 18:03:19 +0100 (IST) Message-ID: <5400B255.9010104@cs.tcd.ie> Date: Fri, 29 Aug 2014 18:03:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "saag@ietf.org" References: <20140829161227.13877.77743.idtracker@ietfa.amsl.com> In-Reply-To: <20140829161227.13877.77743.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140829161227.13877.77743.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/34_6apEBGpSblOAVPC12KM3O7Tg Subject: [saag] Fwd: NOMCOM 2014 - Call for Nominations X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 17:03:49 -0000 FYI. Please nominate yourself or someone else you think would be good. Cheers, S & K. -------- Forwarded Message -------- Subject: NOMCOM 2014 - Call for Nominations Date: Fri, 29 Aug 2014 09:12:27 -0700 From: NomCom Chair 2014 Reply-To: nomcom14@ietf.org To: IETF Announcement List CC: ietf@ietf.org The 2014-15 Nominating Committee (Nomcom) is seeking nominations from now until October 11, 2014. The open positions being considered by this year's Nomcom can be found at the end of this email and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2014/ Nominations may be made by selecting the Nominate link at the top of the Nomcom 2014 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2014/nominate/ {Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ } Nominations may also be made by email to nomcom13@ietf.org. If use email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Self-nomination is welcome! NomCom 2014-15 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 11, 2013. Please submit your nominations as early as possible for the sake of your nominees. Note that nominations should not wait for management permission, as it is easier to decline the nomination, than put one in late. We've set the questionnaire submission deadline for October 25, 2014. The Nomcom appoints individuals to fill the open slots on the IAOC, the IAB, and the IESG. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this Nomcom is responsible, follows: IAOC: Randy Bush IAB: Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler IESG: Pete Resnick (Applications) Ted Lemon (Internet) Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) Jari Arkko (Gen) *- known to have decline to run again. Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF, and also, please consider accepting a nomination. You'll find extensive information about specific positions, developed by the IAB, IESG, and IAOC, under individual tabs at: https://datatracker.ietf.org/nomcom/2014/requirements/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. Please send suggestions and feedback about this to nomcom14@ietf.org. Thank you for your help in identifying qualified nominees! Michael Richardson Nomcom Chair 2014-15 nomcom-chair-2014@ietf.org, mcr+nomcom@sandelman.ca