From nobody Tue Apr 1 08:59: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 429BC1A0833 for ; Tue, 1 Apr 2014 08:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 MYTLkxNrkCdv for ; Tue, 1 Apr 2014 08:59:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B16811A098F for ; Tue, 1 Apr 2014 08:59:07 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49209) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WV15b-000NE8-8u for saag@ietf.org; Tue, 01 Apr 2014 11:59:03 -0400 Message-ID: <533AE246.9080806@bbn.com> Date: Tue, 01 Apr 2014 11:59:02 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/UJ65kI03LPRzomhe2ZWe8_1Uw3E Subject: [saag] new terminology ID posted 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, 01 Apr 2014 15:59:10 -0000 revised as per SAAG discussion and directions from Stephen Farrell: https://datatracker.ietf.org/doc/draft-kent-opportunistic-security/ Steve From nobody Tue Apr 1 09:36: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 6F21E1A0505 for ; Tue, 1 Apr 2014 09:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, T_RP_MATCHES_RCVD=-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 JxEaP4yZFgQO for ; Tue, 1 Apr 2014 09:36:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 732AB1A0852 for ; Tue, 1 Apr 2014 09:36:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0B9FCBE35; Tue, 1 Apr 2014 17:36:46 +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 DnmQkQwDufxA; Tue, 1 Apr 2014 17:36:45 +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 D3EB0BDF9; Tue, 1 Apr 2014 17:36:45 +0100 (IST) Message-ID: <533AEB1E.1050000@cs.tcd.ie> Date: Tue, 01 Apr 2014 17:36:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stephen Kent , saag References: <533AE246.9080806@bbn.com> In-Reply-To: <533AE246.9080806@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/TmprPsuu4jgEZF2mXmTw_99Duak Subject: Re: [saag] new terminology ID posted 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, 01 Apr 2014 16:36:52 -0000 Thanks Steve, On 04/01/2014 04:59 PM, Stephen Kent wrote: > revised as per SAAG discussion and directions from Stephen Farrell: > > https://datatracker.ietf.org/doc/draft-kent-opportunistic-security/ Good job. Modulo some wordsmithing, I think this is good enough to go on with. I'd like to AD sponsor this as an informational RFC after we've thrashed about a bit on that wordsmithing, if there seems to be rough consensus for that. Does that sound like a good (enough!) plan to folks? *Please* note I'm asking if this is *good enough* plan not whether the document will be perfect after wordsmithing. Ideally, I'd like to see responses like: a) "go for it, and here are my editorial comments," or, b) "go for it, sorry no time for comments right now" (note: more (a)'s than (b)'s is better, a (b) is useful if you commented before maybe), or, c) "Don't do it, and here's why" with a link to whichever mail in the archive makes your point (its probably there already:-), or, if you really must, d) a mail that succinctly makes a new point as to why to not do this at all. Also: let's try control ourselves and not follow up on everything in nit-picking style, if we do go ahead with this there's time for that when we know where we're headed. If it looks like there're a good set of go-for-it responses and no real showstoppers then I think we could try for letting Steve produce a -01 based on the editorial comments you send to the list (say in the next week or two?) and then do a sorta-LC here and then an IETF LC (so maybe a -02 will be needed before IETF LC, we'll see). Thanks, S. > > Steve > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From nobody Tue Apr 1 09:37: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 C84641A0564 for ; Tue, 1 Apr 2014 09:37: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 uOSJRyYma8S1 for ; Tue, 1 Apr 2014 09:37:06 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id E98691A0852 for ; Tue, 1 Apr 2014 09:37:05 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A1C592AB270; Tue, 1 Apr 2014 16:36:54 +0000 (UTC) Date: Tue, 1 Apr 2014 16:36:54 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140401163654.GD12559@mournblade.imrryr.org> References: <533AE246.9080806@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <533AE246.9080806@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/eGKiRmT_GLfDvoP9HfUD3scSz04 Subject: Re: [saag] new terminology ID posted 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, 01 Apr 2014 16:37:09 -0000 On Tue, Apr 01, 2014 at 11:59:02AM -0400, Stephen Kent wrote: > revised as per SAAG discussion and directions from Stephen Farrell: > > https://datatracker.ietf.org/doc/draft-kent-opportunistic-security/ Thanks. A few quick comments. - There is not always a user, some applications are non-interactive, and so: 6. Use of opportunistic security must not introduce human perceptible delays in session/connection establishment, as that will discourage its use. As a result, authentication and MiTM detection should take place after an encrypted session is established. This ordering implies that some data may be transmitted prior to authentication or detection of a MiTM. is not necessarily applicable. Even with human users (see below) some modes of opportunistic security may be strong enough to make MiTM protection worth the wait. - With DANE used opportunistically, i.e. only for connections to servers that publish usable DNSSEC validated TLSA records, and otherwise a fallback to unauthenticated TLS or even cleartext, there is in fact MiTM and integrity protection when said usable TLSA records are published. Connections to DANE authenticated servers can for many applications be considered sufficiently well authenticated to be equivalent to cases in which strong authentication was required. The difference is that policy about which destinations are fully protected is not fixed at the client, rather the policy is securely published by some destination systems and applied only to those systems that publish such policy (say in form of DANE TLSA records). It seems that the draft defintion of the the umbrella term "opportunistic security" may not extend quite far enough from a floor of "better than nothing" a strongly authenticated ceiling in cases where strong authentication policy is partly published by the server system, and thus from the client's perspective is applied only when possible. http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane -- Viktor. From nobody Tue Apr 1 10:45: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 9A09D1A09A1 for ; Tue, 1 Apr 2014 10:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 n8w20UjqwakD for ; Tue, 1 Apr 2014 10:45:34 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA821A09B4 for ; Tue, 1 Apr 2014 10:45:34 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A3336165579; Tue, 1 Apr 2014 17:45:30 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (unknown [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 98182165574; Tue, 1 Apr 2014 17:45:30 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 802219803D; Tue, 1 Apr 2014 17:45:30 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Tue, 1 Apr 2014 13:45:30 -0400 From: "Salz, Rich" To: Stephen Farrell , Stephen Kent , saag Date: Tue, 1 Apr 2014 13:45:28 -0400 Thread-Topic: [saag] new terminology ID posted Thread-Index: Ac9NyJZhi0/g/98nQIqAa/s5jMzr+gABEY/Q Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711FD90F644@USMBX1.msg.corp.akamai.com> References: <533AE246.9080806@bbn.com> <533AEB1E.1050000@cs.tcd.ie> In-Reply-To: <533AEB1E.1050000@cs.tcd.ie> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/bYLuU7UdwYdtRgnvzTSKImdT91Y Subject: Re: [saag] new terminology ID posted 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, 01 Apr 2014 17:45:35 -0000 I just read it, pretty carefully. Definitely "go for it"; this is a very r= eadable and useful/important document. A few nits below, most on the level= of typo's. Is this the first time an RFC has used "OUGHT NOT"? :) I think Victor's concerns about #6 are addressed by saying "if it's two pro= grams talking, it's not human perceptible" Although perhaps some wording ma= king that explicit is a good idea.1 In #7, should OK be OS? And there's a spurious ">" before Since. Sec 2 (ever consider a career at the OED? :) "In fact, it the key manageme= nt process" is an is missing there? In Sec 3 about S/MIME, "so the originator knows" seems a little off; perhap= s "can specify" instead of knows? In the last paragraph "and alternative w= ay" should be "an" "Lof or TOFU" since they're the same, perhaps the or sh= ould become a parenthetical "(also known as" And I think TOFU is more well= -known, even if LoF is more evocative. In sec 4, "to avoid the term 'anonymous' her" should be "here".And a missin= g space after the period. Should the reference to RFC2818 also reference 67= 97? Sec 5, extra space between (data) and confidentiality. Shared secret refer= ences CEK without any definition. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Tue Apr 1 10:59: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 34D281A0997 for ; Tue, 1 Apr 2014 10:59: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 2flxbQpKZB81 for ; Tue, 1 Apr 2014 10:59:22 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 281121A098F for ; Tue, 1 Apr 2014 10:59:22 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9F99F2AB276; Tue, 1 Apr 2014 17:59:16 +0000 (UTC) Date: Tue, 1 Apr 2014 17:59:16 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140401175916.GG12559@mournblade.imrryr.org> References: <533AE246.9080806@bbn.com> <533AEB1E.1050000@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C711FD90F644@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FD90F644@USMBX1.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/qjHKZBTqOIpwQVIKysONNq56nbc Subject: Re: [saag] new terminology ID posted 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, 01 Apr 2014 17:59:24 -0000 On Tue, Apr 01, 2014 at 01:45:28PM -0400, Salz, Rich wrote: > I think Victor's concerns about #6 are addressed by saying "if > it's two programs talking, it's not human perceptible" Although > perhaps some wording making that explicit is a good idea.1 [ By the way, go for it. ] Perhaps "human user" is not the key difference. Some applications are latency-sensitive, and others latency tolerant. In latency- sensitive applications, where opportunistic security is competing with no security, one should indeed pay attention to the latency cost, and perhaps be willing to cut corners on round-trips if stronger authentication means substantially higher latency. -- Viktor. From nobody Tue Apr 1 11:46: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 57FBE1A08AC for ; Tue, 1 Apr 2014 11:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 WuaifUV2phae for ; Tue, 1 Apr 2014 11:46:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8BC1A09C7 for ; Tue, 1 Apr 2014 11:46:48 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49595) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WV3hr-0001TP-SC for saag@ietf.org; Tue, 01 Apr 2014 14:46:43 -0400 Message-ID: <533B0993.80001@bbn.com> Date: Tue, 01 Apr 2014 14:46:43 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> In-Reply-To: <20140401163654.GD12559@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/Bm17jKv0mezkpfs0kiHEuZg5AKg Subject: Re: [saag] new terminology ID posted 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, 01 Apr 2014 18:46:50 -0000 Viktor, >> revised as per SAAG discussion and directions from Stephen Farrell: >> >> https://datatracker.ietf.org/doc/draft-kent-opportunistic-security/ > Thanks. A few quick comments. > > - There is not always a user, some applications are non-interactive, > and so: > > 6. Use of opportunistic security must not introduce human > perceptible delays in session/connection establishment, as that > will discourage its use. As a result, authentication and MiTM > detection should take place after an encrypted session is > established. This ordering implies that some data may be > transmitted prior to authentication or detection of a MiTM. > > is not necessarily applicable. Even with human users (see below) > some modes of opportunistic security may be strong enough to make > MiTM protection worth the wait. I called out human users because in that context perceptible delays may pose problems wrt adoption. The sense at the STRINT workshop was that, in general, since these services are invisible, we should strive to make them painless. That motivates performing MiTM detection and authentication in parallel, after establishing an encrypted session. I have changed the text to make it clear that the delay issue is specific to apps with human users. However, that does not address the rest of your concerns. > - With DANE used opportunistically, i.e. only for connections to > servers that publish usable DNSSEC validated TLSA records, > and otherwise a fallback to unauthenticated TLS or even > cleartext, there is in fact MiTM and integrity protection > when said usable TLSA records are published. Connections to > DANE authenticated servers can for many applications be > considered sufficiently well authenticated to be equivalent > to cases in which strong authentication was required. I agree that the example you cite provides very good security, equivalent or better (given the problems with Web PKI) to an HTTPS connection to a server. I can re-word #6 to accommodate the example you cited. But, it is an example that requires the target of a session to publish a DANE record. Thus it may not result in as much encryption as a mechanism which does not impose that prerequisite. Folks will have to decide if we want to create a different term for DANE-enabled TLS (and IPsec) sessions, or broaden the definition of opportunistic security to encompass them. I'm happy to generate text to accommodate whatever folks decide. > The difference is that policy about which destinations are > fully protected is not fixed at the client, rather the policy > is securely published by some destination systems and applied > only to those systems that publish such policy (say in form > of DANE TLSA records). I understand. > It seems that the draft defintion of the the umbrella term > "opportunistic security" may not extend quite far enough from > a floor of "better than nothing" a strongly authenticated > ceiling in cases where strong authentication policy is partly > published by the server system, and thus from the client's > perspective is applied only when possible. see my comment above re your example. Steve From nobody Tue Apr 1 11:48: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 37D2E1A09CD for ; Tue, 1 Apr 2014 11:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 arXchYdbwQki for ; Tue, 1 Apr 2014 11:48:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id E70071A08AC for ; Tue, 1 Apr 2014 11:48:36 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49596) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WV3jd-0001Ve-CI for saag@ietf.org; Tue, 01 Apr 2014 14:48:33 -0400 Message-ID: <533B0A01.1090704@bbn.com> Date: Tue, 01 Apr 2014 14:48:33 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag References: <533AE246.9080806@bbn.com> <533AEB1E.1050000@cs.tcd.ie> <2A0EFB9C05D0164E98F19BB0AF3708C711FD90F644@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FD90F644@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/q7nD1nl0PA1Ly5gYQ-kyY9Zh-w4 Subject: Re: [saag] new terminology ID posted 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, 01 Apr 2014 18:48:38 -0000 Rich, Thanks for the comments and for spotting the typos. > I just read it, pretty carefully. Definitely "go for it"; this is a very readable and useful/important document. A few nits below, most on the level of typo's. > > Is this the first time an RFC has used "OUGHT NOT"? :) see RFC 6919 :-). > I think Victor's concerns about #6 are addressed by saying "if it's two programs talking, it's not human perceptible" Although perhaps some wording making that explicit is a good idea. two apps may not be as sensitive to delays as people, hence my choice of terms. I've replied to Viktor separately, as the issue he raised is based on issues other than human vs. machine "users". > In #7, should OK be OS? And there's a spurious ">" before Since. fixed. > Sec 2 (ever consider a career at the OED? :) I am someone who knows when to use fewer vs. less, that vs. which, etc. :-) > "In fact, it the key management process" is an is missing there? fixed. > In Sec 3 about S/MIME, "so the originator knows" seems a little off; perhaps "can specify" instead of knows? In the last paragraph "and alternative way" should be "an" "Lof or TOFU" since they're the same, perhaps the or should become a parenthetical "(also known as" And I think TOFU is more well-known, even if LoF is more evocative. fixed, and fixed. > In sec 4, "to avoid the term 'anonymous' her" should be "here".And a missing space after the period. Should the reference to RFC2818 also reference 6797? fixed. > Sec 5, extra space between (data) and confidentiality. Shared secret references CEK without any definition. fixed. From nobody Tue Apr 1 12:26: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 E6AAF1A09C0 for ; Tue, 1 Apr 2014 12:26: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 azdtk7063opt for ; Tue, 1 Apr 2014 12:26:08 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 497961A07F4 for ; Tue, 1 Apr 2014 12:26:08 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 69EA32AB273; Tue, 1 Apr 2014 19:26:03 +0000 (UTC) Date: Tue, 1 Apr 2014 19:26:03 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140401192603.GI12559@mournblade.imrryr.org> References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <533B0993.80001@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ixAzd-70ysqw_jGhZVaPBQ6L41I Subject: Re: [saag] new terminology ID posted 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, 01 Apr 2014 19:26:10 -0000 On Tue, Apr 01, 2014 at 02:46:43PM -0400, Stephen Kent wrote: > > - With DANE used opportunistically, i.e. only for connections to > > servers that publish usable DNSSEC validated TLSA records, > > and otherwise a fallback to unauthenticated TLS or even > > cleartext, there is in fact MiTM and integrity protection > > when said usable TLSA records are published. Connections to > > DANE authenticated servers can for many applications be > > considered sufficiently well authenticated to be equivalent > > to cases in which strong authentication was required. > > I agree that the example you cite provides very good security, equivalent > or better (given the problems with Web PKI) to an HTTPS connection to a > server. I can re-word #6 to accommodate the example you cited. But, it > is an example that requires the target of a session to publish a DANE > record. > > Thus it may not result in as much encryption as a mechanism which does not > impose that prerequisite. Folks will have to decide if we want to create a > different term for DANE-enabled TLS (and IPsec) sessions, or broaden the > definition of opportunistic security to encompass them. I'm happy to > generate text to accommodate whatever folks decide. I was hoping that "opportunistic DANE TLS" (the proposed terminology for this type of security policy in the DANE SMTP draft) will fit under the broad "umbrella term" of "opportunistic security". In other words "opportunistic security" has no explicit floor or ceiling. -- Viktor. From nobody Tue Apr 1 12:49: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 EE6801A09F9 for ; Tue, 1 Apr 2014 12:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ipdBJLm2Q8cQ for ; Tue, 1 Apr 2014 12:49:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 42B8F1A09A8 for ; Tue, 1 Apr 2014 12:49:25 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49813) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WV4gU-0002wn-2y for saag@ietf.org; Tue, 01 Apr 2014 15:49:22 -0400 Message-ID: <533B1841.20102@bbn.com> Date: Tue, 01 Apr 2014 15:49:21 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140401192603.GI12559@mournblade.imrryr.org> In-Reply-To: <20140401192603.GI12559@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/sqSgWkptw1TTcZ2QNihCE1HRknY Subject: Re: [saag] new terminology ID posted 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, 01 Apr 2014 19:49:28 -0000 Viktor, > ... > I was hoping that "opportunistic DANE TLS" (the proposed terminology > for this type of security policy in the DANE SMTP draft) will fit > under the broad "umbrella term" of "opportunistic security". I'm not saying it won't. That's not for me to decide. We are still working on the text. > In other words "opportunistic security" has no explicit floor or > ceiling. I disagree on this point. If there is no floor, then doing nothing could count, and that doesn't make sense to me. We have existing security mechanisms that may yield better security than OS, so they should not be encompassed by the term, hence there ought to be a ceiling as well. Steve From nobody Tue Apr 1 12:55: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 3E79A1A09C8 for ; Tue, 1 Apr 2014 12:55:35 -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_HYg5-_apsW for ; Tue, 1 Apr 2014 12:55:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 43CEB1A09A8 for ; Tue, 1 Apr 2014 12:55:33 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 21A062AB273; Tue, 1 Apr 2014 19:55:29 +0000 (UTC) Date: Tue, 1 Apr 2014 19:55:29 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140401195528.GJ12559@mournblade.imrryr.org> References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140401192603.GI12559@mournblade.imrryr.org> <533B1841.20102@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <533B1841.20102@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/N-vZaCTRUxExj9VqxGLC-9sHtXA Subject: Re: [saag] new terminology ID posted 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, 01 Apr 2014 19:55:35 -0000 On Tue, Apr 01, 2014 at 03:49:21PM -0400, Stephen Kent wrote: > >In other words "opportunistic security" has no explicit floor or > >ceiling. > > I disagree on this point. If there is no floor, then doing nothing > could count, and that doesn't make sense to me. We have existing security > mechanisms that may yield better security than OS, so they should not > be encompassed by the term, hence there ought to be a ceiling as well. Sorry, agreed about not encompassing mandatory non-opportunistic cases. I meant no floor or ceiling on the actual security achieved for a given connection. It may be none, it may be as strong or stronger than traditional PKIX. The difference is that the security achieved is roughly the best possible under the circumstances (though DANE may resist downgrade attacks). Given that there's no real confusion about the points made, I think that's all on this subject from me for now. -- Viktor. From nobody Thu Apr 3 06:00: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 C13E71A01BC for ; Thu, 3 Apr 2014 06:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 oV-6yIYXCHse for ; Thu, 3 Apr 2014 06:00:00 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id AB7051A011F for ; Thu, 3 Apr 2014 05:59:59 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s33CxkuT019163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Apr 2014 15:59:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s33CxkVt001523; Thu, 3 Apr 2014 15:59:46 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21309.23361.800534.331977@fireball.kivinen.iki.fi> Date: Thu, 3 Apr 2014 15:59:45 +0300 From: Tero Kivinen To: Stephen Farrell In-Reply-To: <533AEB1E.1050000@cs.tcd.ie> References: <533AE246.9080806@bbn.com> <533AEB1E.1050000@cs.tcd.ie> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 47 min X-Total-Time: 68 min Archived-At: http://mailarchive.ietf.org/arch/msg/saag/xejf6cxd-rRtccvPtVdVlLiiA-A Cc: saag Subject: Re: [saag] new terminology ID posted 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, 03 Apr 2014 13:00:06 -0000 Stephen Farrell writes: > a) "go for it, and here are my editorial comments," or, I would say "go for it"... and here is my comments to it: ---------------------------------------------------------------------- In 3) in Section 1 there is reference to IKE but the RFC points to the TLS 1.0: passive wiretapping. IKE [RFC2246] has offered this capability, ^^^^^^^ though it does not appear to be commonly used.) This should be RFC5996 (and this is why I like much better to use refences in style of [IKEv2] than [RFC5996]). -- In section 2 we should refer to IKEv2 not IKE first, as RFC2409 is obsoleted by RFC5996: Opportunistic encryption still calls for each party to identify the other, using IKE [RFC2409] (equivalently, IKE v2 [RFC5996]) authentication mechanisms, so it is not an unauthenticated key management approach. .... i.e change "using IKE [RFC2409] (equivalently, IKE v2 [RFC5996])" to "using IKEv2 [RFC5996] (equivalently, IKEv1 [RFC2409])" -- In section 3 it says that TLS uses LoF or TOFU for the client authentication, but I do not think that is true: TLS normally affords server authentication (based on X.509 certificates and the so-called Web PKI), and offers optional support for client authentication based on a leap of faith (LoF) or trust on first use (TOFU) approach. Because SSH is most often employed in an enterprise context, reliance on these initial authentication mechanisms represents a reasonable risk- based design tradeoff. Both LoF and TOFU quite often do require user interface i.e user to be able to notified if the certificate changes or whether this is new connection. When doing TLS *CLIENT* authentication the server does not have user at all, so using LoF or TOFU there would be hard. I would say that in TLS the client authentication is commonly not done at all inside the TLS, but it is done after the connection to the server is done in a form of user name and password or similar non-cryptographic ways. The next paragraph talks about SSH, but even in SSH it does not use LoF or TOFU on the *CLIENT* authentication. SSH commonly uses the method where the first connection to new server gives a warning saying this is new connection and user will accept the connection and the key returned from the other end on the first connection is stored to the database and checked for all later uses. If key is changed then user is given again a warning asking what to do (connect anyways, connect and change the key in database, or do not connect). All of this is done on the server authentication not client authentication. There is no CLIENT authentication in the SSH, there is USER authentication which usually will require server and client to share some kind of bilateral arrangement (store the password to the server side database, or store the user's public key to the authorized keys file on the server etc), and this user authentication is run after the server authentication has finished. As the next paragraph talks about the TLS, I assume the first paragraph was supposed to talk only about SSH, i.e. the first TLS was typo. BTW, I myself have categorized the different generic IETF security protocols as follows: +---------------+-----------------------+---------------------+ | | Bilateral | Unilateral | | | agreement | or no | | | between | agreement | | | peers | between peers | +---------------+-----------------------+---------------------+ | Above TCP | SSH | TLS | | i.e. usually | | | | implementable | | | | in usermode | | | | | | | | Asymmetric | | | | authentication| | | +---------------+-----------------------+---------------------+ | Below TCP | IKE | HIP | | i.e. usually | | | | do require | | | | kernel change | | | | | | | | Symmetric | | | | authentication| | | +---------------+-----------------------+---------------------+ Of course TLS with client authentication will require bilateral agreement, and also if you use TLS with username + password authentication over HTTP or similar that will require bilateral agreement. On the other hand Opportunistic Encryption in IPsec does not require bilater agreement, i.e it moves to the same box than HIP. I.e. the uses for the protocols are not that clear, but that gives at least in my understanding the basic idea where the protocol was designed for and/or what is the main use for it now. The bilateral agreement makes it harder to get it used everywhere. Unilateral or no-agreement are much easier in that sense (usable everywhere). Whether the protocol can be implemented in the usermode (or inside application) that makes it much easier to get it deployed everywhere. Requiring access to parts below TCP stack usually requires kernel modification or at least special credentials which makes it much harder to deploy the protocol everywhere. Symmetric authentication is more suitable in peer to peer connection, compared to the asymmetric authentication where the protocol is more suitable for client (with user) and server uses. -- In section 4 you have reference to the RFC4306 (IKEv2), which should be replaced with RFC5996 (latest version of IKEv2). Also there is text saying: Finally, we avoid using the term "unauthenticated encryption" because "authenticated encryption" is a well-defined term in the crypto community. Instead we use the term "authenticated encrypted communication". Is this text correct? You say we avoid using therm "unauthenticatged encryption" but use "authenticated encrypted communication" instead? I would assume both of them should either say "unauthenticated" or "authenticated", i.e. change the text to say '... term "unauthenticated encrypted communication".' -- kivinen@iki.fi From nobody Thu Apr 3 08:46: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 837811A0229 for ; Thu, 3 Apr 2014 08:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 5gru233BFQWq for ; Thu, 3 Apr 2014 08:46: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 CD2E31A020A for ; Thu, 3 Apr 2014 08:46:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 45B82BE55 for ; Thu, 3 Apr 2014 16:46:11 +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 hUoa20C-zDL5 for ; Thu, 3 Apr 2014 16:46:11 +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 23D0ABE51 for ; Thu, 3 Apr 2014 16:46:11 +0100 (IST) Message-ID: <533D8243.4020603@cs.tcd.ie> Date: Thu, 03 Apr 2014 16:46:11 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "saag@ietf.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/_X_Najhse9qZb5IXyCF2qTPgni0 Subject: [saag] London 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: Thu, 03 Apr 2014 15:46:20 -0000 Mea culpa for being late with these. I've posted them at [1]. Not that much there I think but do let me know if anything needs adding/fixing. Regards, Stephen. [1] http://www.ietf.org/proceedings/89/minutes/minutes-89-saag From nobody Thu Apr 3 10:52: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 8E9801A0104 for ; Thu, 3 Apr 2014 10:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 ceVOTo31Hr4r for ; Thu, 3 Apr 2014 10:52:16 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8A12F1A0218 for ; Thu, 3 Apr 2014 10:52:16 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 475CF9A43DB for ; Thu, 3 Apr 2014 13:52:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id gSTmLQaL5SWZ for ; Thu, 3 Apr 2014 13:51:41 -0400 (EDT) Received: from [192.168.2.100] (pool-96-241-160-129.washdc.fios.verizon.net [96.241.160.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A8CF1F2C073 for ; Thu, 3 Apr 2014 13:51:41 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Apr 2014 13:51:30 -0400 Message-Id: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> To: IETF SAAG Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/sNzb2hQ1zMdE1nR2N7ArKhhA12g Subject: [saag] draft-iab-crypto-alg-agility-00 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, 03 Apr 2014 17:52:21 -0000 I gave a presentation at the SAAG session in London about this document. = Stephen said that the discussion would continue on this list. I'm = posting this message to get that discussion going. Russ From nobody Fri Apr 4 07:23: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 4E0561A019C for ; Fri, 4 Apr 2014 07:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 o9QLy2Pdu7gd for ; Fri, 4 Apr 2014 07:23:12 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id CCC6C1A01DE for ; Fri, 4 Apr 2014 07:23:09 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:34553 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WW51U-00012j-RN for saag@ietf.org; Fri, 04 Apr 2014 10:23:13 -0400 Message-ID: <533EC048.1010603@bbn.com> Date: Fri, 04 Apr 2014 10:23:04 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <533AE246.9080806@bbn.com> <533AEB1E.1050000@cs.tcd.ie> <21309.23361.800534.331977@fireball.kivinen.iki.fi> In-Reply-To: <21309.23361.800534.331977@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/LvpYt9q1A26OgULxUoBY1DfOY6E Subject: Re: [saag] new terminology ID posted 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, 04 Apr 2014 14:23:17 -0000 Tero, Thanks for your comments. Responses inline below. > Stephen Farrell writes: >> a) "go for it, and here are my editorial comments," or, > I would say "go for it"... > > and here is my comments to it: > ---------------------------------------------------------------------- > In 3) in Section 1 there is reference to IKE but the RFC points to the > TLS 1.0: > > passive wiretapping. IKE [RFC2246] has offered this capability, > ^^^^^^^ > though it does not appear to be commonly used.) > > This should be RFC5996 (and this is why I like much better to use > refences in style of [IKEv2] than [RFC5996]). I've been working with two colleagues here at BBN to do the edits and some errors have crept in via that interaction. We've fixed this reference to point to IKEv2. At this stage I am loathe to change the reference style throughout the doc, but when we near the end we can revisit that decision. > -- > > In section 2 we should refer to IKEv2 not IKE first, as RFC2409 is > obsoleted by RFC5996: > > Opportunistic encryption still calls for each party to identify the > other, using IKE [RFC2409] (equivalently, IKE v2 [RFC5996]) > authentication mechanisms, so it is not an unauthenticated key > management approach. .... > > i.e change "using IKE [RFC2409] (equivalently, IKE v2 [RFC5996])" to > "using IKEv2 [RFC5996] (equivalently, IKEv1 [RFC2409])" fixed. > > -- > > In section 3 it says that TLS uses LoF or TOFU for the client > authentication, but I do not think that is true: > > TLS normally affords server > authentication (based on X.509 certificates and the so-called Web > PKI), and offers optional support for client authentication based on > a leap of faith (LoF) or trust on first use (TOFU) approach. Because > SSH is most often employed in an enterprise context, reliance on > these initial authentication mechanisms represents a reasonable risk- > based design tradeoff. another editing whoops that we have fixed. > Both LoF and TOFU quite often do require user interface i.e user to be > able to notified if the certificate changes or whether this is new > connection. When doing TLS *CLIENT* authentication the server does not > have user at all, so using LoF or TOFU there would be hard. absolutely correct. > I would say that in TLS the client authentication is commonly not done > at all inside the TLS, but it is done after the connection to the > server is done in a form of user name and password or similar > non-cryptographic ways. agreed. > The next paragraph talks about SSH, but even in SSH it does not use > LoF or TOFU on the *CLIENT* authentication. SSH commonly uses the > method where the first connection to new server gives a warning saying > this is new connection and user will accept the connection and the key > returned from the other end on the first connection is stored to the > database and checked for all later uses. If key is changed then user > is given again a warning asking what to do (connect anyways, connect > and change the key in database, or do not connect). All of this is > done on the server authentication not client authentication. yes. I have revised the text here to make clear that TOFU/LoF applies to server, not client, auth. > There is no CLIENT authentication in the SSH, there is USER > authentication which usually will require server and client to share > some kind of bilateral arrangement (store the password to the server > side database, or store the user's public key to the authorized keys > file on the server etc), and this user authentication is run after the > server authentication has finished. I have added some text to better describe SSH user auth. Let me know if the text in the next rev suffices. > As the next paragraph talks about the TLS, I assume the first > paragraph was supposed to talk only about SSH, i.e. the first TLS was > typo. Actually, it was the other way around, but because text was mashed together in the course of making revisions, the result was just a mess. > BTW, I myself have categorized the different generic IETF security > protocols as follows: > > +---------------+-----------------------+---------------------+ > | | Bilateral | Unilateral | > | | agreement | or no | > | | between | agreement | > | | peers | between peers | > +---------------+-----------------------+---------------------+ > | Above TCP | SSH | TLS | > | i.e. usually | | | > | implementable | | | > | in usermode | | | > | | | | > | Asymmetric | | | > | authentication| | | > +---------------+-----------------------+---------------------+ > | Below TCP | IKE | HIP | > | i.e. usually | | | > | do require | | | > | kernel change | | | > | | | | > | Symmetric | | | > | authentication| | | > +---------------+-----------------------+---------------------+ Nice diagram. I'll have to see if we can make use of it, or a similar version in the future. > Of course TLS with client authentication will require bilateral > agreement, and also if you use TLS with username + password > authentication over HTTP or similar that will require bilateral > agreement. agreed, but when one uses a password with TLS it's not part of TLS anymore, it's the app above TLS. I want to address intrinsic properties of the protocols, as specified and as commonly used, in this doc. > On the other hand Opportunistic Encryption in IPsec does not require > bilater agreement, i.e it moves to the same box than HIP. I.e. the > uses for the protocols are not that clear, but that gives at least in > my understanding the basic idea where the protocol was designed for > and/or what is the main use for it now. agreed. do you think we need to include more text about this? > The bilateral agreement makes it harder to get it used everywhere. > Unilateral or no-agreement are much easier in that sense (usable > everywhere). Whether the protocol can be implemented in the usermode > (or inside application) that makes it much easier to get it deployed > everywhere. Requiring access to parts below TCP stack usually requires > kernel modification or at least special credentials which makes it > much harder to deploy the protocol everywhere. yes, bilateral, a priori agreement requirements are clearly an impediment to deployment, and thus should be avoided when one is trying to maximize use of encryption. (Gee, I guess I should find a place to say that :-) in the doc.) Also, changes to kernel code are another impediment to deployment, at least in terms of rate of uptake. (The recent comments about how many copies of XP are still in use should be a lesson for us re OS-based changes.) > Symmetric authentication is more suitable in peer to peer connection, > compared to the asymmetric authentication where the protocol is more > suitable for client (with user) and server uses. I'll have to think about that. IPsec is p-t-p. > -- > > In section 4 you have reference to the RFC4306 (IKEv2), which should > be replaced with RFC5996 (latest version of IKEv2). fixed. > Also there is text saying: > > Finally, we avoid using the term "unauthenticated > encryption" because "authenticated encryption" is a well-defined term > in the crypto community. Instead we use the term "authenticated > encrypted communication". > > Is this text correct? You say we avoid using therm "unauthenticatged > encryption" but use "authenticated encrypted communication" instead? I > would assume both of them should either say "unauthenticated" or > "authenticated", i.e. change the text to say '... term "unauthenticated > encrypted communication".' fixed. Thanks for all of the comments. Steve From nobody Fri Apr 4 07:55: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 4DAB11A018C for ; Fri, 4 Apr 2014 07:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ZUkoCpyRSq7z for ; Fri, 4 Apr 2014 07:55:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 453481A0134 for ; Fri, 4 Apr 2014 07:55:28 -0700 (PDT) Received: from [192.168.131.138] ([80.92.122.106]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LcT2M-1Wuj6q1i8E-00joKL for ; Fri, 04 Apr 2014 16:55:22 +0200 Message-ID: <533EC0A7.7090200@gmx.net> Date: Fri, 04 Apr 2014 16:24:39 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <533EC002.2010506@gmx.net> In-Reply-To: <533EC002.2010506@gmx.net> X-Enigmail-Version: 1.5.2 X-Forwarded-Message-Id: <533EC002.2010506@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ThkWMMcEKP01uNWmTQpO1bKEhA6VKPA4A" X-Provags-ID: V03:K0:/EXj9C9U1qMmWCh9lLE2TbTuTWXeu63fa72kUw5C3yN3J7pqU4t XvikswdKbaJKU4DiQlL2AYf9M2no+CLOEal8fyU+YemBYMXvF/7q62gdcrrGGN9iFxFehlk B/7uf/bWyeAAsYkKd+7SqJ4oNeZcV6Nc6qhcsWtvlyvIHNMtaa/yF69uLb/vDOd8qF1/WXg jn5ktBa1udxf6pz4BpnUw== Archived-At: http://mailarchive.ietf.org/arch/msg/saag/DISjgTm084ziug_g4g5bKpiWHdc Subject: [saag] Fwd: ABFAB Tutorial - April 22nd 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, 04 Apr 2014 14:55:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ThkWMMcEKP01uNWmTQpO1bKEhA6VKPA4A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI: In case someone of you is interested in a tutorial about ABFAB and how it applies to Internet of Things (and to the ACE work in particular).= Ciao Hannes PS: Infos about ACE: https://www.ietf.org/mailman/listinfo/ace Previous tutorials: http://www.tschofenig.priv.at/wp/?p=3D1012 -------- Original Message -------- Subject: ABFAB Tutorial - April 22nd Date: Fri, 04 Apr 2014 16:21:54 +0200 From: Hannes Tschofenig To: ace@ietf.org Hi all, at the ACE BOF we promised to also schedule a tutorial about ABFAB. We have been working with Margaret, Sam, and Rhys on the details and they kindly offered to give us an overview of ABFAB and how it applies to the IoT space. Date: Tuesday, April 22, 2014 Time: 1:00 pm BST =3D 8am EDT =3D 8pm CST http://www.timeanddate.com/worldclock/meetingdetails.html?year=3D2014&mon= th=3D4&day=3D22&hour=3D12&min=3D0&sec=3D0&p1=3D37&p2=3D136&p3=3D179&p4=3D= 33 Webex: https://ietf.webex.com/ietf/j.php?MTID=3Dmd4e56d458aa66a2bbdfd2e1463dbc97= 7 Meeting Number: 644 405 818 Meeting Password: abfab Audio: +1-650-479-3208 Access code:644 405 818 Due to the IETF Webex configuration restrictions there are no other dial-in codes available. Ciao Hannes & Kepeng --ThkWMMcEKP01uNWmTQpO1bKEhA6VKPA4A 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.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTPsCnAAoJEGhJURNOOiAtlwgH/0l7Kpgr3pRimWfJryAmjr+9 T0Lb7w+Kf12TfZ9p6KhoUTB7ZBF4K6aN690X3ctJNqIw1nJD91rs2EFRGcqjEE75 nZ96sWqaLZ5Vwwb38Lka0/jG1XNLIutqp4QjXT6qllZYFcazz9rO4Q0IrjDX9mTK nAfG6mFcdxTcSGhaOH++s4becQMo2V1ELJsqVqJBNj94n7siDeN1nEI45RpIs3S7 PnwfHZPV6tF8rV2JE2fTr/sqV2cEXN6IBlQkPvdSp9mtTvSTZZpCB5b3ggEPqJ+x ImHXSyRQ3E6O4jNE2NoAxbAfx9p33+/AbBhck5zrwUhz3U3Hisd9+5nFjyduThQ= =QapS -----END PGP SIGNATURE----- --ThkWMMcEKP01uNWmTQpO1bKEhA6VKPA4A-- From nobody Sat Apr 5 14:11: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 739241A02D1 for ; Sat, 5 Apr 2014 14:11:40 -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] 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 4vo0jfZFLsF0 for ; Sat, 5 Apr 2014 14:11:36 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBAD1A02DC for ; Sat, 5 Apr 2014 14:11:36 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id B46032005D106; Sat, 5 Apr 2014 14:11: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=XHp4tHBrNeyxj3 t9br602tHRj4I=; b=JHENVcIDNKUv7V02d6ktYZFmtQlJgKZkC0twVcPg+rsCEm e7nTeDC/qSbRGXjmZeeRLtjLTAkYp5b4htTHrRcSrda/87hu5lFrFcOT0Upgt0AE 7n0RufIXWreEWKG4WRDqWDk4CzLpTSxtYnt86F9LLI+a1T6v152rMoTQu0izk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPA id 6A1D92005D107; Sat, 5 Apr 2014 14:11:31 -0700 (PDT) Date: Sat, 5 Apr 2014 16:11:30 -0500 From: Nico Williams To: Stephen Kent Message-ID: <20140405211129.GE2727@localhost> References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <533B0993.80001@bbn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/U6qnKvbGw6PFm6x7LBH60Uam96o Cc: saag@ietf.org Subject: Re: [saag] new terminology ID posted 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, 05 Apr 2014 21:11:40 -0000 On Tue, Apr 01, 2014 at 02:46:43PM -0400, Stephen Kent wrote: > > - With DANE used opportunistically, i.e. only for connections to > > servers that publish usable DNSSEC validated TLSA records, > > and otherwise a fallback to unauthenticated TLS or even > > cleartext, there is in fact MiTM and integrity protection > > when said usable TLSA records are published. Connections to > > DANE authenticated servers can for many applications be > > considered sufficiently well authenticated to be equivalent > > to cases in which strong authentication was required. > > I agree that the example you cite provides very good security, equivalent > or better (given the problems with Web PKI) to an HTTPS connection to a > server. I can re-word #6 to accommodate the example you cited. But, it > is an example that requires the target of a session to publish a > DANE record. Right: DANE affords the client opportunistic _and_ strong security (as strong as the DNSSEC) IFF the targets publish TLSA RRsets for themselves. But why wouldn't targets do that? I believe they will when doing so becomes widely recognized as a best practice, which I believe will happen. > Thus it may not result in as much encryption as a mechanism which does not > impose that prerequisite. Folks will have to decide if we want to create a > different term for DANE-enabled TLS (and IPsec) sessions, or broaden the > definition of opportunistic security to encompass them. I'm happy to > generate > text to accommodate whatever folks decide. One might still always use TLS (with PKI or no authentication at all) when TLSA RRsets are not found, but now we have fallback-to-no-TLS security issues. DANE removes the fallback problem , which is why DANE should quickly become a best practice. Nico -- From nobody Sat Apr 5 14:20: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 70D231A02F6 for ; Sat, 5 Apr 2014 14:20:35 -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] 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 QjjMV1WiSfN2 for ; Sat, 5 Apr 2014 14:20:31 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9704F1A02DB for ; Sat, 5 Apr 2014 14:20:31 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id CACDE2005D10D; Sat, 5 Apr 2014 14:20:26 -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=r848acQtlr6cuO pWqvwra8J8zU0=; b=wNaMQavSVHp/zZyR+0BlxvoGRm40hS94ZVK/wou2gPNu9d FUWL19rJqXYNShSFFYvva3EoyE6PJ/nYMnhboTdCo2H5/45vXvXfbe/I73OHQNhr Sm37XnqNetXmM0VE4ZGlDBim0OvIXtoqZxNbIvYkIglgkCpk3Z9q67M0hxJqk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPA id 879832005D10B; Sat, 5 Apr 2014 14:20:26 -0700 (PDT) Date: Sat, 5 Apr 2014 16:20:25 -0500 From: Nico Williams To: Stephen Kent Message-ID: <20140405212023.GF2727@localhost> References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <533B0993.80001@bbn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/SiyGGh__L3uA8or2jyolStv2qxo Cc: saag@ietf.org Subject: Re: [saag] new terminology ID posted 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, 05 Apr 2014 21:20:35 -0000 On Tue, Apr 01, 2014 at 02:46:43PM -0400, Stephen Kent wrote: > Thus it may not result in as much encryption as a mechanism which does not > impose that prerequisite. Folks will have to decide if we want to create a > different term for DANE-enabled TLS (and IPsec) sessions, or broaden the > definition of opportunistic security to encompass them. I'm happy to > generate text to accommodate whatever folks decide. Er, are you asking for a consensus call on this point? I'm definitely for DANE-enabled TLS. Who wouldn't be? Can we hear some arguments against? I'm curious about this. Or, if we don't hear any such arguments, then I think we must have consensus on this point. Until then, what's the harm in including "DANE-enabled TLS" in your I-D? How might we get feedback on that if you don't? As to IPsec, I really think there are two "correct" approaches to making end-to-end IPsec work: - Apps (or the OS libraries/kernel) lookup IPsec-equivalents of TLSA RRsets for the desired host/service name (not IP addresses!), then arrange for local IPsec policy to require the remote's ID/credentials for the address found in the DNS to match those found in the IPsec DANE. and/or - Use IPsec connection latching and channel binding to IPsec channels at the app layer. Note that the first effectively refers to connection latching. The latter is only relevant when there's an app-layer authentication mechanism with various properties, making the first approach the only general one. Nico -- From nobody Sat Apr 5 20:39: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 7990B1A01B3 for ; Sat, 5 Apr 2014 20:39:46 -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 uP3nG-P-RLJ8 for ; Sat, 5 Apr 2014 20:39:41 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 79AC21A02AC for ; Sat, 5 Apr 2014 20:39:36 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D686F2AA9EF; Sun, 6 Apr 2014 03:39:29 +0000 (UTC) Date: Sun, 6 Apr 2014 03:39:29 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140406033929.GQ12559@mournblade.imrryr.org> References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140405212023.GF2727@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/lOrhD00YnnHg94XXRgruSfXdP5g Subject: Re: [saag] new terminology ID posted 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, 06 Apr 2014 03:39:46 -0000 On Sat, Apr 05, 2014 at 04:20:25PM -0500, Nico Williams wrote: > > Thus it may not result in as much encryption as a mechanism which does not > > impose that prerequisite. Folks will have to decide if we want to create a > > different term for DANE-enabled TLS (and IPsec) sessions, or broaden the > > definition of opportunistic security to encompass them. I'm happy to > > generate text to accommodate whatever folks decide. > > Er, are you asking for a consensus call on this point? I'm definitely > for DANE-enabled TLS. Who wouldn't be? Can we hear some arguments > against? I'm curious about this. > > Or, if we don't hear any such arguments, then I think we must have > consensus on this point. > > Until then, what's the harm in including "DANE-enabled TLS" in your I-D? > How might we get feedback on that if you don't? Thanks. Specifically, I'd like to see opportunistic use of DANE TLS (as secure as DNSSEC when TLSA records are found) included under the "opportunistic security" umbrella. There will of course also be uses of DANE which are not "opportunistic", but they won't have the scalability of "opportunistic DANE TLS". Anyone else in support of having the I-D definition of "opportunistic security" be broad enough to include the opportunistic DANE TLS use-case? -- Viktor. From nobody Sun Apr 6 04: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 AA6641A03C2 for ; Sun, 6 Apr 2014 04:09:41 -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 0rQmX4zZn1I8 for ; Sun, 6 Apr 2014 04:09:37 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 39F821A037D for ; Sun, 6 Apr 2014 04:09:37 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id 63so2049279qgz.8 for ; Sun, 06 Apr 2014 04:09:31 -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=GabnB75LNJwnV72sqg+esPoOVzrHbYVmvjGmAdWwTPE=; b=ep8ICDiGcvybBfLVDlyCifL8TDBf5DO+6cCR7LlZe0IJy3Ewmk8hrkI8g9+pe77+l9 TIB0Rpbt1MX6AWYdN73ei4OnXhBM0zSmaWnU+znMyF1o4hJDmrbxud5DJSbMeH7YwEzx TU9l8n5rYybyc37deZHMpYII3eAwXTDa2qqax7SNqjt8bOdktvPl8sviP3KtzwtOaSey /tTb4rWxkSiKvqzQHsHrLeQvBH9XYk06S4K2JA8/+b9LUOZT+mMk0sXo/UGEKoiULC1V hYMqRwHTKV3cb1CaBEzazaTs5B7EUqM64bzAAKBH9+PFmovAiZ07i1w/OiWnSYG/iJbC E6cA== MIME-Version: 1.0 X-Received: by 10.140.109.132 with SMTP id l4mr7479177qgf.72.1396782571877; Sun, 06 Apr 2014 04:09:31 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.157.137 with HTTP; Sun, 6 Apr 2014 04:09:31 -0700 (PDT) In-Reply-To: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> Date: Sun, 6 Apr 2014 12:09:31 +0100 X-Google-Sender-Auth: aHnjjA0AUBfIY2emN49yvc_lqGc Message-ID: From: Ben Laurie To: Russ Housley Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/eSwjIFAykIzy7_iOrewFED0IahE Cc: IETF SAAG Subject: Re: [saag] draft-iab-crypto-alg-agility-00 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, 06 Apr 2014 11:09:41 -0000 On 3 April 2014 18:51, Russ Housley wrote: > > I gave a presentation at the SAAG session in London about this document. Stephen said that the discussion would continue on this list. I'm posting this message to get that discussion going. Thinking about this in the context of Certificate Transparency, it seems there are a couple of problems with the I-D. "IETF protocols that make use of cryptographic algorithms MUST carry one or more algorithm identifier." CT (at least currently) does not carry the algorithm identifier in band, it is metadata that is known about each log. Allowing logs to choose algorithms on-the-fly probably results in reduced security. I guess this is because the threat model is unusual: the bad guy is running the log. Normally one assumes that the bad guy is not one of the endpoints. A corollary of this is that " If a protocol does not carry an algorithm identifier, then the protocol version number or some other major change is needed to transition from one algorithm to another. The inclusion of an algorithm identifier is a minimal step toward cryptographic algorithm agility." would appear to be incorrect. Finally, I'm not really sure what s3.3 is getting at. It makes some statements about some protocols without drawing any conclusions that I can discern. From nobody Sun Apr 6 09:52: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 148081A01E3 for ; Sun, 6 Apr 2014 09:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 kQw7XgwTwydX for ; Sun, 6 Apr 2014 09:52:48 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DC4801A0162 for ; Sun, 6 Apr 2014 09:52:48 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s36GqfBq078846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 6 Apr 2014 09:52:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <20140406033929.GQ12559@mournblade.imrryr.org> Date: Sun, 6 Apr 2014 09:52:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <60BA03D4-5C92-4583-884D-38BCCBEBA7A6@vpnc.org> References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> To: saag@ietf.org X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/eYHsUAFXi83uZTZO0Isg8ah2urE Subject: Re: [saag] new terminology ID posted 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, 06 Apr 2014 16:52:53 -0000 On Apr 5, 2014, at 8:39 PM, Viktor Dukhovni = wrote: > On Sat, Apr 05, 2014 at 04:20:25PM -0500, Nico Williams wrote: >=20 >>> Thus it may not result in as much encryption as a mechanism which = does not >>> impose that prerequisite. Folks will have to decide if we want to = create a >>> different term for DANE-enabled TLS (and IPsec) sessions, or broaden = the >>> definition of opportunistic security to encompass them. I'm happy to >>> generate text to accommodate whatever folks decide. >>=20 >> Er, are you asking for a consensus call on this point? I'm = definitely >> for DANE-enabled TLS. Who wouldn't be? Can we hear some arguments >> against? I'm curious about this. >>=20 >> Or, if we don't hear any such arguments, then I think we must have >> consensus on this point. >>=20 >> Until then, what's the harm in including "DANE-enabled TLS" in your = I-D? >> How might we get feedback on that if you don't? >=20 > Thanks. Specifically, I'd like to see opportunistic use of DANE > TLS (as secure as DNSSEC when TLSA records are found) included > under the "opportunistic security" umbrella. There will of course > also be uses of DANE which are not "opportunistic", but they won't > have the scalability of "opportunistic DANE TLS". >=20 > Anyone else in support of having the I-D definition of "opportunistic > security" be broad enough to include the opportunistic DANE TLS > use-case? Yes, definitely. Given the increasing interest in DANE, it would be = silly to have this document not handle it as a possibility. --Paul Hoffman= From nobody Sun Apr 6 12:08: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 70B211A0259 for ; Sun, 6 Apr 2014 12:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-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 LfqDRks0er7w for ; Sun, 6 Apr 2014 12:08:37 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 20D6C1A0230 for ; Sun, 6 Apr 2014 12:08:36 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9DB8E4778D; Sun, 6 Apr 2014 19:08:30 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 912934778C; Sun, 6 Apr 2014 19:08:30 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 88020FE074; Sun, 6 Apr 2014 19:08:30 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Sun, 6 Apr 2014 15:08:29 -0400 From: "Salz, Rich" To: Ben Laurie , Russ Housley Date: Sun, 6 Apr 2014 15:08:27 -0400 Thread-Topic: [saag] draft-iab-crypto-alg-agility-00 Thread-Index: Ac9RiLYLP1Ox/wScSkG37lT+C08YxQAQtHoQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> In-Reply-To: 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 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/57U49nbI-iclOXowF4ZSYXrE42k Cc: IETF SAAG Subject: Re: [saag] draft-iab-crypto-alg-agility-00 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, 06 Apr 2014 19:08:42 -0000 Not to count angels on a pin, but is CT a protocol or a set of data formats= ?=20 -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Sun Apr 6 12:20:05 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712221A025E for ; Sun, 6 Apr 2014 12:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-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 wklJ-GyH7G7q for ; Sun, 6 Apr 2014 12:19:58 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 655B91A026A for ; Sun, 6 Apr 2014 12:19:56 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.147.33]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s36JJbqs000225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Apr 2014 12:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1396811989; bh=hE9KQsBdfq35rZC3AsQd++NNO28CNHIEcqrJZqyNBhI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2ufp5M6fL4BWQq8qxFQrpsTdTShPSt2KjKiiZPqZNYTp0hYfS2Y1AXVt3Bb/iSdTK WfuACtxhTQhVOVZDKdVjxAWVMMn2Q8bAdoYFQvV60jWKETDGWTYyfhF/egaJJQWE8T QBCpJeuE2RFnSyRSd1+Cz/B/C+NgMi9p1oJZ34Bk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1396811989; i=@elandsys.com; bh=hE9KQsBdfq35rZC3AsQd++NNO28CNHIEcqrJZqyNBhI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NXmmGBl+KgN6jnKxv/cv0jy0ELNFrBXAP17piPgO1lXJ9giPMU/mnOJ8ALP31F/cD 489CL1dtpA+l9U3alTLEXIjng50Md5oSShf6evet1FeWU/gsdTvr2WfuH0zItJOZkk a0Rx2keJVn67dVW7hX2a0XwhimC+m5s4v1mFD3gQ= Message-Id: <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 06 Apr 2014 12:18:21 -0700 To: "Salz, Rich" , Ben Laurie , Russ Housley From: S Moonesamy In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp .akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zFtaX64DUh_jtQtUpKuwaaZK9BM Cc: saag@ietf.org Subject: Re: [saag] draft-iab-crypto-alg-agility-00 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, 06 Apr 2014 19:20:02 -0000 Hi Rich, At 12:08 06-04-2014, Salz, Rich wrote: >Not to count angels on a pin, but is CT a protocol or a set of data formats? From RFC 6962: "Logs are network services that implement the protocol operations for submissions and queries that are defined in this document." Regards, S. Moonesamy From nobody Sun Apr 6 14:54: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 45AAA1A02AE for ; Sun, 6 Apr 2014 14:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, T_RP_MATCHES_RCVD=-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 yhX3emOEYF6y for ; Sun, 6 Apr 2014 14:54:43 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 36B561A029E for ; Sun, 6 Apr 2014 14:54:42 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 92202474F8; Sun, 6 Apr 2014 21:54:36 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 854B1474F7; Sun, 6 Apr 2014 21:54:36 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 82F1E8004F; Sun, 6 Apr 2014 21:54:36 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Sun, 6 Apr 2014 17:54:35 -0400 From: "Salz, Rich" To: S Moonesamy , Ben Laurie , Russ Housley Date: Sun, 6 Apr 2014 17:54:34 -0400 Thread-Topic: [saag] draft-iab-crypto-alg-agility-00 Thread-Index: Ac9RzS/x3aW19e1XQvSP1MFChNVf1AAFMk+A Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> In-Reply-To: <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/oQ06IAKHURhHx16d50nMtJgrpK0 Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-00 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, 06 Apr 2014 21:54:48 -0000 I know what the text says. But there are no protocol operations, really, i= t's just HTTP/JSON, right? Having said that, I think the agility document should say "protocols and da= ta formats." I was arguing (with Google folks, mainly) for crypto identifies in the CT d= ata structures before the WG was convened. And I still think that CT should= be brought in line with the letter and spirit of the agility document: id= entify the mechanisms used, in the data types. If interop is a concern, mak= e the current set be MUST and say SHOULD NOT implement anything else. CT should not be a special case exemption from the agility spec. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Sun Apr 6 16:15: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 89B951A0503 for ; Sun, 6 Apr 2014 16:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, T_RP_MATCHES_RCVD=-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 jCfXaCkz3Dz4 for ; Sun, 6 Apr 2014 16:15:45 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE6A1A014F for ; Sun, 6 Apr 2014 16:15:44 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.147.33]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s36NFQBv009666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Apr 2014 16:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1396826138; bh=QgIuJ+7IxGStVcr0XSXaFBo1I6M687rsYhXmduPFiIc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vFnQ17q6kGhCKLAfaUrgclhXVSsLbcq/8agyC8VEY1jmFap+BwG2jAtOkT2Lh5ltE CenIfdwp+OakryvJQstoGmi3Q+KaKecZ1OHSC1gsjTvz5+nUTiESeDFI535145WKEU ABRxvetlmz7CEror2exV2GFSquoUVia8RZzWX0RE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1396826138; i=@elandsys.com; bh=QgIuJ+7IxGStVcr0XSXaFBo1I6M687rsYhXmduPFiIc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0BMI7Sg7Bp+EXDnJF2dp0BuavkZi5nKdyzY7LJMtQCZLcuvk0FgpIgKoeZbYGvj7K cWsPKDkNK2ox2FfddfZ/rQipKPjUx4oprYaOMhqIfqIkKdOPeXKHkaOBvnwWk7xKo5 FTiVItH0r949grm+NNtx6LbAqfx0z6Go24P+DecA= Message-Id: <6.2.5.6.2.20140406151732.0bc4ed08@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 06 Apr 2014 16:05:06 -0700 To: "Salz, Rich" From: S Moonesamy In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp .akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/v3qfXM_OmTI9K6ANnVjP67pnvWg Cc: saag@ietf.org Subject: Re: [saag] draft-iab-crypto-alg-agility-00 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, 06 Apr 2014 23:15:49 -0000 Hi Rich, At 14:54 06-04-2014, Salz, Rich wrote: >I know what the text says. But there are no protocol operations, >really, it's just HTTP/JSON, right? I read the RFC again. The better choice was "protocol operations" because of some requirements. There is a thread at http://www.ietf.org/mail-archive/web/ietf/current/msg71257.html about the term "protocol". >Having said that, I think the agility document should say "protocols >and data formats." > >I was arguing (with Google folks, mainly) for crypto identifies in >the CT data structures before the WG was convened. And I still think >that CT should be brought in line with the letter and spirit of the >agility document: identify the mechanisms used, in the data types. >If interop is a concern, make the current set be MUST and say SHOULD >NOT implement anything else. > >CT should not be a special case exemption from the agility spec. And the above is the part which I would look at in terms of data formats. It is better to solve the Certificate Transparency part in the TRANS working group. The agility document is in the IAB Stream. It's better to keep the two documents separate for now. Regards, S. Moonesamy From nobody Sun Apr 6 16:22: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 3C0C31A0503 for ; Sun, 6 Apr 2014 16:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 NoY_O5jIaYwT for ; Sun, 6 Apr 2014 16:22: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 AF3FB1A016F for ; Sun, 6 Apr 2014 16:22:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 62E0DBE24; Mon, 7 Apr 2014 00:22:37 +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 y+ZcpQtACsKC; Mon, 7 Apr 2014 00:22:36 +0100 (IST) Received: from [10.87.48.12] (unknown [86.44.74.117]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0C77ABE20; Mon, 7 Apr 2014 00:22:36 +0100 (IST) Message-ID: <5341E1BB.6030402@cs.tcd.ie> Date: Mon, 07 Apr 2014 00:22:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: S Moonesamy , "Salz, Rich" References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406151732.0bc4ed08@elandnews.com> In-Reply-To: <6.2.5.6.2.20140406151732.0bc4ed08@elandnews.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/4jp0MOFSetEQKlI8VckLOsDAYBs Cc: saag@ietf.org Subject: Re: [saag] draft-iab-crypto-alg-agility-00 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, 06 Apr 2014 23:22:52 -0000 Just to clarify... On 04/07/2014 12:05 AM, S Moonesamy wrote: > The agility document is in the IAB Stream. The author's goal was for this to end up as an IETF consensus document, hence using this list and not an IAB list. So to the extent there's an issue highlighted by CT, we should tackle that issue. Cheers, S. From nobody Sun Apr 6 18: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 F13FB1A0434 for ; Sun, 6 Apr 2014 18:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, GB_I_LETTER=-2, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-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 7DHaV75V_o3C for ; Sun, 6 Apr 2014 18:09:40 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9314E1A01DD for ; Sun, 6 Apr 2014 18:09:40 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.147.33]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s3719JSl000471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Apr 2014 18:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1396832973; bh=QymmQOLAGvFaoFPvg6+/bRkL4n2VKhS+AL9/xQs0IEE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LMC7YbTU9bB7qyMQcplIyV/ypyZ8NuQTEvYnzc9EuEHJqT8Caigy42Rfa3bV1QNbi /7FG1uCCwAn0mMhSqPQCNSTegpEDDDPJ1BTYzhHmZhxqscacvdvvfgt7PfhlOIGn73 wczAe8H2pGQLobvSEHy0nzjTLwRVSbZckQJE7VD0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1396832973; i=@elandsys.com; bh=QymmQOLAGvFaoFPvg6+/bRkL4n2VKhS+AL9/xQs0IEE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=B6nNsr9MKR8NUHt1uU3myvfOyZhHbfwMOTdJ/w2GsGghA7pGTU5XWnkXo38o2Bsjd luwNv2ySpdsb/+glSGYZcd+gWRJLxtRYJoCqOdDJEWfF3Hw9y+82HiL583hSuvHzvl kWolHr6qrKBAQS+xU9IHeh4qJ3xpakcuQh3klU1A= Message-Id: <6.2.5.6.2.20140406164511.0bf19e48@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 06 Apr 2014 18:05:35 -0700 To: "Salz, Rich" , S Moonesamy , Ben Laurie , Russ Housley From: S Moonesamy In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp .akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/nKA6VT7DRj9b7FbTH0YdXEy_EJ8 Cc: saag@ietf.org Subject: Re: [saag] draft-iab-crypto-alg-agility-00 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, 07 Apr 2014 01:09:45 -0000 Hi Rich, Replying again based on the comment from Stephen Farrell. At 14:54 06-04-2014, Salz, Rich wrote: >Having said that, I think the agility document should say "protocols >and data formats." > >I was arguing (with Google folks, mainly) for crypto identifies in >the CT data structures before the WG was convened. And I still think >that CT should be brought in line with the letter and spirit of the >agility document: identify the mechanisms used, in the data types. >If interop is a concern, make the current set be MUST and say SHOULD >NOT implement anything else. > >CT should not be a special case exemption from the agility spec. If I understood draft-iab-crypto-alg-agility-00 correctly, the point is to insulate the application layer protocol from the cryptography altogether. The data formats would not be part of the protocol. What is being done is securing the transport. The issue may be clearer if the interoperability parts of draft-ietf-trans-rfc6962-bis-00 were identified. Regards, S. Moonesamy From nobody Mon Apr 7 02:25: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 2DD461A06A3 for ; Mon, 7 Apr 2014 02:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.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, GB_I_LETTER=-2, 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 6_xE97fRx8a7 for ; Mon, 7 Apr 2014 02:25:43 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id A34DA1A06AD for ; Mon, 7 Apr 2014 02:25:42 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id q108so5831279qgd.24 for ; Mon, 07 Apr 2014 02:25:36 -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:content-transfer-encoding; bh=Yy/t9p2vnWdWBO6Eav/xxqBZeUpthVyfQs96KdEIx/0=; b=xr2WutN1fmUxRaoNuL1VIAtHFQJMHyse/hB/Kci+/1tCJdJt8vUuThuaiKRFeaDAdi AHFoz5XOG4jUi7f6gpAZv/oYtNcqpJ5uQPesSB/rNRIMLzozDY2yt/dtVAm5LIBYGqLX QxlKC+2P6+sTbTJM7HZ6cai6/vYz7xYfG64wCXBCNSp49s4CwdbNaD4F5czpF1QohvFa Q6iWW3Fiv1DOZxc1GIARrFhFrxv18Vw0Uu0smih78Su7NkEDMObbsyZ8LRqUN85hPKtd +n7HoVmClLUY+bsoJYgfSike9btvXI/GreQmO2ZC14IH4R1mmiY6oj2F1N67F5REbEGV 9VtA== MIME-Version: 1.0 X-Received: by 10.140.28.70 with SMTP id 64mr30532507qgy.36.1396862736929; Mon, 07 Apr 2014 02:25:36 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.157.137 with HTTP; Mon, 7 Apr 2014 02:25:36 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> Date: Mon, 7 Apr 2014 10:25:36 +0100 X-Google-Sender-Auth: 4IxK4iWe1_wI-2ywUPZZ5F8o7lc Message-ID: From: Ben Laurie To: "Salz, Rich" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/saag/bxOU09ZVTMok-zSmW8_8jkzDAHo Cc: S Moonesamy , "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-00 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, 07 Apr 2014 09:25:48 -0000 On 6 April 2014 22:54, Salz, Rich wrote: > I know what the text says. But there are no protocol operations, really,= it's just HTTP/JSON, right? > > Having said that, I think the agility document should say "protocols and = data formats." > > I was arguing (with Google folks, mainly) for crypto identifies in the CT= data structures before the WG was convened. And I still think that CT shou= ld be brought in line with the letter and spirit of the agility document: = identify the mechanisms used, in the data types. If interop is a concern, m= ake the current set be MUST and say SHOULD NOT implement anything else. > > CT should not be a special case exemption from the agility spec. I think it should, and here's why: normally you want agility so endpoints can change their crypto in an orderly way, so as to phase out weak algorithms. In CT the endpoint is the enemy: you don't want it to be able to choose algorithms that suit it. From nobody Mon Apr 7 06:57: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 4ECC91A070C for ; Mon, 7 Apr 2014 06:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 pdMynMjv1VyI for ; Mon, 7 Apr 2014 06:57:48 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 86DB21A0441 for ; Mon, 7 Apr 2014 06:57:48 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id AB97C165585; Mon, 7 Apr 2014 13:57:42 +0000 (GMT) Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id A021A16557D; Mon, 7 Apr 2014 13:57:42 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id 86ADA2FD51; Mon, 7 Apr 2014 13:57:42 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Mon, 7 Apr 2014 09:57:41 -0400 From: "Salz, Rich" To: S Moonesamy Date: Mon, 7 Apr 2014 09:57:40 -0400 Thread-Topic: [saag] draft-iab-crypto-alg-agility-00 Thread-Index: Ac9R7iDSl5Ilt1DVScaozjfWYsphSAAew8Yw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED0D@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406151732.0bc4ed08@elandnews.com> In-Reply-To: <6.2.5.6.2.20140406151732.0bc4ed08@elandnews.com> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FppdMOSwqai7TjqVe0U6R-R8iA8 Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-00 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, 07 Apr 2014 13:57:53 -0000 > And the above is the part which I would look at in terms of data formats.= It is better to solve the Certificate Transparency part in the TRANS work= ing group. The agility document is in the IAB Stream. It's better to keep= the two documents separate for now. I never meant to imply that they should be merged into one document; sorry = if I gave that impression. What I meant was that CT should follow the policy of the crypto-agility doc= ument; I'll continue that discussion in the other thread (with Ben). /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Mon Apr 7 07:01: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 887111A0708; Mon, 7 Apr 2014 07:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 owwoVP8OWT5G; Mon, 7 Apr 2014 07:00:57 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC7D1A0713; Mon, 7 Apr 2014 07:00:56 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8C8FC480F8; Mon, 7 Apr 2014 14:00:50 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (unknown [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 77F08480E3; Mon, 7 Apr 2014 14:00:50 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 355789803E; Mon, 7 Apr 2014 14:00:50 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Mon, 7 Apr 2014 10:00:39 -0400 From: "Salz, Rich" To: "trans@ietf.org" Date: Mon, 7 Apr 2014 10:00:37 -0400 Thread-Topic: [saag] draft-iab-crypto-alg-agility-00 Thread-Index: Ac9SQ1iCuderyUe5RjO1bTZuczG+EAAJhb3w Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> In-Reply-To: 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 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/tFgvKb8r1aivS2-2TSUXV-11pa0 Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-00 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, 07 Apr 2014 14:01:01 -0000 (Adding trans@ietf.org) Me: > CT should not be a special case exemption from the agility spec. Ben: > I think it should, and here's why: normally you want agility so endpoints= can change their crypto in an orderly way, so as to phase out weak algorit= hms. In CT the endpoint is the enemy: you don't want it to be able to choos= e algorithms that suit it. What is the endpoint? The log server? I don't understand the point. And as I said, why can't you get the same effect with proper use of ALL CAP= S words in the RFC? /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Mon Apr 7 07:14: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 F367A1A0791 for ; Mon, 7 Apr 2014 07:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 piQtjr5S-gfi for ; Mon, 7 Apr 2014 07:14:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 019801A0452 for ; Mon, 7 Apr 2014 07:14:39 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:40880 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WXAJu-000GoT-0s; Mon, 07 Apr 2014 10:14:42 -0400 Message-ID: <5342B2C8.7060304@bbn.com> Date: Mon, 07 Apr 2014 10:14:32 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nico Williams References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> In-Reply-To: <20140405212023.GF2727@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/jx9cfp0JLhQXS-f6cqjv5StsURo Cc: saag@ietf.org Subject: Re: [saag] new terminology ID posted 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, 07 Apr 2014 14:14:45 -0000 Nico, > On Tue, Apr 01, 2014 at 02:46:43PM -0400, Stephen Kent wrote: >> Thus it may not result in as much encryption as a mechanism which does not >> impose that prerequisite. Folks will have to decide if we want to create a >> different term for DANE-enabled TLS (and IPsec) sessions, or broaden the >> definition of opportunistic security to encompass them. I'm happy to >> generate text to accommodate whatever folks decide. > Er, are you asking for a consensus call on this point? I'm definitely > for DANE-enabled TLS. Who wouldn't be? Can we hear some arguments > against? I'm curious about this. I was not asking for a consensus call, yet. And, even if I were, the issue is not whether DANE-enabled TLS is good or bad (I think it';s very good) but whether it will be included in a definition of OS. > Or, if we don't hear any such arguments, then I think we must have > consensus on this point. DANE-enabled TLS does not meet some of the posited requirements for OS, e.g., PFS, and encrypt first and authenticate later. Gee, that sounds a lot like "shoot first and ask questions later" now that I think about it :-). > Until then, what's the harm in including "DANE-enabled TLS" in your I-D? > How might we get feedback on that if you don't? Include it as what? I have included notes on what I viewed as "legacy" IETF security protocols. DANE-enabled TLS is rather new to be viewed as one of those. I don't want to discuss all of the proposals that are now on progress, lest we never complete this doc. In that sense DANE-enabled TLS tends to fall in the middle. If folks feel it's important to mention, then I will do so, but not as an example of OS. > As to IPsec, I really think there are two "correct" approaches to making > end-to-end IPsec work: > > - Apps (or the OS libraries/kernel) lookup IPsec-equivalents of TLSA > RRsets for the desired host/service name (not IP addresses!), then > arrange for local IPsec policy to require the remote's ID/credentials > for the address found in the DNS to match those found in the IPsec > DANE. > > and/or > > - Use IPsec connection latching and channel binding to IPsec channels > at the app layer. > > Note that the first effectively refers to connection latching. The > latter is only relevant when there's an app-layer authentication > mechanism with various properties, making the first approach the only > general one. I think this level of detail is beyond what needs to be discussed in this doc but, as above, let's see what other folks feel. Steve From nobody Mon Apr 7 07:17: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 5EAF71A072C for ; Mon, 7 Apr 2014 07:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 3a-3VRU8uUUa for ; Mon, 7 Apr 2014 07:17:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7504B1A0445 for ; Mon, 7 Apr 2014 07:17:48 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:39088 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WXAMx-000Gpr-3H for saag@ietf.org; Mon, 07 Apr 2014 10:17:51 -0400 Message-ID: <5342B386.3080301@bbn.com> Date: Mon, 07 Apr 2014 10:17:42 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <60BA03D4-5C92-4583-884D-38BCCBEBA7A6@vpnc.org> In-Reply-To: <60BA03D4-5C92-4583-884D-38BCCBEBA7A6@vpnc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/VtHJd4uq7HUAUkK7TYhAhq8aR_o Subject: Re: [saag] new terminology ID posted 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, 07 Apr 2014 14:17:53 -0000 Paul, > ... > Yes, definitely. Given the increasing interest in DANE, it would be silly to have this document not handle it as a possibility. > > --Paul Hoffman As I noted in my reply a few minutes ago, one of the precepts for OS as per the STRINT workshop was PFS. It doesn't seem that DANE-enabled TLS meets that criteria, but maybe I'm mistaken. So, either we change the criteria for OS, or we view DANE-enabled TLS and a good thing, but not as an example of OS. Steve From nobody Mon Apr 7 07:21: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 A1D831A0784 for ; Mon, 7 Apr 2014 07:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 FS38FuKnzgf6 for ; Mon, 7 Apr 2014 07:21:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5DC1A072C for ; Mon, 7 Apr 2014 07:21:21 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:33490 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WXAQE-000A0p-5r; Mon, 07 Apr 2014 10:21:14 -0400 Message-ID: <5342B454.1050607@bbn.com> Date: Mon, 07 Apr 2014 10:21:08 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> In-Reply-To: <20140406033929.GQ12559@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/kxYgfO0Z7omsM6O6uhjmQtoJRPc Cc: Jari Arkko Subject: Re: [saag] new terminology ID posted 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, 07 Apr 2014 14:21:25 -0000 Viktor, > ... > Thanks. Specifically, I'd like to see opportunistic use of DANE > TLS (as secure as DNSSEC when TLSA records are found) included > under the "opportunistic security" umbrella. There will of course > also be uses of DANE which are not "opportunistic", but they won't > have the scalability of "opportunistic DANE TLS". > > Anyone else in support of having the I-D definition of "opportunistic > security" be broad enough to include the opportunistic DANE TLS > use-case? > As I mentioned in my reply to Paul, PFS was highlighted as a critical part of OS 9ro whetever we call it) in the STRINT workshop. So, unless folks decide to change that, it doesn't seem that DANE-enabled TLS fits. That's not a criticism of DANE-enabled TL, just a side effect of the criteria. I suggest Stephen, Jari, and Steve Bellovin chime in, since they were all supporters of PFS as part of the criteria. Steve From nobody Mon Apr 7 07:37: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 833DE1A072C; Mon, 7 Apr 2014 07:37:43 -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 yWGnl2rcbt9q; Mon, 7 Apr 2014 07:37:39 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 750911A044C; Mon, 7 Apr 2014 07:37:16 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id i8so6426026qcq.37 for ; Mon, 07 Apr 2014 07:37:10 -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=DuEApVu0ykD3cfqzV6qn6JTomxq14bPw+VEOChzc06Y=; b=bAdVdu+4fpHGkMfyxH/wk3325AewW/Vu+N+OHWGuSL+7fDjQxyI3NKkJIJSKUoJUcS CwqnxCmMYIZ44n7Tpb84aIlAeVrQoJpkHMj3fUWEkYvTESUlM6xU8JqGN+D/mhhaVAeL 74+xWl3WtBMKrL8VVFsHID6C3S5sVShV/MWuuqnVzp9CQOwoMQl511NCLknjYG7LhWXp GwdQXxrAVKlC0rEii/OQER1u0c8o8L8vjK4X4ohtpUhlrZjsGB1zfUiP2tVbrPApbhwQ 65zOehXw1vLnuJolB8FjYHUkcpmyXQSc48aJ+RWMTQf/s/gQfhT4BSfkckFatOdeHHTV 2q4w== MIME-Version: 1.0 X-Received: by 10.224.147.77 with SMTP id k13mr16010750qav.64.1396881430593; Mon, 07 Apr 2014 07:37:10 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.157.137 with HTTP; Mon, 7 Apr 2014 07:37:10 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> Date: Mon, 7 Apr 2014 15:37:10 +0100 X-Google-Sender-Auth: rqKQwVGdGvQgg68cu3AaF4IbQ0s Message-ID: From: Ben Laurie To: "Salz, Rich" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/sXo-4hYdS4fMJCypSsocBUrYfk4 Cc: "trans@ietf.org" , "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-00 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, 07 Apr 2014 14:37:43 -0000 On 7 April 2014 15:00, Salz, Rich wrote: > (Adding trans@ietf.org) > > Me: >> CT should not be a special case exemption from the agility spec. > > Ben: >> I think it should, and here's why: normally you want agility so endpoints can change their crypto in an orderly way, so as to phase out weak algorithms. In CT the endpoint is the enemy: you don't want it to be able to choose algorithms that suit it. > > What is the endpoint? The log server? I don't understand the point. Yes, the log server. > And as I said, why can't you get the same effect with proper use of ALL CAPS words in the RFC? What effect? You mean define an algorithm that the log server MUST use? From nobody Mon Apr 7 08:08: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 964C51A07B6 for ; Mon, 7 Apr 2014 08:08: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 yEhXerZxqgRN for ; Mon, 7 Apr 2014 08:08:42 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC921A045E for ; Mon, 7 Apr 2014 08:08:41 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E1F202AA954; Mon, 7 Apr 2014 15:08:34 +0000 (UTC) Date: Mon, 7 Apr 2014 15:08:34 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140407150834.GW12559@mournblade.imrryr.org> References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <5342B454.1050607@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5342B454.1050607@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/wt_qs4F2rqt1u9X2RgCLJRhMpdU Subject: Re: [saag] new terminology ID posted 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, 07 Apr 2014 15:08:48 -0000 On Mon, Apr 07, 2014 at 10:21:08AM -0400, Stephen Kent wrote: > >Anyone else in support of having the I-D definition of "opportunistic > >security" be broad enough to include the opportunistic DANE TLS > >use-case? > > As I mentioned in my reply to Paul, PFS was highlighted as a critical part > of OS (or whatever we call it) in the STRINT workshop. So, unless folks > decide to change that, it doesn't seem that DANE-enabled TLS fits. That's > not a criticism of DANE-enabled TL, just a side effect of the criteria. I posit that an explicit *requirement* to negotiate PFS for a security mechanism to be called "opportunistic security" (or WWCI) is nonsense. Rather, "opportunistic security" (and other countermeasures to pervasive monitoring) should strive for and prefer PFS, but requiring PFS is absurd. Recall that "opportunistic security" is roughly speaking "as strong as possible", and when nothing better is in fact possible, includes cleartext. Is cleartext stronger than a non-PFS TLS connection? This is best illustrated by an interesting observation from my employer's mail logs just last week: * Email sent via mimecast.com was observed to trigger TLS handshake errors in the mail log. I was asked to look at these to determine whether something is wrong on our side, and whether mail was being delayed. * The error message in the logs was a TLS alert(46) from the SMTP client, which per http://tools.ietf.org/html/rfc5246#appendix-A.3 is "certificate_unknown". One might say: "fair enough", after all, our SMTP server certificate was (and still is) self-signed. * However, STARTTLS in email is opportunistic, and like most MTAs, when TLS is not available, the mimecast.com MTA within a few milliseconds reconnected in cleartext and delivered the mail! So what should one make of the server certificate check and refusal to proceed with unauthenticated TLS? My answer is: "cluelessness". For the mimecast.com SMTP client checking certificates has as its only effect the downgrading of a large fraction of SMTP connections (self-signed certificates are naturally quite common with SMTP) to cleartext. No MITM protection is achieved, but pervasive monitoring is made easier. > I suggest Stephen, Jari, and Steve Bellovin chime in, since they were all > supporters of PFS as part of the criteria. I very much doubt that Steve Bellovin et. al. would seriously suggest that "opportunistic security" require fallback to cleartext when PFS is not available. You do the best you can and recommend to all concerned to *implement support* for PFS. But surely no requirement ala mimecast.com to throw in the towel and fall back to cleartext when the TLS connection is not sufficiently righteous. In light of the above, there is nothing in DANE TLS that specifically contra-indicates PFS. Indeed, for example, with Postfix PFS ciphersuites will be used at highest preference whenever the server supports these, whether the authentication mechanism is DANE or PKIX and none at all (legacy opportunistic TLS). It is surely clear that "opportunistic security" CANNOT REQUIRE that PFS be the outcome, just as it CANNOT REQUIRE that even encryption be the outcome. This is surely a desired/recommended capability, not a required outcome. PFS is as much a goal for "opportunistic DANE TLS" as it is for other forms of "opportunistic security". The definitions of "opportunistic security" in the draft should be broad enough to accommodate "opportunistic DANE TLS". -- Viktor. From nobody Mon Apr 7 08:26: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 F17051A07B6 for ; Mon, 7 Apr 2014 08:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 cZRLICiK4ZUc for ; Mon, 7 Apr 2014 08:26:39 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0EA1A07C4 for ; Mon, 7 Apr 2014 08:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=487; q=dns/txt; s=iport; t=1396884381; x=1398093981; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=CtpA5b6+mOAIbE0wetLdmPT2fl472fzG2KcRvCP4rDI=; b=kqBgLhgr1BGHh7ZXmIvcJLh41FgM7J1Gx8kcuZvOGR02BHizGKyH/BfR Lp12y/eLRl7HtfjhGLOOofTTOdicX6Lw31rbOvpptbYtVvxYHi7cC83P0 EG7ndoiEs8v9MgWG8bscwlsoudzphsEoWlx5pIzgTICruGAxv4FTMja/j g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYKAGrCQlOtJssV/2dsb2JhbABZgwY7g2G5W4czAgKBJRZ0giUBAQEEAQEBIA8BOxsLGAICBSECAg8CFjAGAQwGAgEBh3UNqW2iARMEgSmNT4JvgUkBA4lUjweSP4M1OA X-IronPort-AV: E=Sophos;i="4.97,810,1389744000"; d="scan'208";a="9782147" Received: from aer-core-4.cisco.com ([173.38.203.21]) by aer-iport-4.cisco.com with ESMTP; 07 Apr 2014 15:26:20 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.196.140]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s37FQIFc025404; Mon, 7 Apr 2014 15:26:18 GMT Message-ID: <5342C399.40808@cisco.com> Date: Mon, 07 Apr 2014 19:26:17 +0400 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stephen Kent , saag References: <533AE246.9080806@bbn.com> In-Reply-To: <533AE246.9080806@bbn.com> 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/t3cRBNLu016OLhRJSfYbyr2qThg Subject: Re: [saag] new terminology ID posted 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, 07 Apr 2014 15:26:44 -0000 Dear Steve, Thank you for taking this on. Really good job. I agree with Stephen, and with everyone who said, “Go for it!” Eliot On 4/1/14, 7:59 PM, Stephen Kent wrote: > > revised as per SAAG discussion and directions from Stephen Farrell: > > https://datatracker.ietf.org/doc/draft-kent-opportunistic-security/ > > Steve > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From nobody Mon Apr 7 10:01: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 B93771A07EF for ; Mon, 7 Apr 2014 10:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-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 G0kM_FrXbQGs for ; Mon, 7 Apr 2014 10:01:26 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C980F1A07CC for ; Mon, 7 Apr 2014 10:01:24 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.147.234]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s37H14Rt015290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Apr 2014 10:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1396890077; bh=obTH2Xk20xUdK8ldOBH+OuBUhij2jQjdZNykGpNIs+0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rHaqWaPBxWIcYVV0UZCq5zZC7kIukyNGn0WQ5X5h0fhu3vV2BdTjRyKBECtHfTSBI G394UNyYCjQFtl9ttOY6O/cJJtFc+Vr3/+qTcNNA63/fwEStIgKv4THoN+Ei+UXVbQ H7ExhooxNSp9fWmUX3T7qMDxVlioeEGe0zTEy3zU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1396890077; i=@elandsys.com; bh=obTH2Xk20xUdK8ldOBH+OuBUhij2jQjdZNykGpNIs+0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=onEi4dgoFCYFZrAO01R+pV/9urz9lUNXwMieUp8ro8gBJgJpf6jg/+F5SSxUnkpYx 0+G9p+9n57gfYDAROrtkrkbc2JstxJBBcGJgxyBfTh2cYCgRF4jkLckGt2g8AzF04B BP/wI4jWBm1V0mTr/evvcGMWau+zYzhDJGClGjPg= Message-Id: <6.2.5.6.2.20140407070156.0d4d8900@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 07 Apr 2014 07:30:04 -0700 To: "Salz, Rich" From: S Moonesamy In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED0D@USMBX1.msg.corp .akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406151732.0bc4ed08@elandnews.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED0D@USMBX1.msg.corp.akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ehfiLyBvBLL7tQCAN9dX567yiOU Cc: saag@ietf.org Subject: Re: [saag] draft-iab-crypto-alg-agility-00 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, 07 Apr 2014 17:01:34 -0000 Hi Rich, At 06:57 07-04-2014, Salz, Rich wrote: >I never meant to imply that they should be merged into one document; >sorry if I gave that impression. I did not read it as that. :-) >What I meant was that CT should follow the policy of the >crypto-agility document; I'll continue that discussion in the other >thread (with Ben). That is what I understood. In my opinion it is a good idea to identify the end-points [1]. Regards, S. Moonesamy 1. msg-id: 2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com From nobody Mon Apr 7 10:37: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 C8F741A07C1 for ; Mon, 7 Apr 2014 10:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 R5TymSHHGgx2 for ; Mon, 7 Apr 2014 10:37:34 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEF91A07AE for ; Mon, 7 Apr 2014 10:37:31 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s37HbKRd025239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Apr 2014 10:37:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <5342B386.3080301@bbn.com> Date: Mon, 7 Apr 2014 10:37:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <60BA03D4-5C92-4583-884D-38BCCBEBA7A6@vpnc.org> <5342B386.3080301@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/t0ioVZBy5TPTqK_aA8xivhDlxw0 Cc: saag@ietf.org Subject: Re: [saag] new terminology ID posted 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, 07 Apr 2014 17:37:40 -0000 On Apr 7, 2014, at 7:17 AM, Stephen Kent wrote: > As I noted in my reply a few minutes ago, one of the precepts for OS = as per > the STRINT workshop was PFS.=20 I wasn't at the STRINT workshop, but I did talk to participants at the = IETF afterward. None of them said that PFS was a requirement, some said = it was a goal. Stephen Farrel's slides in SAAG don't reflect the "PFS is a precept" = idea. In fact, the opposite seems to be the case; his one point on OE = was "Requiring a tight coupling of authentication and ability to encrypt = not a good plan". In addition, I'm not sure I see the why getting a server's cert via DANE = inherently limits PFS. Not all certificates are for RSA encryption keys, = right? So, please do really consider making this document more open to the = technologies that many people believe will help achieve OE. --Paul Hoffman= From nobody Mon Apr 7 10:50: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 D38CE1A0811 for ; Mon, 7 Apr 2014 10:50:35 -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] 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 ABsdhquWuVfk for ; Mon, 7 Apr 2014 10:50:31 -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 7A50D1A0810 for ; Mon, 7 Apr 2014 10:50:28 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id F05C82005D10E for ; Mon, 7 Apr 2014 10:50:22 -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=/a+Mzkip3qZjb8ZvIPrs 4pCxC/w=; b=YLN64XVsnS6DAddz/MjEPz9QhXB8BwZmxzJPIDSK0vQSOjihRU7I aH7MHa7+PR4HKi7QgYgcn9KhqEyAQRIISQa6nqqM5m5DRzQiUGKD8ctZrEk/JFLE c0D8AcsVbDeiNrUE/fr9pylgEXe2TXizEp9ORFTphPJN32a/8Wv1bhE= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id A478A2005D10D for ; Mon, 7 Apr 2014 10:50:22 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id r20so5564322wiv.15 for ; Mon, 07 Apr 2014 10:50:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.10.66 with SMTP id g2mr26787375wib.5.1396893021302; Mon, 07 Apr 2014 10:50:21 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Mon, 7 Apr 2014 10:50:21 -0700 (PDT) In-Reply-To: References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <60BA03D4-5C92-4583-884D-38BCCBEBA7A6@vpnc.org> <5342B386.3080301@bbn.com> Date: Mon, 7 Apr 2014 12:50:21 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/A_YUeXmf3YbjOnCa9go1bKx-07U Cc: "saag@ietf.org" Subject: Re: [saag] new terminology ID posted 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, 07 Apr 2014 17:50:36 -0000 On Mon, Apr 7, 2014 at 12:37 PM, Paul Hoffman wrote: > On Apr 7, 2014, at 7:17 AM, Stephen Kent wrote: >> As I noted in my reply a few minutes ago, one of the precepts for OS as per >> the STRINT workshop was PFS. > > I wasn't at the STRINT workshop, but I did talk to participants at the IETF afterward. None of them said that PFS was a requirement, some said it was a goal. > > Stephen Farrel's slides in SAAG don't reflect the "PFS is a precept" idea. In fact, the opposite seems to be the case; his one point on OE was "Requiring a tight coupling of authentication and ability to encrypt not a good plan". > > In addition, I'm not sure I see the why getting a server's cert via DANE inherently limits PFS. Not all certificates are for RSA encryption keys, right? > > So, please do really consider making this document more open to the technologies that many people believe will help achieve OE. +1 (sorry for not trimming more of the quotes; they are relevant to my agreement, which is to all of the above) Does SAAG have area working group items, like the Apps Area does? This should be such a work item. I'd add that maybe we ought to have competing I-Ds on this matter. Nico -- From nobody Mon Apr 7 10:52: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 71D501A07AE for ; Mon, 7 Apr 2014 10:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 in7wQ96SzBoe for ; Mon, 7 Apr 2014 10:52:35 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E371F1A0237 for ; Mon, 7 Apr 2014 10:52:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 15EA6BE5C; Mon, 7 Apr 2014 18:52:28 +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 OyA9FtoY1jOL; Mon, 7 Apr 2014 18:52:27 +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 E3018BE5B; Mon, 7 Apr 2014 18:52:27 +0100 (IST) Message-ID: <5342E5DC.4030102@cs.tcd.ie> Date: Mon, 07 Apr 2014 18:52:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Paul Hoffman , Stephen Kent References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <60BA03D4-5C92-4583-884D-38BCCBEBA7A6@vpnc.org> <5342B386.3080301@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/rdmflAlvM4bz2WSYlZd6RLeAWeA Cc: saag@ietf.org Subject: Re: [saag] new terminology ID posted 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, 07 Apr 2014 17:52:41 -0000 On 04/07/2014 06:37 PM, Paul Hoffman wrote: > On Apr 7, 2014, at 7:17 AM, Stephen Kent wrote: > >> As I noted in my reply a few minutes ago, one of the precepts for >> OS as per the STRINT workshop was PFS. > > I wasn't at the STRINT workshop, but I did talk to participants at > the IETF afterward. None of them said that PFS was a requirement, > some said it was a goal. > > Stephen Farrel's slides in SAAG don't reflect the "PFS is a precept" > idea. In fact, the opposite seems to be the case; his one point on OE > was "Requiring a tight coupling of authentication and ability to > encrypt not a good plan". > > In addition, I'm not sure I see the why getting a server's cert via > DANE inherently limits PFS. Not all certificates are for RSA > encryption keys, right? > > So, please do really consider making this document more open to the > technologies that many people believe will help achieve OE. Since I was (mis:-)named... I think PFS is a fine thing for OE/OS, and would like to see it as at least the common case that we strongly encourage. I guess we'll all easily agree on that. I'm not sure whether or not we ought go as far as to say that use of RSA key transport means that a scheme does not conform to our OS/OE terminology. I could personally go either way on this, or put another way, I'd be fine myself with if we have a rough consensus either way on the topic, and yes, there are pros and cons. For me, the biggest I think are that without PFS there's no possibility to detect an attack that has succeeded. OTOH, declaring PFS as required means that a bunch of useful things might take longer to get deployed. So colour me uncertain on this one. S. From nobody Mon Apr 7 10:54: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 326D61A01AE for ; Mon, 7 Apr 2014 10:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Rm2XKri4DAVI for ; Mon, 7 Apr 2014 10:54:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 667381A0752 for ; Mon, 7 Apr 2014 10:54:43 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:42437 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WXDkj-000F4W-9Y for saag@ietf.org; Mon, 07 Apr 2014 13:54:37 -0400 Message-ID: <5342E65C.5070309@bbn.com> Date: Mon, 07 Apr 2014 13:54:36 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.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/9sHbAW5LxcCzVpM9xCglrJY6WbM Subject: Re: [saag] draft-iab-crypto-alg-agility-00 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, 07 Apr 2014 17:54:48 -0000 Ben, Sorry to jump on late on this, but as a co-author of an RFC that deals with alg agility for the RPKI, I thought I might be able to contribute. It's generally useful to have a MUST implement alg (or set, if there are multiple algs needed) for any set of protocols (data formats, etc.) to help ensure interoperability. Selecting the MUST implement is sometimes hard, but it's worth the effort. Then one needs to have a way for all clients, CA, and log servers (in the CT context) to express which alg9s) are being used at any time, so that everyone else knows what choices have been made, when choices are allowed, and to guide folks through the transition process. I suggest folks read RFC 6919 as an example of how that can be done, although I'm not suggesting that CT needs to adopt as thorough a model as did the RPKI. Steve From nobody Mon Apr 7 11:04: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 E5FD91A0161 for ; Mon, 7 Apr 2014 11:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 RoNWuyRC86Li for ; Mon, 7 Apr 2014 11:04:00 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7181A1A0816 for ; Mon, 7 Apr 2014 11:04:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 900AFBE5C; Mon, 7 Apr 2014 19:03:54 +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 4xJL9jPO+HEL; Mon, 7 Apr 2014 19:03:54 +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 685A6BE5B; Mon, 7 Apr 2014 19:03:54 +0100 (IST) Message-ID: <5342E88A.5080302@cs.tcd.ie> Date: Mon, 07 Apr 2014 19:03:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nico Williams , Paul Hoffman References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <60BA03D4-5C92-4583-884D-38BCCBEBA7A6@vpnc.org> <5342B386.3080301@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/L-_bxx_DyD2Cxnwp9GDhc-FuD8M Cc: "saag@ietf.org" Subject: [saag] area WGs (was: Re: new terminology ID posted) 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, 07 Apr 2014 18:04:06 -0000 On 04/07/2014 06:50 PM, Nico Williams wrote: > Does SAAG have area working group items, like the Apps Area does? > This should be such a work item. Not nearly as organised. Sean and I had generally not liked that idea. Kathleen and I haven't really discussed it but will. The downside Sean and I saw was that area WGs can tend to throw up ideas that really ought have had more review and/or charter discussion as a result of which it can be too late to fix stuff when drafts get to IETF LC or IESG eval. Appsawg are now for example putting in place what they call "mini-charters" partly (I think) to handle that. One could argue that the overall perpass stuff means we're now doing some of these kinds of drafts I guess and that we ought organise that a bit more, but give Kathleen and I a while to ponder that please. For example, consider beating us up about it at IETF-90 maybe:-) > I'd add that maybe we ought to have competing I-Ds on this matter. Personally, I very much dislike that idea. We discussed this topic and what to do and agreed that opportunistic something was where to go. If you think that Steve K's draft is not good enough to work from then please reply to my mail asking about exactly that from last week. (But *please* reply as requested to that so we don't re-run the entire terminology discussion from scratch.) S. From nobody Mon Apr 7 11:13: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 4AB6F1A0839 for ; Mon, 7 Apr 2014 11:13:52 -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 j5qDij17eoKS for ; Mon, 7 Apr 2014 11:13:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 09AE21A0834 for ; Mon, 7 Apr 2014 11:13:47 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 129282AA95A; Mon, 7 Apr 2014 18:13:41 +0000 (UTC) Date: Mon, 7 Apr 2014 18:13:41 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140407181340.GA12559@mournblade.imrryr.org> References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <60BA03D4-5C92-4583-884D-38BCCBEBA7A6@vpnc.org> <5342B386.3080301@bbn.com> <5342E5DC.4030102@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5342E5DC.4030102@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/tGE9w47f3bnguP5YRS35w19nB3M Subject: Re: [saag] new terminology ID posted 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, 07 Apr 2014 18:13:52 -0000 On Mon, Apr 07, 2014 at 06:52:28PM +0100, Stephen Farrell wrote: > I think PFS is a fine thing for OE/OS, and would like to see > it as at least the common case that we strongly encourage. I > guess we'll all easily agree on that. Yes, strongly encourage. > I'm not sure whether or not we ought go as far as to say that > use of RSA key transport means that a scheme does not conform > to our OS/OE terminology. More to the point, when encountering a server that *only* supports RSA key transport, should an OS/OE client avoid using TLS, and send in cleartext? Clearly not! > I could personally go either way on this, or put another way, > I'd be fine myself with if we have a rough consensus either way > on the topic, and yes, there are pros and cons. There really are no "pros and cons" here. Opportunistic security clients MUST be willing to accept RSA key transport when that's all that is available, cleartext is never a better option. However, servers that want to claim support for OS/OE (the marketing term), SHOULD support PFS. The PFS red-herring is quite orthogonal to the opportunistic component of client policy. That is, PFS is motherhood and apple pie goodness across the board from opportunistic unauthenticated encryption to pre-shared peer fingerprint authentication. > So colour me uncertain on this one. I think you're letting yourself off the hook too easily. Or in any case I am not letting you of the hook that easily. Elementary logic leads one quickly to conclude that PFS *cannot* be a requirement. Otherwise we end up in mimecast.com silly-land where, for example, cleartext is used in place of TLS because certificate verification fails or TLS did not use PFS, ... -- Viktor. From nobody Mon Apr 7 11:34: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 DC2B71A0162 for ; Mon, 7 Apr 2014 11:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 kngB4b8O3No1 for ; Mon, 7 Apr 2014 11:34:03 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC141A0840 for ; Mon, 7 Apr 2014 11:33:20 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:50124 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WXEMD-000JVX-UX; Mon, 07 Apr 2014 14:33:22 -0400 Message-ID: <5342EF69.7000306@bbn.com> Date: Mon, 07 Apr 2014 14:33:13 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Paul Hoffman References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <60BA03D4-5C92-4583-884D-38BCCBEBA7A6@vpnc.org> <5342B386.3080301@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/eIRFrNQx4-tHf_RyvgPiFKwL1qQ Cc: saag@ietf.org Subject: Re: [saag] new terminology ID posted 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, 07 Apr 2014 18:34:08 -0000 Paul, > On Apr 7, 2014, at 7:17 AM, Stephen Kent wrote: > >> As I noted in my reply a few minutes ago, one of the precepts for OS as per >> the STRINT workshop was PFS. > I wasn't at the STRINT workshop, but I did talk to participants at the IETF afterward. None of them said that PFS was a requirement, some said it was a goal. Well, the summary slides for the breakout session were not posted, so I can't point to them. I'm still waiting for comments from the other folks in the session to see what their recollection is. > Stephen Farrel's slides in SAAG don't reflect the "PFS is a precept" idea. In fact, the opposite seems to be the case; his one point on OE was "Requiring a tight coupling of authentication and ability to encrypt not a good plan". The quote above supports (though does not mandate) PFS use; it is not, as you suggest, indicating the opposite! PFS via a blind DH exchange is pure encryption w/o authentication. it epitomizes the comment you attributed to Stephen. Can you clarify what you meant above? > In addition, I'm not sure I see the why getting a server's cert via DANE inherently limits PFS. Not all certificates are for RSA encryption keys, right? Right, but if a cert for a server contains a DH key, unless that key is changed after each time if is retrieved, the result will not be what I consider PFS. If the private key corresponding to the public key in the TLSA record were compromised, every passively wiretapped session with the server is vulnerable. The central security idea behind PFS is to limit the damage done by disclosure of a private key. That's why two-way, ephemeral DH is so attractive. From an ease of deployment perspective, ephemeral DH is attractive because there is no a priori posting of security data needed to enable it. > So, please do really consider making this document more open to the technologies that many people believe will help achieve OE. I'm not working to achieve OE, I'm working on OS :-). Still, if the Sec ADs and others (not just the folks who have put a lot of effort into DANE) indicate that want a less prospective (yet still useful) definition for OS, I'll modify the doc accordingly. Steve From nobody Mon Apr 7 11:34: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 6127A1A083F for ; Mon, 7 Apr 2014 11:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 KxatcmaOgrfs for ; Mon, 7 Apr 2014 11:34:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6510D1A0267 for ; Mon, 7 Apr 2014 11:33:29 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:50125 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WXEMN-000JVu-VV for saag@ietf.org; Mon, 07 Apr 2014 14:33:32 -0400 Message-ID: <5342EF73.5070903@bbn.com> Date: Mon, 07 Apr 2014 14:33:23 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <5342B454.1050607@bbn.com> <20140407150834.GW12559@mournblade.imrryr.org> In-Reply-To: <20140407150834.GW12559@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/OZ3io4tabCl1CygXbOAfG4GY9P0 Subject: Re: [saag] new terminology ID posted 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, 07 Apr 2014 18:34:11 -0000 Viktor, I'm guessing that you did not attend the STRINT workshop, right? My comments on requiring PFS are taken from that context. That's why I asked Stephen, as workshop chair, and Jari and Steve Bellovin, all folks who participated in the breakout session that generated the list that I included in my doc, to comment. (Our new Sec AD, Kathleen, also attended that session, so she shoudl feel free to comment as well.) DANE-enabled TLS is a great technology. But, it requires that a target of a session create a TLSa record. That, by itself, is a potential impediment to widespread use. In contrast, a protocol that calls for the initiator and responder to perform an ephemeral D-H exchange does not impose such a burden. If a TLSA record exists, one could send it after the encrypted session was in place. I'm not sure how to interpret your response. It could be that you worry that it DANE-enabled TLS isn't covered under the OS term, that will hinder its adoption. Maybe. Maybe you feel that it's better to push for DANE-enabled TLS now, and now wait for a PFS solution, i.e., the protocol in the hand is better that a PFS in the bush, so to speak. I don't disagree with that observation. But, does that mean we need to make the definition as set of statement of the form: "you can do A, or B, and if you do A, then you may or may not do C, but if you do B, then ..." That seems confusing, at least to me. Your said: "In light of the above, there is nothing in DANE TLS that specifically contra-indicates PFS. Indeed, for example, with Postfix PFS ciphersuites will be used at highest preference whenever the server supports these, whether the authentication mechanism is DANE or PKIX and none at all (legacy opportunistic TLS)." Sorry that I missed that in the RFC. Can you remind me of the specific text that indicates PFS support? I know that TLS can support PFS via the DH or ECDH cipher suite, but the TLS RFCs indicate that this is an intentionally server-anonymous mode of communication. Your also said: "It is surely clear that "opportunistic security" CANNOT REQUIRE that PFS be the outcome, just as it CANNOT REQUIRE that even encryption be the outcome." I don't think my message said that. It said that a protocol characterized as OS makes use of PFS. If one tries to execute an OS protocol, and a peer does not support it, and if we stick with the criteria developed in the workshop, then one would fallback to plaintext. You seem to be saying that it would be preferable to not require PFS if that means falling back to plaintext, when one could use DANE-enabled TLS instead. I don't disagree with that order of preference; the question is whether this should be called OS. Steve From nobody Mon Apr 7 12:08: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 4637B1A07D2; Mon, 7 Apr 2014 12:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 ZadV4h_jCEb4; Mon, 7 Apr 2014 12:08:14 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7519C1A0862; Mon, 7 Apr 2014 12:08:14 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 23969475C5; Mon, 7 Apr 2014 19:08:07 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5F1F9475C7; Mon, 7 Apr 2014 19:08:06 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 00A122035; Mon, 7 Apr 2014 19:08:05 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Mon, 7 Apr 2014 15:08:05 -0400 From: "Salz, Rich" To: Ben Laurie Date: Mon, 7 Apr 2014 15:08:04 -0400 Thread-Topic: [saag] draft-iab-crypto-alg-agility-00 Thread-Index: Ac9Sbt3APIV6Sn3hQzGAAemoYAyUqgAAA0Pg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> In-Reply-To: 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 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/L0M6RiaU82PFS8rhZA1hbitYdSo Cc: "trans@ietf.org" , "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-00 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, 07 Apr 2014 19:08:19 -0000 So the concern is log servers that are going to reserve the right to "go ro= gue" by using weak crypto that could be subverted? Or is there a different= concern? =20 I believe this can be addressed by leaving the data formats future-proof, b= ut mandating the crypto in the RFC. For example, put a hash identifier (OID= , TLS id, whatever) in the hash entry, but the RFC says "MUST use SHA-256."= To make it even stronger, you could set up an IANA registry. Being pragma= tic, nobody's going to implement anything other than what Chrome supports, = at least at first. And by making log data self-identifying, you can (quietl= y) perform experiments on new crypto types. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Mon Apr 7 12:10: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 9DAA61A047A for ; Mon, 7 Apr 2014 12:10:07 -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] 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 58MA_spFwKx3 for ; Mon, 7 Apr 2014 12:10:02 -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 C0F611A0162 for ; Mon, 7 Apr 2014 12:10:02 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 3FDF740122424 for ; Mon, 7 Apr 2014 12:09: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=DqAr1vUmhVRO6cvQ/G+C ImSl/pU=; b=ihW38hG3qthxOipcpKgyDvPbuQm9EXr0H56ezARd61qiAHtrPVZN KOVx4BORJGWYGxiHe6f7kcGafK6VsK6BsFD0XwqBhI6Gat0CFAnyy6dJ+Gp9g8GH +Dq5u915cyRm9vdCEE6YS6dUwVWGJ2DeXIrc4q+t9s4SmzawW0Xr7+c= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (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 E4E684012241C for ; Mon, 7 Apr 2014 12:09:56 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id r20so5694110wiv.15 for ; Mon, 07 Apr 2014 12:09:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.240.226 with SMTP id wd2mr17056wjc.95.1396897795598; Mon, 07 Apr 2014 12:09:55 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Mon, 7 Apr 2014 12:09:55 -0700 (PDT) In-Reply-To: <5342B2C8.7060304@bbn.com> References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <5342B2C8.7060304@bbn.com> Date: Mon, 7 Apr 2014 14:09:55 -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/U5R1zp6-CEvF6B7MMsaRe4wkPRI Cc: "saag@ietf.org" Subject: Re: [saag] new terminology ID posted 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, 07 Apr 2014 19:10:07 -0000 On Mon, Apr 7, 2014 at 9:14 AM, Stephen Kent wrote: >> On Tue, Apr 01, 2014 at 02:46:43PM -0400, Stephen Kent wrote: >> Er, are you asking for a consensus call on this point? I'm definitely >> for DANE-enabled TLS. Who wouldn't be? Can we hear some arguments >> against? I'm curious about this. > > I was not asking for a consensus call, yet. And, even if I were, the > issue is not whether DANE-enabled TLS is good or bad (I think it';s > very good) but whether it will be included in a definition of OS. OK, so let's define OS. My definition: You get the strongest security in the Internet threat model that can be obtained, and you get as strong a floor on security in the Internet threat model as that which you can securely discover, else the floor may be as low as protection only against passive attacks. Note the importance of getting the floor to be as high as possible when we can discover that it can be. That's the point of using DNSSEC to securely learn the server's/service's security capabilities: so that you can then accept nothing less. If the floor is always the lowest that's higher than just sending plaintext then I'm afraid we won't be helping much at all. We'll be selling snake oil, and the public will eventually notice and call us out for it. The floor has to be variable, and fallback-safe. >> Or, if we don't hear any such arguments, then I think we must have >> consensus on this point. > > DANE-enabled TLS does not meet some of the posited requirements for > OS, e.g., PFS, and encrypt first and authenticate later. Gee, that sounds > a lot like "shoot first and ask questions later" now that I think about it > :-). That's just ridiculous: - DANE doesn't say you don't get PFS; - nor is RSA key transport worse than not exchanging keys (and using them) at all. (I know, I'm repeating what Viktor's already said.) I'm not sure what is the antecedent of "that" in you last sentence above, so I can't tell if I agree with it or not :) >> Until then, what's the harm in including "DANE-enabled TLS" in your I-D? >> How might we get feedback on that if you don't? > > Include it as what? I have included notes on what I viewed as "legacy" > IETF security protocols. DANE-enabled TLS is rather new to be viewed > as one of those. I don't want to discuss all of the proposals that are > now on progress, lest we never complete this doc. In that sense DANE-enabled > TLS tends to fall in the middle. If folks feel it's important to mention, > then I will do so, but not as an example of OS. So let's not discuss DANE. Let's instead discuss semantics. I offered a definition of OS above. >> As to IPsec, I really think there are two "correct" approaches to making >> end-to-end IPsec work: > > I think this level of detail is beyond what needs to be discussed in this > doc > but, as above, let's see what other folks feel. I don't care so much whether that detail/those proposals end up in the I-D so much as that IF you're going to propose an OS mode for IPsec then it'd better be meaningful. End-to-end IPsec currently is not deployable on a large scale on account of the issues that I've described too many times to bother repeating myself right now. Either you don't agree and we then debate the issues, or you agree and wordsmith your I-D accordingly with whatever level of detail is appropriate to that I-D's purpose. Nico -- From nobody Mon Apr 7 12:44:05 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F161A07F4 for ; Mon, 7 Apr 2014 12:44:02 -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] 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 cv7KjpbFhwed for ; Mon, 7 Apr 2014 12:43:58 -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 662431A0237 for ; Mon, 7 Apr 2014 12:43:57 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id DA4452F4060 for ; Mon, 7 Apr 2014 12:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=bffZ8DKmAayFQiZ8wQstCCB4jFM=; b=ZTGQj3ejjsJ anwY6pS+sntfXPftzf3M6j02f270WJB0kB/evDz0j3wstsxJygg9hJy8vXh7roPS +ayTvvIa+GCvfBlWcajXNX3U4nBnYxvDJMfSFUD38mlszdEMCS1HUe9wEngJVzKW cW3JfBqR+n/cbeO5vDTrHtQOqxwek6Hk= 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-a63.g.dreamhost.com (Postfix) with ESMTPSA id 8E7812F4059 for ; Mon, 7 Apr 2014 12:43:51 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id r20so5745516wiv.15 for ; Mon, 07 Apr 2014 12:43:50 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.181.5.6 with SMTP id ci6mr60304wid.39.1396899830367; Mon, 07 Apr 2014 12:43:50 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Mon, 7 Apr 2014 12:43:50 -0700 (PDT) Date: Mon, 7 Apr 2014 14:43:50 -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/dcmkUOB_lmSWRuqEawIvUx6W-40 Cc: "saag@ietf.org" Subject: [saag] The floor on OS (Re: new terminology ID posted) 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, 07 Apr 2014 19:44:03 -0000 On Mon, Apr 7, 2014 at 2:09 PM, Nico Williams wrote: > On Mon, Apr 7, 2014 at 9:14 AM, Stephen Kent wrote: >> I was not asking for a consensus call, yet. And, even if I were, the >> issue is not whether DANE-enabled TLS is good or bad (I think it';s >> very good) but whether it will be included in a definition of OS. > > OK, so let's define OS. My definition: > > You get the strongest security in the Internet threat model that > can be obtained, and you get as strong a floor on security in the > Internet threat model as that which you can securely discover, else > the floor may be as low as protection only against passive attacks. It's hard to overstate the importance of having the floor strength be variable _and_ that when the floor is strong you have no fallback on weaker levels of security. So, new thread. Floors: - no security whatsoever (everything sent in cleartext); - unauthenticated key exchange (note that RSA key transport can do this), which obtains protection against passive attackers; It goes without saying that keys are exchanged so they can be used for authenticated encryption and possibly for channel binding (or other MITM detection schemes), so I won't repeat this below. - unauthenticated key exchange w/ TOFU/LoF/TACK/pinning, which obtains protection against passive attackers and forces MITMs to remain in the middle for longer than they might be prepared, willing, or able to; There is the risk that forcing a capable MITM to always be in the middle causes further disclosures to them. But having fallen victim to an MITM once this seems like a small additional risk. - authenticated key exchange. Authentication can be done in any number of ways, from DNSSEC-based to PKI-based, to web of trust-based. If one does TOFU/LoF then on subsequent exchanges we have a form of authenticated (pseudonymous) key exchange. "Opportunistic" necessarily means that the floor that one gets might be very low strength. But it must not mean that a fallback on low-strength is always required. We'd be doing a great disservice to the public if required fallback to the lowest floor in all circumstances! We must allow for discovery of floor strength for specific peers. TOFU/LoF, TACK, pinning -- these are technologies for setting the floor in the future to be no lower than today (modulo expiration, ...). PKI (DNSSEC or x.509/PKIX) is a technology for discovering the lowest floor in the present. DNSSEC/DANE in particular is a technology for out-of-band high floor discovery, which therefore strongly indicates that fallback on lower strength floors should be NOT permitted. DNSSEC is a PKI of sorts however, with all the problems that that implies. This is a reason to expect some pushback on DNSSEC-based solutions. If one does not trust the DNSSEC PKI then either one must not use DANE or one must require the use of other technologies (e.g., TOFU/LoF) in addition to DANE to add a measure of security. Allowing the floor to rise as possible -and to stay strong- is critical. Aside #1: Channel binding is no help if there's not a separate, higher-layer authentication mechanism to take advantage of it. Aside #2: Any technology that requires persistent local storage (e.g., TOFU/LoF, TACK/pinning) may fail to be usable on highly constrained devices, but that's very much a side issue. Mobile devices today have plenty of persistent storage. Embedded devices mostly don't really need to speak to potentially any peer on the Internet, so PSK or similar are generally good enough for them. Nico -- From nobody Mon Apr 7 12:51: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 205ED1A0808 for ; Mon, 7 Apr 2014 12:51: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 GVlUbubWzdTx for ; Mon, 7 Apr 2014 12:51:34 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1831A047A for ; Mon, 7 Apr 2014 12:51:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B37C22AA95A; Mon, 7 Apr 2014 19:51:28 +0000 (UTC) Date: Mon, 7 Apr 2014 19:51:28 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140407195128.GD12559@mournblade.imrryr.org> References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <60BA03D4-5C92-4583-884D-38BCCBEBA7A6@vpnc.org> <5342B386.3080301@bbn.com> <5342EF69.7000306@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5342EF69.7000306@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/v3tbvPXqBLTcLPe4D2qA1qVn9CQ Subject: Re: [saag] new terminology ID posted 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, 07 Apr 2014 19:51:44 -0000 On Mon, Apr 07, 2014 at 02:33:13PM -0400, Stephen Kent wrote: > Paul, > > >I wasn't at the STRINT workshop, but I did talk to participants > >at the IETF afterward. None of them said that PFS was a requirement, > >some said it was a goal. > > Well, the summary slides for the breakout session were not posted, so I > can't point to them. I'm still waiting for comments from the other folks > in the session to see what their recollection is. Their recollection does not trump first-order logic. PFS *cannot* be a *required outcome* for an opportunistic mode of operation. Otherwise, welcome to mimecast.com SMTP client silly-land. PFS can and should be a preferred mode of operation regardless of whether security is opportunistic or mandatory. In this regard nothing disqualifies DANE. > >In addition, I'm not sure I see the why getting a server's cert > >via DANE inherently limits PFS. Not all certificates are for RSA > >encryption keys, right? There are in practice negligibly few certificates that are limited to RSA key transport (presumably via the keyUsage extension). This is a non-issue. Secondly, in practice DANE TLSA (RFC 6698) does not publish the server certificate, the vast majority of TLSA records will be certificate or public key digests. The certificate will be provided in the server handshake (as with non-DANE TLS). > Right, but if a cert for a server contains a DH key, unless that key is > changed after each time if is retrieved, the result will not be what I > consider PFS. Even with long-term fixed DH keys on the server (which are as common with TLS as unicorns are on the prairie) the server is still free to perform an ephemeral DH key exchange. PFS is not ruled out by fixed DH keys. > If the private key corresponding to the public key in the TLSA record were > compromised, every passively wiretapped session with the server is > vulnerable. The central security idea behind PFS is to limit the damage > done by disclosure of a private key. That's why two-way, ephemeral DH is > so attractive. From an ease of deployment perspective, ephemeral DH is > attractive because there is no a priori posting of security data needed > to enable it. Though the public key will generally in fact not be *in* the TLSA record, I'll read the above as equally applicable to the case when the public key *digest* is in the TLSA record, which is I think equivalent for your purpose. Now if we're to take this objection to DANE as a mode of opportunistic TLS seriously, we should note that there is nothing DANE specific here. ANY server with a long-term key, whether it corresponds to a DANE TLSA record or not, if it employs a non-PFS key exchange mechanism, may facilitate decryption of past session via disclosure of long-term keys. Thus, we might conclude, that OS/OE clients MUST refuse to connect to existing servers with stable long-term keys, or refuse to negotiate non-PFS key exchange mechanisms, and thus, since we're making encryption invisible, transparent, ... use the superior cleartext mechanism which is free of the RSA key exchange failure mode. Clearly not! So all that could possibly be meant by the PFS goodness from STRINT (I read the abstracts of most of the papers, and read some in full) is that PFS should be promoted, and used as widely as possible. This in no way excludes DANE any more than it excludes any other opportunistically authenticated or unauthenticated protocol. > Still, if the Sec ADs and others (not just the folks who have put a lot of > effort into DANE) indicate that want a less prospective (yet still useful) > definition for OS, I'll modify the doc accordingly. This is rather a strange stance. There is NOTHING in DANE that makes disclosure of long-term keys any more risky than with other protocols. It seems you've the wrong end of the stick with respect to DANE. It is *precisely* the folks who understand DANE in detail, who are best positioned to provide guidance on whether DANE fits the opportunistic security model or not. -- Viktor. From nobody Mon Apr 7 13:21: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 7E7DB1A07BF for ; Mon, 7 Apr 2014 13:21:55 -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_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 dT2JKd0VzF-o for ; Mon, 7 Apr 2014 13:21:48 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 703B11A04B1 for ; Mon, 7 Apr 2014 13:21:45 -0700 (PDT) Received: from BL2PR03MB290.namprd03.prod.outlook.com (10.141.68.19) by BL2PR03MB290.namprd03.prod.outlook.com (10.141.68.19) with Microsoft SMTP Server (TLS) id 15.0.918.8; Mon, 7 Apr 2014 20:21:32 +0000 Received: from BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) by BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) with mapi id 15.00.0918.000; Mon, 7 Apr 2014 20:21:32 +0000 From: "Orit Levin (LCA)" To: Nico Williams , Stephen Kent Thread-Topic: [saag] The floor on OS (Re: new terminology ID posted) Thread-Index: AQHPUpm9PyyS72yF8U6P5ldK8nHOyJsGkxWw Date: Mon, 7 Apr 2014 20:21:31 +0000 Message-ID: <5b7711fa447a46588246f15884b41551@BL2PR03MB290.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.247.123.117] x-forefront-prvs: 0174BD4BDA x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(979002)(6009001)(428001)(51704005)(164054003)(24454002)(13464003)(377454003)(189002)(199002)(53806001)(81542001)(90146001)(81342001)(56816005)(86362001)(92566001)(66066001)(20776003)(76576001)(94946001)(97336001)(80022001)(93136001)(65816001)(54356001)(33646001)(95416001)(76796001)(54316002)(86612001)(31966008)(85852003)(97186001)(63696002)(83072002)(93516002)(99286001)(95666003)(81686001)(47976001)(76482001)(56776001)(2656002)(87936001)(51856001)(47736001)(15975445006)(74502001)(80976001)(79102001)(50986001)(99396002)(59766001)(77982001)(49866001)(85306002)(69226001)(4396001)(83322001)(47446002)(19580395003)(19580405001)(74366001)(74662001)(94316002)(76786001)(87266001)(81816001)(98676001)(46102001)(74876001)(74706001)(74316001)(24736002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB290; H:BL2PR03MB290.namprd03.prod.outlook.com; FPR:2A6CF1EC.A70AE709.BCFF7D7B.82F6EDE1.2055E; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) 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/fTrUN7WRKQCj91uKT2XvyTxYFfw Cc: "saag@ietf.org" Subject: Re: [saag] The floor on OS (Re: new terminology ID posted) 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, 07 Apr 2014 20:21:55 -0000 In UTA, we have spent numerous email cycles discussing how different (suppo= rting) techniques relate (or not) to the "opportunistic" concept. The level= of mutual understanding and agreement that we have achieved is still to be= seen in the next round of UTA drafts. So...I can see a lot of value in capturing the concepts/cases listed below = in a single protocol-independent document under the general security area. Thanks, Orit. > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Nico Williams > Sent: Monday, April 07, 2014 12:44 PM > To: Stephen Kent > Cc: saag@ietf.org > Subject: [saag] The floor on OS (Re: new terminology ID posted) >=20 > On Mon, Apr 7, 2014 at 2:09 PM, Nico Williams > wrote: > > On Mon, Apr 7, 2014 at 9:14 AM, Stephen Kent wrote: > >> I was not asking for a consensus call, yet. And, even if I were, the > >> issue is not whether DANE-enabled TLS is good or bad (I think it';s > >> very good) but whether it will be included in a definition of OS. > > > > OK, so let's define OS. My definition: > > > > You get the strongest security in the Internet threat model that > > can be obtained, and you get as strong a floor on security in the > > Internet threat model as that which you can securely discover, else > > the floor may be as low as protection only against passive attacks. >=20 > It's hard to overstate the importance of having the floor strength be > variable _and_ that when the floor is strong you have no fallback on > weaker levels of security. So, new thread. >=20 > Floors: >=20 > - no security whatsoever (everything sent in cleartext); >=20 > - unauthenticated key exchange (note that RSA key transport can do > this), which obtains protection against passive attackers; >=20 > It goes without saying that keys are exchanged so they can be used > for authenticated encryption and possibly for channel binding (or > other MITM detection schemes), so I won't repeat this below. >=20 > - unauthenticated key exchange w/ TOFU/LoF/TACK/pinning, which > obtains protection against passive attackers and forces MITMs to > remain in the middle for longer than they might be prepared, willing, > or able to; >=20 > There is the risk that forcing a capable MITM to always be in the > middle causes further disclosures to them. But having fallen victim > to an MITM once this seems like a small additional risk. >=20 > - authenticated key exchange. >=20 > Authentication can be done in any number of ways, from DNSSEC-based to > PKI-based, to web of trust-based. If one does TOFU/LoF then on > subsequent exchanges we have a form of authenticated (pseudonymous) > key exchange. >=20 > "Opportunistic" necessarily means that the floor that one gets might > be very low strength. But it must not mean that a fallback on > low-strength is always required. We'd be doing a great disservice to > the public if required fallback to the lowest floor in all > circumstances! >=20 > We must allow for discovery of floor strength for specific peers. >=20 > TOFU/LoF, TACK, pinning -- these are technologies for setting the > floor in the future to be no lower than today (modulo expiration, > ...). >=20 > PKI (DNSSEC or x.509/PKIX) is a technology for discovering the lowest > floor in the present. >=20 > DNSSEC/DANE in particular is a technology for out-of-band high floor > discovery, which therefore strongly indicates that fallback on lower > strength floors should be NOT permitted. >=20 > DNSSEC is a PKI of sorts however, with all the problems that that > implies. This is a reason to expect some pushback on DNSSEC-based > solutions. If one does not trust the DNSSEC PKI then either one must > not use DANE or one must require the use of other technologies (e.g., > TOFU/LoF) in addition to DANE to add a measure of security. >=20 > Allowing the floor to rise as possible -and to stay strong- is critical. >=20 > Aside #1: Channel binding is no help if there's not a separate, > higher-layer authentication mechanism to take advantage of it. >=20 > Aside #2: Any technology that requires persistent local storage (e.g., > TOFU/LoF, TACK/pinning) may fail to be usable on highly constrained > devices, but that's very much a side issue. Mobile devices today have > plenty of persistent storage. Embedded devices mostly don't really > need to speak to potentially any peer on the Internet, so PSK or > similar are generally good enough for them. >=20 > Nico > -- >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Mon Apr 7 13:37: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 BE9E21A07A1 for ; Mon, 7 Apr 2014 13:37:13 -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 SWwtr71idpj4 for ; Mon, 7 Apr 2014 13:37:05 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id EA6A81A04B1 for ; Mon, 7 Apr 2014 13:37:04 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 224092AA954; Mon, 7 Apr 2014 20:36:58 +0000 (UTC) Date: Mon, 7 Apr 2014 20:36:58 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140407203658.GE12559@mournblade.imrryr.org> References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <5342B454.1050607@bbn.com> <20140407150834.GW12559@mournblade.imrryr.org> <5342EF73.5070903@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5342EF73.5070903@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/V3OMDd_bnVQ_2aOdIfyaJEeiTeE Subject: Re: [saag] new terminology ID posted 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, 07 Apr 2014 20:37:14 -0000 On Mon, Apr 07, 2014 at 02:33:23PM -0400, Stephen Kent wrote: [ Reordered, because the below may the crux of the contention. ] > > "In light of the above, there is nothing in DANE TLS that specifically > > contra-indicates PFS. Indeed, for example, with Postfix PFS ciphersuites > > will be used at highest preference whenever the server supports these, > > whether the authentication mechanism is DANE or PKIX and none at all (legacy > > opportunistic TLS)." > > Sorry that I missed that in the RFC. Can you remind me of the specific text > that indicates PFS support? I know that TLS can support PFS via the DH or > ECDH cipher suite, but the TLS RFCs indicate that this is an intentionally > server-anonymous mode of communication. I think this nails the source of the confusion. TLS supports PFS *with* authentication. That's the distinction between the: # ADH-* and DHE-* ciphersuites. The former are anonymous, in the latter the PFS key exchange is signed with the server's long-term keys. # AECDH-* and ECDHE-* ciphersuites. The former are anonymous, in the latter the PFS key exchange is signed with the server's long-term keys. > DANE-enabled TLS is a great technology. But, it requires that a target of > a session create a TLSA record. That, by itself, is a potential impediment > to widespread use. Of course, I am not suggesting that "opportunistic DANE TLS" is the one only true "opportunistic security". I am merely suggesting that DANE TLS is (for now pending wider DNSSEC deployment) a small legitimate corner case that should not be *excluded* from the wide umbrella term of "opportunistic security". > In contrast, a protocol that calls for the initiator > and responder to perform an ephemeral D-H exchange does not impose such a > burden. If a TLSA record exists, one could send it after the encrypted > session was in place. This view of "opportunistic security" as a single protocol is clearly too narrow. For example, an HTTP client that opportunistically upgrades to HTTPS would be ill-advised to refuse to employ non-PFS cipher-suites and fall back to HTTP. Sure, we want to encourage servers and clients to support PFS and preferentially negotiate PFS key exchange mechanisms. This does not mean that technologies that are *capable* of non-PFS modes of operation on either the client or the server are automatically disqualified. > I'm not sure how to interpret your response. It could be that you worry > that if DANE-enabled TLS isn't covered under the OS term, that will hinder > its adoption. No, my concern is that you've proposed a needlessly narrow view of "opportunistic security" that hinders technical discussion of related approaches to getting "as strong as possible" security. > Maybe you feel that it's better to push for > DANE-enabled TLS now, and now wait for a PFS solution, i.e., the protocol > in the hand is better that a PFS in the bush, so to speak. * With respect to definitions of OS/OE I not pushing for DANE in preference to any other opportunistic approach. Perhaps that's the source of confusion. I am asking that your definitions not *exclude* opportunistic use of DANE, but definitely you SHOULD NOT prescribe DANE. * DANE neither demands nor precludes PFS, you don't need to wait for anything. Postfix uses DANE with PFS, PKIX with PFS, opportunistic unauthenticated TLS with PFS, ... * PFS is orthogonal to all other aspects of the various protocols, it just a set of key exchange mechanisms that happens to be advantageous in the face of demands for disclosure of long-term keys. > I don't disagree > with that observation. But, does that mean we need to make the definition > as set of statement of the form: "you can do A, or B, and if you do A, > then you may or may not do C, but if you do B, then ..." That seems > confusing, at least to me. To be honest, I no longer recall at this point which parts of the definitions in the most recent version of the I-D seemed to exclude DANE, and if I misread the defintions, and none do, great! However, if the definitions are in fact restrictive to the point of excluding opportunistic DANE from the umbrella defintion of opportunistic security, then that is my objection. I don't believe that you should be defining a single protocol. Rather this I-D should be defining a new approach to securing many protocols in which the security bar is not fixed at a high minimum that leaves most traffic completely unprotected. Opportunistic use of DANE is one mechanism to allow the bar to float between cleartext and DNSSEC authenticated that fits within the overall philosophy of "opportunistic security". > I don't think my message said that. It said that a protocol characterized as > OS makes use of PFS. If one tries to execute an OS protocol, and a peer does > not support it, and if we stick with the criteria developed in the workshop, > then one would fallback to plaintext. You seem to be saying that it would be > preferable to not require PFS if that means falling back to plaintext, Absolutely, and I think I would get majority support for this view. > when one could use DANE-enabled TLS instead. No, when one could use other key exchange mechanism, including RSA key exchange. Even with RSA key exchange one is free to ignore the server's certificate leaving the server unauthenticated. DANE is irrelevant here. > I don't disagree with that order of preference; the question is whether > this should be called OS. With "opportunistic DANE TLS" (for example), DANE authentication is mandated when TLSA records are published, but in their absence the policy degrades to "opportunistic TLS", which in the absence of TLS support (e.g. with SMTP no STARTTLS) degrades to cleartext. -- Viktor. From nobody Tue Apr 8 07:00: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 50F551A03A1 for ; Tue, 8 Apr 2014 07:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 MTEm8TrqYJxQ for ; Tue, 8 Apr 2014 07:00:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8F81A0159 for ; Tue, 8 Apr 2014 07:00:47 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:48992 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WXWa7-000P9e-6I for saag@ietf.org; Tue, 08 Apr 2014 10:00:55 -0400 Message-ID: <5344010E.6000306@bbn.com> Date: Tue, 08 Apr 2014 10:00:46 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <5342E65C.5070309@bbn.com> <5342E8E9.5070008@cs.tcd.ie> In-Reply-To: <5342E8E9.5070008@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/TlclyrDpwC9L2wAjkW5UTvxlir0 Subject: Re: [saag] draft-iab-crypto-alg-agility-00 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, 08 Apr 2014 14:00:49 -0000 Whoops. Stephen Farrell noted that I cited the wrong RFC. It's 6916, not 6919, that describes the alg agility design for the RPKI. Steve From nobody Tue Apr 8 07:06: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 E70341A03F9 for ; Tue, 8 Apr 2014 07:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 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, RP_MATCHES_RCVD=-0.272, 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 ZaGCquDtsOvM for ; Tue, 8 Apr 2014 07:06:30 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9991A03E2 for ; Tue, 8 Apr 2014 07:06:26 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id if17so775116vcb.22 for ; Tue, 08 Apr 2014 07:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vbrKEI6TglnDTEow907XTqtQI8q+Q5LSTa6S7k8+5Y4=; b=kiXoiRpU296wEm+NN2iUAIz96okMk3VtvQis0er2mj2INzlbFSLlBM1pPPFk0Xb/KN QRThQ0vVHbI+ixbw3usmWm5Vq85YuLuUdGB8vNs6yT8/yJcHOlk1phlf1YGPSokuWwhE DqkX7RixSjKk7rSJwgnnuGDymbqDvpVMekZ8VeWGsXGAAHhL2OPkV67VnKNlTWVeJuVo LLehtrJ1lYqyAkGK9zp08Km8euFOHn4isCweg8Cg62SEokB/lsScgYFzXfJUIa4G6NsR P0FWnhBdez5VjOWlyaH0jfTYBlPLlainLPRZpSIKEEnWBjl2EoKzL/F5z8hwcb7+bxvX 11Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vbrKEI6TglnDTEow907XTqtQI8q+Q5LSTa6S7k8+5Y4=; b=FvEjIQ91QFpPJJ4oYRulSxpCsim6+G2oZ4t0Q59tVzYn0GGP4XNJ2xOeke4HPsb07o /TJmfqPCKDneS6uvltfAtkvOkrO21E+YuenKXQqBxv4R9PDI5v/TGs8stEaq3MtEHOtg 2dYT+Wvqy8v5tczl4y8fPHae347H7jeJud/R/an6enBbMHoyJhm4xMaNL1WHnP774ke6 AjMAno5w+7irIiE+LBKfQnzie2XdKtjQJvpUeHLTbnKK7iqpt4gil1C42E7CJsaxqTD8 zX/lDccq28Geptpi4z8KgO2fMO2mLeZ/KyV+WDVVcbNKGEEcwjQgk9Q9Xihvr3AGZOMB RK9w== X-Gm-Message-State: ALoCoQlMEXAFJSquHb/okoHhgMFrS6tH4Cc8Ew7BzaUEKXVOdzCPhObp8era6mpbjGkzUGiepZE6cVp84tGtImXwFTPjwEIBIjOPBJ/Wat+qe4C95BwjxH/UG1sEbx/L0f09orrcnlYghgY/BsuWS+MqLD8yDeIO2nZ2oQiV4nDYKja9nPdetr+TGcWUvNB4LtJdHhdlKQ1h MIME-Version: 1.0 X-Received: by 10.52.128.231 with SMTP id nr7mr2851040vdb.17.1396965986202; Tue, 08 Apr 2014 07:06:26 -0700 (PDT) Received: by 10.52.119.179 with HTTP; Tue, 8 Apr 2014 07:06:26 -0700 (PDT) In-Reply-To: <5342E65C.5070309@bbn.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <5342E65C.5070309@bbn.com> Date: Tue, 8 Apr 2014 15:06:26 +0100 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/awDnMhSHggYbdAtOYer1lFPDbEE Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-00 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, 08 Apr 2014 14:06:34 -0000 On 7 April 2014 18:54, Stephen Kent wrote: > Ben, > > Sorry to jump on late on this, but as a co-author of an RFC that deals > with alg agility for the RPKI, I thought I might be able to contribute. > > It's generally useful to have a MUST implement alg (or set, if there are > multiple > algs needed) for any set of protocols (data formats, etc.) to help ensure > interoperability. Selecting the MUST implement is sometimes hard, but it's > worth > the effort. > > Then one needs to have a way for all clients, CA, and log servers (in the CT > context) > to express which alg9s) are being used at any time, so that everyone else > knows > what choices have been made, when choices are allowed, and to guide folks > through the > transition process. I am not really arguing with that, actually. But in the case of CT, this information needs to be in the metadata about the logs. The RFC does not currently specify how that metadata becomes available to clients (and I'm not sure it should, either). > I suggest folks read RFC 6919 as an example of how that can be done, > although > I'm not suggesting that CT needs to adopt as thorough a model as did the > RPKI. > > Steve > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- Certificate Transparency is hiring! Let me know if you're interested. From nobody Tue Apr 8 07:08: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 7C3181A03FB for ; Tue, 8 Apr 2014 07:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 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, RP_MATCHES_RCVD=-0.272, 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 pGwO79EW0XrS for ; Tue, 8 Apr 2014 07:08:20 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 59D551A03FC for ; Tue, 8 Apr 2014 07:08:12 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id la4so816243vcb.31 for ; Tue, 08 Apr 2014 07:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WOHk3q3zeh+/RuxLpGOaX/FppL+U8P5eXCPlclEEoGo=; b=Pj1OAJ6Maualo6g1NZJ7+dK+TAKgdPINu32DilWyFjJnEdGfVeJp7cSHP2l+/+Wrrl BHjP25Yhf4GEmjnoFOGdSDxGGYpKueKo4ABsznvkqPL2+DGvBekG8892pIGpwzXYOyhn 6b871w642AHhR3EwSs/0vfmhAZHeEx4fDxNi3I2ygHI8DAq7fNDsfOfQ5Ksq4sPcZCiZ J7wtKCcEca7KAvshyDb+svOtPWw3mQpds24tddpYwJmXgEKSiMczEyNFd+EqxzYSy/6K hHeMxpbPTiEU01Qu8nk6v7CEhma1JqN1yZbXo+4m+Q6OfRd+Q7mNw8en1lafVbR3MHgP /siA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WOHk3q3zeh+/RuxLpGOaX/FppL+U8P5eXCPlclEEoGo=; b=W6OxA0W6ozjAxWwo2bIAzSWmXUC9gnUixjjBeur7XTLjBI2sOkiOKUq1E4lDHHGzeo hPji+0vsFIynBg+xEurTxIwm+BQSB89ZDq/q0oriVu8+gGuwdgxVy1LhxHhHv6ZCoyF8 VR62YEW+bGhG71da6ru8uT2RRT65Chingl1Lmm61zgmj8yY5GzoyCDc3gfzTiq/8RctT XQPL1dZXege1ptmn70xn+AjEOlpCLFkSum6Vp9PrNsMcX/nevBCk6C7gx0h/WuWgCvI4 w7ByTvrtEOm8rF3YzSmmJVL6wvivkuSmdHDDDSHQMvPN6Kl827vvMeVxXvCyEUvVS7uZ qa1g== X-Gm-Message-State: ALoCoQmUJE3CQshyBFpSMN5UIEjCkIytKgTgzDNcEBgcVX5KZZf9UoygdadHRHBQTCsfdeacSe1GS8/nb1xeCx0TZ8CZRtNgYM9pYruA31b5KosHeoKPFece7c2c2+dZhTG5b234TCzgDyNPVVlfAYjrw0oL17Puuf+Sjs/aCt0FjrjiU1EfMqqTFDeiQMJjnOVm/MmnShUA MIME-Version: 1.0 X-Received: by 10.58.31.136 with SMTP id a8mr3601978vei.20.1396966091996; Tue, 08 Apr 2014 07:08:11 -0700 (PDT) Received: by 10.52.119.179 with HTTP; Tue, 8 Apr 2014 07:08:11 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> Date: Tue, 8 Apr 2014 15:08:11 +0100 Message-ID: From: Ben Laurie To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/saag/egckEXq01jX7j4pegNk9f2c01ts Cc: "trans@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [Trans] draft-iab-crypto-alg-agility-00 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, 08 Apr 2014 14:08:21 -0000 On 7 April 2014 20:08, Salz, Rich wrote: > So the concern is log servers that are going to reserve the right to "go = rogue" by using weak crypto that could be subverted? Or is there a differe= nt concern? Right, that's the concern. > I believe this can be addressed by leaving the data formats future-proof,= but mandating the crypto in the RFC. For example, put a hash identifier (O= ID, TLS id, whatever) in the hash entry, but the RFC says "MUST use SHA-256= ." To make it even stronger, you could set up an IANA registry. Being prag= matic, nobody's going to implement anything other than what Chrome supports= , at least at first. And by making log data self-identifying, you can (quie= tly) perform experiments on new crypto types. As I responded to Steve, I agree that there should be an identifier, but it belongs in the metadata about the logs. The RFC does not (and arguably should not) specify how logs get that metadata, nor what format it is in. > > /r$ > > -- > Principal Security Engineer > Akamai Technology > Cambridge, MA > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --=20 Certificate Transparency is hiring! Let me know if you're interested. From nobody Tue Apr 8 07:10: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 F001B1A03E4; Tue, 8 Apr 2014 07:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] 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 bIGn9CH16EE4; Tue, 8 Apr 2014 07:10:07 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1F72C1A03F6; Tue, 8 Apr 2014 07:10:03 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B460A284A8; Tue, 8 Apr 2014 14:10:02 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 9FC6528441; Tue, 8 Apr 2014 14:10:02 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 792768003C; Tue, 8 Apr 2014 14:10:02 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Tue, 8 Apr 2014 10:10:02 -0400 From: "Salz, Rich" To: Ben Laurie Date: Tue, 8 Apr 2014 10:10:01 -0400 Thread-Topic: [Trans] [saag] draft-iab-crypto-alg-agility-00 Thread-Index: Ac9TM/8HsmFpMT5DRZeb66rjILytWgAACODg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/jyk3Ck4F-iShFWmPAm-EWVyBW0w Cc: "trans@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [Trans] draft-iab-crypto-alg-agility-00 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, 08 Apr 2014 14:10:11 -0000 PiBBcyBJIHJlc3BvbmRlZCB0byBTdGV2ZSwgSSBhZ3JlZSB0aGF0IHRoZXJlIHNob3VsZCBiZSBh biBpZGVudGlmaWVyLCBidXQgaXQgYmVsb25ncyBpbiB0aGUgbWV0YWRhdGEgYWJvdXQgdGhlIGxv Z3MuDQoNCkkgZG8gbm90IHVuZGVyc3RhbmQgd2h5IG1ldGFkYXRhIGlzIG1vcmUgc2VjdXJlIHRo ZW4gdGhlIGRhdGEgaXRzZWxmLg0KDQpJIHN0cm9uZ2x5IGRpc2FncmVlIHRoYXQgQ1Qgc2hvdWxk IGJlIGEgc3BlY2lhbCBjYXNlIGZyb20gdGhlIGdlbmVyYWwgYWdpbGl0eSBkb2MuDQoNCgkvciQN Cg0KLS0gIA0KUHJpbmNpcGFsIFNlY3VyaXR5IEVuZ2luZWVyDQpBa2FtYWkgVGVjaG5vbG9neQ0K Q2FtYnJpZGdlLCBNQQ0K From nobody Tue Apr 8 07:15: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 397B71A0425 for ; Tue, 8 Apr 2014 07:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 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, RP_MATCHES_RCVD=-0.272, 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 y_cQcpu4CFRw for ; Tue, 8 Apr 2014 07:15:46 -0700 (PDT) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id A3EB51A041E for ; Tue, 8 Apr 2014 07:14:24 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id jw12so789210veb.23 for ; Tue, 08 Apr 2014 07:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VpNSm6Z6nzrBiWVXdU/FpiwgH4+VCRqNuL4L3ihoRoQ=; b=cCQSIoy7VyJLiPU9/TFhT+ODC3U3a+PVGHon6qAxwifX53L9faOApSN8p61CGsXUsc zQlWt3xSPszCphDh8ArfRhcphhrYeq4s6vhvjiAB8DxtW6SaWwU+r/VmxMfvVdDubn9e odd+p19kxIeQixhyUc+C338UXPRPz0H5FlEa7WnMgk3sh63PBERDcWbWhg7DaJN3d367 R+sezRkKiz0tThVe6MNBTJ6FUB2Mv9y9Ibref12sp6jerO+05pfzOB/5yDuXxpbqSkoU JcJ+hHUZycFa90bgHV+/8tWDV/uKbT7IZKqFKrDxJ2HE69bhuRjKFdi7lsmr/U89LnNl n7gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VpNSm6Z6nzrBiWVXdU/FpiwgH4+VCRqNuL4L3ihoRoQ=; b=khh64XEGJCZDayDSn2ihta8/GYCxN/1FyzI6pZYCOwpNqUt0aOKqPx4DhYwNWmeQ7r Txexx6sBnQuLSZKUFDH+TqjEySbIpoBiMNvMOGQmHoTNVdfwABsIamKsxl2StsI9h8Y1 FDwPq6rNfI5qv5wCz6pGTv3HB0kWRoNgaXQQqvNcuhNymh2QaNspmjynGzbPYPmOszxK w9QQvDdiYU/Q7+3ZLUrK8WYnP9+x8g6S2CH2em2JFIWzYyrjtN5MQUTxV7xKpEs37x68 IzZ1R/23/+bk2O6uZFLojUEEMouw475t0Wd4Z4j1ygyo7oWQujdAe9Uj1hDI2IlHLmrx wngw== X-Gm-Message-State: ALoCoQmcPhdglD6RwVKZ1rgYWmtDjUoyvtZe9Wcw/kGmn3kJQ9IHA/feYX0FHNcxq3pdPJOyZIV1+Njk3M8TCFQ7zXSPSjfyAxl1D3I/wAfv5enyP0Yo68UNZh4I/xszbmKDH+Lf8aeYi3f/EZeQU+NaMNqMRItMfz6PTuDvBRw7BZnL9rQDtbl/7tEhSSQQhTXXFy3or14K MIME-Version: 1.0 X-Received: by 10.58.49.10 with SMTP id q10mr3347372ven.5.1396966464417; Tue, 08 Apr 2014 07:14:24 -0700 (PDT) Received: by 10.52.119.179 with HTTP; Tue, 8 Apr 2014 07:14:24 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> Date: Tue, 8 Apr 2014 15:14:24 +0100 Message-ID: From: Ben Laurie To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/SPOnzZzW-ixFEEtUvnmilstMgHk Cc: "trans@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [Trans] draft-iab-crypto-alg-agility-00 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, 08 Apr 2014 14:15:47 -0000 On 8 April 2014 15:10, Salz, Rich wrote: >> As I responded to Steve, I agree that there should be an identifier, but it belongs in the metadata about the logs. > > I do not understand why metadata is more secure then the data itself. It is created by a different authority. > I strongly disagree that CT should be a special case from the general agility doc. I am not saying it is a special case, I am disputing where the agility should happen. :-) -- Certificate Transparency is hiring! Let me know if you're interested. From nobody Tue Apr 8 07:18: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 1A6C41A03FB; Tue, 8 Apr 2014 07:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 DXnHRw3h-XfJ; Tue, 8 Apr 2014 07:18:19 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id A9EB71A03E1; Tue, 8 Apr 2014 07:18:19 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 63C4F474CC; Tue, 8 Apr 2014 14:18:19 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 57381474CB; Tue, 8 Apr 2014 14:18:19 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 54AD780044; Tue, 8 Apr 2014 14:18:19 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Tue, 8 Apr 2014 10:18:19 -0400 From: "Salz, Rich" To: Ben Laurie Date: Tue, 8 Apr 2014 10:18:18 -0400 Thread-Topic: [Trans] [saag] draft-iab-crypto-alg-agility-00 Thread-Index: Ac9TNNoaN52++GhqSbC+6HoeEfP1NwAAHp2Q Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188BB@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_vCOfa8qfgZbAEugnS7C5hev-h4 Cc: "trans@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [Trans] draft-iab-crypto-alg-agility-00 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, 08 Apr 2014 14:18:21 -0000 PiA+IEkgZG8gbm90IHVuZGVyc3RhbmQgd2h5IG1ldGFkYXRhIGlzIG1vcmUgc2VjdXJlIHRoZW4g dGhlIGRhdGEgaXRzZWxmLg0KDQo+IEl0IGlzIGNyZWF0ZWQgYnkgYSBkaWZmZXJlbnQgYXV0aG9y aXR5Lg0KDQo/ICBJcyB0aGlzIGluIHRoZSBwYXJ0IG9mIHRoZSBSRkMgdGhhdCBpcyBzdGlsbCBU QkQ/DQoNCgkvciQNCg0KLS0gIA0KUHJpbmNpcGFsIFNlY3VyaXR5IEVuZ2luZWVyDQpBa2FtYWkg VGVjaG5vbG9neQ0KQ2FtYnJpZGdlLCBNQQ0KDQo= From nobody Tue Apr 8 07:21: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 402951A03FE for ; Tue, 8 Apr 2014 07:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 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, RP_MATCHES_RCVD=-0.272, 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 gxY-KovrPoCv for ; Tue, 8 Apr 2014 07:21:37 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id ACBF61A0415 for ; Tue, 8 Apr 2014 07:21:28 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id ib6so843013vcb.27 for ; Tue, 08 Apr 2014 07:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rUWchDoKIMDjx7REd1lDAGgAk6m7IYhNTvpHswB7DEc=; b=OF+PZBPNwzRl2kKWU8h7J0o/NvO5iPeSXW0dOr/8recnz7aRJ+5s9TiCKUe0uHq+Id VhpM/2TZTk3Q48AJc2cFURN1HHHQDzOZUhEkMe/2EGDze8pO+ySkkJassrzx4YmbMeN3 gaidZFc/S4XKSAet2Gjpnb9Jds4PuIfvjFf/bcOU5R2i4Vr5dyKg0+4NTzqz53wUv6ox RQaOKPWX7qIvgdtkDvQ3RI0ghKtcCp/ifSgxGR7M/mnZUpXJkSRN1NCzvdvmXh3sUOhG r3ZxwvNHOHooN5iEuoQvhM66+KmKja+7creYCFuFjABLq3hrQTwXi6orNIq1DLrqjX+b kw2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rUWchDoKIMDjx7REd1lDAGgAk6m7IYhNTvpHswB7DEc=; b=C6k6piH8KgAEPW8pnhsm5v6FbC0dc19XAKWxgNftGUm25k/GcwTArMNgiSAQ9EO9Iw CmzyUUlacJN7Nf8jAlrRLgU+E0ltYvu+E64nbqukXbRmA6psNOmrJveu876zBF+nL1zN 6iz3sSGf8Cfhb8QvmdGnFQ5N9GaSraKu9GpNnqKIDaxirsLX6Cm85qtWZqKwn3BJUAk7 MvlsoglkLF1t12xkAe6LDIXrWR1wGodfm+dPXgnfUGLhEQytGPxGNSsfl1VOdlrXmIzp Vz4jvDdQApQMwYmagnPMB/4PYqrtrxY4i6G6wzFI9b0wZgxikA2ZwzOlG/g/VrhDPk2J ZA6w== X-Gm-Message-State: ALoCoQlw7aHw7E80HR4iVLVvmieCu5LpnbyrO+i/s1E5L9tIyiRRkw0+tUwdKs597lhW2NMLYNtJAxeP0g+bDrfDxI3pnSJhthfc4zpHfnlV7kgw7wOB4PJfr+itWmOX1lZQnsL81uyvMehtl/aMquRCggkx64lGAY7UgLVjz4cg6frkMZQ4Z7ymVqxfYUraWuaZ+vGtJGFD MIME-Version: 1.0 X-Received: by 10.221.26.10 with SMTP id rk10mr3524522vcb.0.1396966888424; Tue, 08 Apr 2014 07:21:28 -0700 (PDT) Received: by 10.52.119.179 with HTTP; Tue, 8 Apr 2014 07:21:28 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188BB@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188BB@USMBX1.msg.corp.akamai.com> Date: Tue, 8 Apr 2014 15:21:28 +0100 Message-ID: From: Ben Laurie To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/EvTSCoLB7brluZx2fDgJWbidV2w Cc: "trans@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [Trans] draft-iab-crypto-alg-agility-00 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, 08 Apr 2014 14:21:38 -0000 On 8 April 2014 15:18, Salz, Rich wrote: >> > I do not understand why metadata is more secure then the data itself. > >> It is created by a different authority. > > ? Is this in the part of the RFC that is still TBD? The RFC describes how logs work and how clients work. It does not describe how clients decide what logs they are prepared to accept. I am not sure it should. But whoever does also decides whether the algorithms in use by the logs are acceptable and tells the client what those algorithms are (along with other things, like the log's key, base URL and MMD). -- Certificate Transparency is hiring! Let me know if you're interested. From nobody Tue Apr 8 07:28: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 D64AE1A040A; Tue, 8 Apr 2014 07:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_42=0.6, 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 h07902V4Lblo; Tue, 8 Apr 2014 07:28:52 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CE1FC1A0415; Tue, 8 Apr 2014 07:28:51 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id q9so864053ykb.16 for ; Tue, 08 Apr 2014 07:28:51 -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=UgBaXS/icUxVU2t8r9yTc2fYXjbd0fNiFgvBJCVhkYc=; b=xfQNQhgYKQqj0ZLB6CLKFpf+wGosiRMd1c/vfzQ8YAZncCz9xk1q+Ui6wFoFxjVctY vazAzUAB6iCTY7HTwPEAhDROwRMi9E8FCjAFkta/30Buzre2FSRzVn7W+72dSDFWWVza BshhmRA6G2JwuwQ5yBcQ9bpEmmQHOH25Fes4WCWSaCU0uM9lMIyyN4EjU12Iy96OofPb Zg7I4A9pW7RuQ7F6tAW2BEPyNQr0m4a5IeUdNRP7grSUJ5tahDk+W/6Ihr/D2lDFBlv4 npwHPNFGs2LP/REEA7ndX4lN6Ggbhm0XU4AcQRTMdrGqHU5agIxLBQRnbDg6YND7L2X2 uegg== MIME-Version: 1.0 X-Received: by 10.236.4.225 with SMTP id 61mr3442558yhj.108.1396967331519; Tue, 08 Apr 2014 07:28:51 -0700 (PDT) Received: by 10.170.220.193 with HTTP; Tue, 8 Apr 2014 07:28:51 -0700 (PDT) In-Reply-To: References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188BB@USMBX1.msg.corp.akamai.com> Date: Tue, 8 Apr 2014 18:28:51 +0400 Message-ID: From: Dmitry Belyavsky To: Ben Laurie Content-Type: multipart/alternative; boundary=089e013cc12a8ee2ce04f688cde1 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rMT4V72IogvmuKsrMISB52O0RSg Cc: "trans@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [Trans] draft-iab-crypto-alg-agility-00 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, 08 Apr 2014 14:28:53 -0000 --089e013cc12a8ee2ce04f688cde1 Content-Type: text/plain; charset=UTF-8 Hello Ben, On Tue, Apr 8, 2014 at 6:21 PM, Ben Laurie wrote: > On 8 April 2014 15:18, Salz, Rich wrote: > >> > I do not understand why metadata is more secure then the data itself. > > > >> It is created by a different authority. > > > > ? Is this in the part of the RFC that is still TBD? > > The RFC describes how logs work and how clients work. It does not > describe how clients decide what logs they are prepared to accept. I > am not sure it should. > > But whoever does also decides whether the algorithms in use by the > logs are acceptable and tells the client what those algorithms are > (along with other things, like the log's key, base URL and MMD). > > I think that the client should be able to find out the algorithm used by log because it cant'be changed during the log lifetime. And if the RFC specifies the URIs for certificate submit, it seems to me that it's reasonable to specify the URI for finding out the algorithm. But I prefer to leave out of band of the protocol only the data that can't be passed using it. Thank you! -- SY, Dmitry Belyavsky --089e013cc12a8ee2ce04f688cde1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Ben,


On Tue, Apr 8, 2014 at 6:21 PM, Ben Laurie = <benl@google.com> wrote:
On 8 April 2014 15:18, Salz,= Rich <rsalz@akamai.com> wrot= e:
>> > I do not understand why metadata is more secure then the data= itself.
>
>> It is created by a different authority.
>
> ? =C2=A0Is this in the part of the RFC that is still TBD?

The RFC describes how logs work and how clients work. It does not
describe how clients decide what logs they are prepared to accept. I
am not sure it should.

But whoever does also decides whether the algorithms in use by the
logs are acceptable and tells the client what those algorithms are
(along with other things, like the log's key, base URL and MMD).

I= think that the client should be able to find out the algorithm used by log= because it cant'be changed during the log lifetime. And if the RFC spe= cifies the URIs for certificate submit, it seems to me that it's reason= able to specify the URI for finding out the algorithm. But I prefer to leav= e out of band of the protocol only the data that can't be passed using = it.

Thank you!

--
SY, Dmitry = Belyavsky
--089e013cc12a8ee2ce04f688cde1-- From nobody Tue Apr 8 07:34: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 166461A0402 for ; Tue, 8 Apr 2014 07:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 hBHZ-0jPFqJ7 for ; Tue, 8 Apr 2014 07:34:12 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD421A03FD for ; Tue, 8 Apr 2014 07:34:12 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:33201 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WXX6S-000PUg-6E for saag@ietf.org; Tue, 08 Apr 2014 10:34:20 -0400 Message-ID: <534408E3.8000307@bbn.com> Date: Tue, 08 Apr 2014 10:34:11 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <60BA03D4-5C92-4583-884D-38BCCBEBA7A6@vpnc.org> <5342B386.3080301@bbn.com> <5342EF69.7000306@bbn.com> <20140407195128.GD12559@mournblade.imrryr.org> In-Reply-To: <20140407195128.GD12559@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/OMoiSqeYJjstGsjkqgkehYjLeGw Subject: Re: [saag] new terminology ID posted 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, 08 Apr 2014 14:34:17 -0000 Viktor, Your message appears to be a reply to some of my responses to Paul. That makes my responses a bit confusing, but let me inject a few comments anyway. > On Mon, Apr 07, 2014 at 02:33:13PM -0400, Stephen Kent wrote: > >> Paul, >> >>> I wasn't at the STRINT workshop, but I did talk to participants >>> at the IETF afterward. None of them said that PFS was a requirement, >>> some said it was a goal. >> Well, the summary slides for the breakout session were not posted, so I >> can't point to them. I'm still waiting for comments from the other folks >> in the session to see what their recollection is. > Their recollection does not trump first-order logic. PFS *cannot* > be a *required outcome* for an opportunistic mode of operation. > Otherwise, welcome to mimecast.com SMTP client silly-land. You are begging the question. The unstated assumption is that any security mechanism that is not labelled as OS is not a good thing to do, or will not be deployed. I have never said that, nor do I believe it. > PFS can and should be a preferred mode of operation regardless of > whether security is opportunistic or mandatory. In this regard > nothing disqualifies DANE. The DANE WG was created well before the PM discussion began, and the relevant RFC (6698) was published a year before the IETF declared war on PM. So, DANE is a new, but existing IETF security technology, one that improves on the Web PKI model, but which still strives for creation of encrypted, authenticated sessions. It is NOT a new design generated in response to the war on PM, and thus whether it falls under the term OS should be irrelevant. > >> Right, but if a cert for a server contains a DH key, unless that key is >> changed after each time if is retrieved, the result will not be what I >> consider PFS. > Even with long-term fixed DH keys on the server (which are as common > with TLS as unicorns are on the prairie) the server is still free > to perform an ephemeral DH key exchange. PFS is not ruled out by > fixed DH keys. I'm not sure what you're referring to here. If one publishes a D-H public key via DANE, for what is it used if not key agreement? >> If the private key corresponding to the public key in the TLSA record were >> compromised, every passively wiretapped session with the server is >> vulnerable. The central security idea behind PFS is to limit the damage >> done by disclosure of a private key. That's why two-way, ephemeral DH is >> so attractive. From an ease of deployment perspective, ephemeral DH is >> attractive because there is no a priori posting of security data needed >> to enable it. > Though the public key will generally in fact not be *in* the TLSA > record, I'll read the above as equally applicable to the case when > the public key *digest* is in the TLSA record, which is I think > equivalent for your purpose. yes, my comment is equally applicable if DANE published the hash of a DH key used by a server. > Now if we're to take this objection to DANE as a mode of opportunistic > TLS seriously, we should note that there is nothing DANE specific > here. ANY server with a long-term key, whether it corresponds to > a DANE TLSA record or not, if it employs a non-PFS key exchange > mechanism, may facilit > ate decryption of past session via disclosure > of long-term keys. agreed. and that's a motivation to discourage use of such keys in the future. (Of course we already have this in IPsec, on a per-peer basis.) > Thus, we might conclude, that OS/OE clients MUST refuse to connect > to existing servers with stable long-term keys, or refuse to > negotiate non-PFS key exchange mechanisms, and thus, since we're > making encryption invisible, transparent, ... use the superior > cleartext mechanism which is free of the RSA key exchange failure > mode. Begging the question, again. The unstated assumption here is that OS is the ONLY option available to the client and sever. Note that one of the statement about OS is that it is NOT a substitute for existing, high quality security mechanisms that afford authentication as well as encryption. TLS with the Web PKI is one such mechanism, invoked by HTTPS, As far as I am concerned, DANE-enabled TLS is another such mechanism (if the TLSA record has been acquired via DNSSEC.) Since OS is to be invisible, there is a presumption (which I will endeavor to clarify) that a user will explicitly invoke an authenticated mode of communication if he/she so desires. > Clearly not! So all that could possibly be meant by the PFS goodness > from STRINT (I read the abstracts of most of the papers, and read > some in full) is that PFS should be promoted, and used as widely > as possible. This in no way excludes DANE any more than it excludes > any other opportunistically authenticated or unauthenticated > protocol. I think our only disagreement is whether DANE-enabled TLS (or IPsec, etc.) warrants the OS label. I say no, because use of DANE offers high quality, authenticated sessions as its primary goal, and because it precedes the war on PM. For future efforts, where removing all barriers to use of encryption is more important than authentication, OS is the term we ought to use. As I noted, since DANE requires publishing a TLSA record, it does not seem to be a good candidate to label as OS, i.e., because such publication is a barrier. Now, admittedly, one can say that deploying a new protocol that does not require each target of an OS connection to publish a DANE record is a barrier as well. That's true, but DANE use requires protocol changes, so it imposes 2 barriers to adoption: new software at the client and server, plus server publication of the TLSA record. I don't see that as a fatal flaw; I think DANE is a excellent mechanism, one that is superior to DV certs issued under the Web PKI model. But, that does not mean DANE-enabled foo should be labelled OS. >> Still, if the Sec ADs and others (not just the folks who have put a lot of >> effort into DANE) indicate that want a less prospective (yet still useful) >> definition for OS, I'll modify the doc accordingly. > This is rather a strange stance. There is NOTHING in DANE that > makes disclosure of long-term keys any more risky than with other > protocols. It seems you've the wrong end of the stick with respect > to DANE. It is *precisely* the folks who understand DANE in detail, > who are best positioned to provide guidance on whether DANE fits > the opportunistic security model or not. Again, your comments are focused on arguments that I am not making. DANE is not unique wrt the risks implied by use of long term keys. TLS based on the Web PKI has the same problem, as does S/MIME and SSH when they make use of key transport. The issue is that, going forward, there seems to be a strong desire to move to PFS-based encryption, and thus it makes sense to make that a criteria for new protocols that will be called OS. DANE is not "new" relative to this discussion. Steve From nobody Tue Apr 8 07:47: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 E6F4C1A0431 for ; Tue, 8 Apr 2014 07:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553] 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 ngClFtIXXGWU for ; Tue, 8 Apr 2014 07:47:04 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 32FC81A0410 for ; Tue, 8 Apr 2014 07:47:04 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s38EkxmV098552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Apr 2014 07:47:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <534408E3.8000307@bbn.com> Date: Tue, 8 Apr 2014 07:46:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <88B535DD-6A40-4263-8136-B3E68C3DF871@vpnc.org> References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <60BA03D4-5C92-4583-884D-38BCCBEBA7A6@vpnc.org> <5342B386.3080301@bbn.com> <5342EF69.7000306@bbn.com> <20140407195128.GD12559@mournblade.imrryr.org> <534408E3.8000307@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/j8Xiqr3mAJURSFVjbyQ-14Rj0jU Cc: saag@ietf.org Subject: Re: [saag] new terminology ID posted 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, 08 Apr 2014 14:47:05 -0000 Multiple people have asked for this document to be more inclusive of = DANE. So far, only you have stated an opinion in the negative. You = stated early on that your reason was due to requirements from the STRINT = workshop and asked for support from people at that workshop. That = support has not come, and I showed a message from a participant that = indicated the opposite. Can you say how much more support from this list will be needed in order = for you (as author) to make the document more inclusive? --Paul Hoffman= From nobody Tue Apr 8 07:51: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 204781A0427 for ; Tue, 8 Apr 2014 07:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, 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 ihplyU3_QUKa for ; Tue, 8 Apr 2014 07:51:10 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 936E41A0431 for ; Tue, 8 Apr 2014 07:51:05 -0700 (PDT) Received: from [192.168.16.131] (host-62-245-202-230.customer.m-online.net [62.245.202.230]) by smtp7.webway.se (Postfix) with ESMTPA id 822A893C2A1; Tue, 8 Apr 2014 14:50:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <88B535DD-6A40-4263-8136-B3E68C3DF871@vpnc.org> Date: Tue, 8 Apr 2014 16:51:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <70027B1E-F399-47A5-BEE4-348B721D2BF6@edvina.net> References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <60BA03D4-5C92-4583-884D-38BCCBEBA7A6@vpnc.org> <5342B386.3080301@bbn.com> <5342EF69.7000306@bbn.com> <20140407195128.GD12559@mournblade.imrryr.org> <534408E3.8000307@bbn.com> <88B535DD-6A40-4263-8136-B3E68C3DF871@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Ex56onHdf0RvRGxunJ5X1VOdGFk Cc: saag@ietf.org Subject: Re: [saag] new terminology ID posted 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, 08 Apr 2014 14:51:14 -0000 On 08 Apr 2014, at 16:46, Paul Hoffman wrote: > Multiple people have asked for this document to be more inclusive of = DANE. So far, only you have stated an opinion in the negative. You = stated early on that your reason was due to requirements from the STRINT = workshop and asked for support from people at that workshop. That = support has not come, and I showed a message from a participant that = indicated the opposite. >=20 > Can you say how much more support from this list will be needed in = order for you (as author) to make the document more inclusive? Related question: In SIP, we use DNS to indicate availability or requirement to use TLS - = NAPTR and SRV records. Our RFCs allow a client implementation to prefer = TLS and use it if it's available, regardless of what the user requires. = A server operator can enforce TLS too. Now, I would like to include clients that actually by code prefer TLS = for any SIP connection. If it's available, use it. The lucky part is that it doesn't seem like we have to update or write = any documents for this. Just enforce and encourage a better practise out = there. In my world, this way of thinking is part of "Oppurtunistic Security". = Is it in yours? /O From nobody Tue Apr 8 08:08: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 8CE041A03CA for ; Tue, 8 Apr 2014 08:07:59 -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] 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 e_lEk4eBSo-A for ; Tue, 8 Apr 2014 08:07:55 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B03FD1A03BA for ; Tue, 8 Apr 2014 08:07:55 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id BD6DB2005D109; Tue, 8 Apr 2014 08:07: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=uQ+FSwkfW+15Rx Ea1yLdJXKJhQE=; b=YWC9LsutzOOGGThDyW2xlnqEcJjTTbBNK5iw4FPsJQSuD+ r0r0BM4Rd5F37Wf7LkWKVUp5GjdzieByMdR5ITQ8Pc4+HuDH4Cunn6am5w8VPO3M RAFpnSoYOErSEkm7jreGerYypf96+DnocoXtnugIb1Nzr1psl4ak2ir5un1Co= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPA id 836EC2005D108; Tue, 8 Apr 2014 08:07:55 -0700 (PDT) Date: Tue, 8 Apr 2014 10:07:54 -0500 From: Nico Williams To: Stephen Kent Message-ID: <20140408150753.GH7962@localhost> References: <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <60BA03D4-5C92-4583-884D-38BCCBEBA7A6@vpnc.org> <5342B386.3080301@bbn.com> <5342EF69.7000306@bbn.com> <20140407195128.GD12559@mournblade.imrryr.org> <534408E3.8000307@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534408E3.8000307@bbn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/N3_ClZtxjb_s87Fh5nZi0p20OB0 Cc: saag@ietf.org Subject: Re: [saag] new terminology ID posted 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, 08 Apr 2014 15:07:59 -0000 On Tue, Apr 08, 2014 at 10:34:11AM -0400, Stephen Kent wrote: > >On Mon, Apr 07, 2014 at 02:33:13PM -0400, Stephen Kent wrote: > >>Right, but if a cert for a server contains a DH key, unless that key is > >>changed after each time if is retrieved, the result will not be what I > >>consider PFS. > > > >Even with long-term fixed DH keys on the server (which are as common > >with TLS as unicorns are on the prairie) the server is still free > >to perform an ephemeral DH key exchange. PFS is not ruled out by > >fixed DH keys. > > I'm not sure what you're referring to here. If one publishes a D-H > public key via DANE, for what is it used if not key agreement? Typically one would publish a signing (and/or encryption) certificate or bare public key in a host's TLSA RRset and then one would use an authenticated key exchange in TLS using that certificate to authenticate the server. This allows the client/server to use (or not use) [EC]DHE (PFS). Yes, it would be possible to publish [EC]DH keys/certs instead, thus leading to authenticate key exchanges that lack PFS, however, one could still get PFS via renegotiation. You seem to think that DANE -> not-PFS. This is not even remotely true! If that was your only concern about DANE then you should have none left :) If you have other concerns I'd like to know. Of course, one could come up with other concerns, such as that DNSSEC is a PKI with many of the problems inherent in a PKI, but since you're not rejecting PKI yourself... Nico -- From nobody Tue Apr 8 08:33: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 1CB731A03CA for ; Tue, 8 Apr 2014 08:32:59 -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 j_NHYcLkfJVW for ; Tue, 8 Apr 2014 08:32:56 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3F80B1A01C9 for ; Tue, 8 Apr 2014 08:32:56 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BFA5C2AABDF; Tue, 8 Apr 2014 15:32:55 +0000 (UTC) Date: Tue, 8 Apr 2014 15:32:55 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140408153255.GJ12559@mournblade.imrryr.org> References: <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <60BA03D4-5C92-4583-884D-38BCCBEBA7A6@vpnc.org> <5342B386.3080301@bbn.com> <5342EF69.7000306@bbn.com> <20140407195128.GD12559@mournblade.imrryr.org> <534408E3.8000307@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534408E3.8000307@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/1UBgll3S15VkojojMZ0GCoFag6k Subject: Re: [saag] new terminology ID posted 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, 08 Apr 2014 15:32:59 -0000 On Tue, Apr 08, 2014 at 10:34:11AM -0400, Stephen Kent wrote: > >Clearly not! So all that could possibly be meant by the PFS goodness > >from STRINT (I read the abstracts of most of the papers, and read > >some in full) is that PFS should be promoted, and used as widely > >as possible. This in no way excludes DANE any more than it excludes > >any other opportunistically authenticated or unauthenticated > >protocol. > > I think our only disagreement is whether DANE-enabled TLS (or IPsec, etc.) > warrants the OS label. You still have not really taken the time to internalize the distinction between DANE TLS in general (which may or may not be opportunistic) and "opportunistic DANE TLS". I make *no claim* that DANE TLS in general is opportunistic security. Recall that DANE can be used with protocols such as HTTPS or IMAPS where the requirement to authenticate the peer is presupposed. Nobody will benefit from anointing DANE TLS with inapplicable marketing labels however popular or appealing they might be. However, I *do claim* that "opportunistic DANE TLS" which is use of DANE authentication ONLY when TLSA records are published and otherwise fallback to strongest available security (typically "opportunistic TLS" which even includes cleartext as an option). The above behaviour is fundamentally a form of opportunistic security, except that it has a higher ceiling than you propose, in that it resists downgrade when enabled via DNSSEC TLSA records. Furthermore, it appears that you were unaware that TLS support authenticated PFS (signed ephemeral key exchange). Given that therefore the PFS objection is moot (DANE does not in any way preclude PFS), while the I-D should not specifically single out "opportunistic DANE TLS" as the preferred model for opportunistic security, the definition needs to be broad enough to include it. Opportunistic security needs to be broad enough to include most or all variations on: encrypt when possible, authenticate when possible, achieve best possible results, ... but don't throw in the towel just because for some peer all that's possible is cleartext or unauthenticated TLS. With "opportunistic DANE TLS" the only twist is that to avoid downgrade attacks clients don't fall back when usable TLSA records are published. > I say no, because use of DANE offers high quality, > authenticated sessions as its primary goal, and because it precedes the > war on PM. You're still not listening, you have a pre-conceived notion of what DANE TLS means and ignoring all facts to the contrary. RFC 6698 specifies a TLSA record format, it does not specify all possible uses of that record format. In "opportunistic DANE TLS" that record format is used to *opportunistically* achieve downgrade-resistant DANE authenticated security (when possible) but it is still fundamentally a best effort security mechanism like the original STARTTLS in SMTP. Please make sure that the I-D definition does not preclude this form of opportunistic security. Please take the time (ask questions if need be) to better understand what "opportunistic DANE TLS" is and why it is relevant as an example of OS. > For future efforts, where removing all barriers to use of > encryption is more important than authentication, OS is the term we ought > to use. As I noted, since DANE requires publishing a TLSA record, it does > not seem to be a good candidate to label as OS, i.e., because such > publication is a barrier. Opportunistic DANE TLS works even when zero servers have published TLSA records, it is simply identical to "opportunistic TLS" in that case. There is no barrier to adoption of the client's "opportunistic" behaviour. Unlike IPSEC in which client and server roles are largely symmetric, or even meaningless, in TLS OS is fundamentally a *client* behaviour. Server software does nothing to enable DANE TLS opportunistic or otherwise, it just sits there and does TLS. The operators of servers who want to enable DANE security, publish TLSA records in their DNSSEC signed zones. This enables opportunistically DANE enabled clients to make downgrade-resistant DANE authenticated connections to JUST the servers that have done so. Yes, DNSSEC is a barrier to adoption of server-side TLSA record publishing, but that has nothing to do with OS/OE. There is no barrier to adoption of the client behaviour of doing DANE when possible, failing that TLS when possible, failing that cleartext. > Now, admittedly, one can say that deploying a > new protocol that does not require each target of an OS connection to > publish a DANE record is a barrier as well. It seems you're still trying to define a single protocol, where-as OS should be an umbrella term for a family of protocol designs that includes a variety of existing and future IETF protocols. > That's true, but DANE use > requires protocol changes, so it imposes 2 barriers to adoption: new > software at the client and server, plus server publication of the TLSA > record. Yes, "opportunistic DANE TLS" will not be the *primary* form of opportunistic security. Perhaps for the next 5-10 years as DNSSEC adoption increases (or fizzles out) "opportunistic DANE TLS" will be used in only a small fraction of the connections that qualify as "OS". This does not make this use-case invalid. > I don't see that as a fatal flaw; I think DANE is a excellent > mechanism, one that is superior to DV certs issued under the Web PKI model. > But, that does not mean DANE-enabled foo should be labeled OS. Unless DANE is used *opportunistically*! > The issue is that, going forward, > there seems to be a strong desire to move to PFS-based encryption, and > thus it makes sense to make that a criteria for new protocols that will > be called OS. DANE is not "new" relative to this discussion. Whether DANE is new or existed before is irrelevant, existing protocols that meet a sensible definition of "OS" should not be excluded from OS, just because they existed before the summer of 2013. And in fact while DANE is not "new", "opportunistic DANE TLS" is new, it was proposed by me in the DANE SMTP draft specifically as a new use-case for DANE. We will only make progress if you take the time ask questions to help you better understand the nature of the requested more inclusive definition, rather than continue to object on the basis of firmly held preconceived counter-factual notions. -- Viktor. From nobody Tue Apr 8 11:00: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 366591A068D for ; Tue, 8 Apr 2014 11:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, USER_IN_WHITELIST=-100] 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 B0X95etzJKz1 for ; Tue, 8 Apr 2014 11:00:05 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 716421A0682 for ; Tue, 8 Apr 2014 11:00:05 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 7356DF2C065 for ; Tue, 8 Apr 2014 13:59:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id Om1n9ySjpuv0 for ; Tue, 8 Apr 2014 13:59:32 -0400 (EDT) Received: from [192.168.2.100] (pool-96-241-160-129.washdc.fios.verizon.net [96.241.160.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 81EAEF2C04B for ; Tue, 8 Apr 2014 13:59:32 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Apr 2014 13:59:20 -0400 Message-Id: To: IETF SAAG Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/p2HYn1QU71uW61hgGZ08xUb-M2Y Subject: [saag] NIST Announces Release of the Draft Revision of Special Publication 800-56B 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, 08 Apr 2014 18:00:10 -0000 FYI =3D =3D =3D =3D =3D =3D =3D =3D =3D=20 =20 NIST announces the release of the Draft Revision of Special Publication = 800-56B, Recommendation for Pair-Wise Key Establishment Schemes Using = Integer Factorization Cryptography = . NIST SP 800-56B specifies key-establishment schemes based on the = Rivest Shamir Adleman (RSA) algorithm. The revision is made on the = August 2009 version. The main changes are listed in Appendix D. =20 Please submit comments to 56B2014rev-comments@nist.gov with "Comments on = SP 800-56B (Revision 1)" in the subject line. The comment period closes = on May 15, 2014.= From nobody Tue Apr 8 11:31: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 997C31A068B for ; Tue, 8 Apr 2014 11:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 uF8yyHfJRE4h for ; Tue, 8 Apr 2014 11:30:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E7D271A068D for ; Tue, 8 Apr 2014 11:30:51 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49140 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WXanT-0001uJ-Cm; Tue, 08 Apr 2014 14:30:59 -0400 Message-ID: <5344405A.2060402@bbn.com> Date: Tue, 08 Apr 2014 14:30:50 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ben Laurie References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <5342E65C.5070309@bbn.com> 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/XuS8chVsjmZkEqhkEed8nTVWdtc Cc: "saag@ietf.org" Subject: Re: [saag] draft-iab-crypto-alg-agility-00 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, 08 Apr 2014 18:31:06 -0000 Ben, > On 7 April 2014 18:54, Stephen Kent wrote: >> Ben, >> >> Sorry to jump on late on this, but as a co-author of an RFC that deals >> with alg agility for the RPKI, I thought I might be able to contribute. >> >> It's generally useful to have a MUST implement alg (or set, if there are >> multiple >> algs needed) for any set of protocols (data formats, etc.) to help ensure >> interoperability. Selecting the MUST implement is sometimes hard, but it's >> worth >> the effort. >> >> Then one needs to have a way for all clients, CA, and log servers (in the CT >> context) >> to express which alg9s) are being used at any time, so that everyone else >> knows >> what choices have been made, when choices are allowed, and to guide folks >> through the >> transition process. > I am not really arguing with that, actually. But in the case of CT, > this information needs to be in the metadata about the logs. The RFC > does not currently specify how that metadata becomes available to > clients (and I'm not sure it should, either). Is that really the only option, i.e., externally-distributed alg info? I worry that this will be a problem. The RFC really needs to address this. Steve From nobody Tue Apr 8 11:33: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 0E77E1A0465 for ; Tue, 8 Apr 2014 11:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 b3x1qbZHGqa2 for ; Tue, 8 Apr 2014 11:33:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 87F981A0660 for ; Tue, 8 Apr 2014 11:33:23 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38272 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WXapv-0001vH-Ni for saag@ietf.org; Tue, 08 Apr 2014 14:33:31 -0400 Message-ID: <534440F2.2090607@bbn.com> Date: Tue, 08 Apr 2014 14:33:22 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188BB@USMBX1.msg.corp.akamai.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/rzdawItQf7SMySUlsYuEqpmj6OQ Subject: Re: [saag] [Trans] draft-iab-crypto-alg-agility-00 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, 08 Apr 2014 18:33:25 -0000 Ben, > On 8 April 2014 15:18, Salz, Rich wrote: >>>> I do not understand why metadata is more secure then the data itself. >>> It is created by a different authority. >> ? Is this in the part of the RFC that is still TBD? > The RFC describes how logs work and how clients work. It does not > describe how clients decide what logs they are prepared to accept. I > am not sure it should. It may be OK to separate the discussions, but there needs to be an architecture doc that does address these questions. I fact I think it needs to precede the details that the current doc addresses. Steve From nobody Tue Apr 8 12:22: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 805E91A01BA for ; Tue, 8 Apr 2014 12:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 dxKLqabZiE0b for ; Tue, 8 Apr 2014 12:22:50 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF931A04A8 for ; Tue, 8 Apr 2014 12:22:50 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:41287 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WXbbd-000BZl-LL for saag@ietf.org; Tue, 08 Apr 2014 15:22:49 -0400 Message-ID: <53444C89.4040502@bbn.com> Date: Tue, 08 Apr 2014 15:22:49 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <5342B454.1050607@bbn.com> <20140407150834.GW12559@mournblade.imrryr.org> <5342EF73.5070903@bbn.com> <20140407203658.GE12559@mournblade.imrryr.org> In-Reply-To: <20140407203658.GE12559@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/GEcPE5FiIshIQlzS8DRyFV9SylY Subject: Re: [saag] new terminology ID posted 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, 08 Apr 2014 19:22:52 -0000 Viktor, > On Mon, Apr 07, 2014 at 02:33:23PM -0400, Stephen Kent wrote: > > [ Reordered, because the below may the crux of the contention. ] > >>> "In light of the above, there is nothing in DANE TLS that specifically >>> contra-indicates PFS. Indeed, for example, with Postfix PFS ciphersuites >>> will be used at highest preference whenever the server supports these, >>> whether the authentication mechanism is DANE or PKIX and none at all (legacy >>> opportunistic TLS)." >> Sorry that I missed that in the RFC. Can you remind me of the specific text >> that indicates PFS support? I know that TLS can support PFS via the DH or >> ECDH cipher suite, but the TLS RFCs indicate that this is an intentionally >> server-anonymous mode of communication. > I think this nails the source of the confusion. TLS supports PFS *with* > authentication. That's the distinction between the: > > # ADH-* and DHE-* ciphersuites. The former are anonymous, in the > latter the PFS key exchange is signed with the server's long-term > keys. > > # AECDH-* and ECDHE-* ciphersuites. The former are anonymous, > in the latter the PFS key exchange is signed with the server's > long-term keys. I asked for references (from RFC 5246). I scanned that RFC for AECDH and for ADH found no hits. I did find text for DHE and ECDHE and you are correct that these cipher suites offer the potential for PFS, and F.1.1.3 explicitly states that one should use a fresh DH secret for each exchange to achieve PFS. Is this done by many servers? Anyway, thanks for the clarification (I was focusing on F1.1.1). >> DANE-enabled TLS is a great technology. But, it requires that a target of >> a session create a TLSA record. That, by itself, is a potential impediment >> to widespread use. > Of course, I am not suggesting that "opportunistic DANE TLS" is > the one only true "opportunistic security". I am merely suggesting > that DANE TLS is (for now pending wider DNSSEC deployment) a small > legitimate corner case that should not be *excluded* from the wide > umbrella term of "opportunistic security". why should it not be excluded as we create definitions for a NEW set of security protocols? >> In contrast, a protocol that calls for the initiator >> and responder to perform an ephemeral D-H exchange does not impose such a >> burden. If a TLSA record exists, one could send it after the encrypted >> session was in place. > This view of "opportunistic security" as a single protocol is > clearly too narrow. For example, an HTTP client that opportunistically > upgrades to HTTPS would be ill-advised to refuse to employ non-PFS > cipher-suites and fall back to HTTP. this use of the term "opportunistic" argues for he need to have a more precise definition :-). Nothing needs to be labelled as "opportunistic" to be good or to be deployed. > Sure, we want to encourage servers and clients to support PFS and > preferentially negotiate PFS key exchange mechanisms. This does > not mean that technologies that are *capable* of non-PFS modes of > operation on either the client or the server are automatically > disqualified. Again, the term "disqualified" strikes me as inappropriate. My focus has been on documenting criteria for a set of new protocols, created in response to the IETF war on PM. These criteria were discussed in a STRINT workshop session devoted to the topic, and attended by current and former Sed ADs, the IETF Chair, and several WG chairs who are dealing with the topic. None of this should be seen as competing with existing security protocols, e.g., TLS or IPsec. TLS, whether used with the Web PKI or with DANE, offers potentially better security service guarantees than an OS protocol. >> I'm not sure how to interpret your response. It could be that you worry >> that if DANE-enabled TLS isn't covered under the OS term, that will hinder >> its adoption. > No, my concern is that you've proposed a needlessly narrow view of > "opportunistic security" that hinders technical discussion of > related approaches to getting "as strong as possible" security. You say "needlessly narrow" I say "clearly defined" :-). Your characterization of "as strong as possible" makes no mention of widely deployed, which is a critical aspect of OS. It also seems to suggest that if something isn't labelled OS, it will not be deployed. That's silly, to paraphrase your criticism. >> Maybe you feel that it's better to push for >> DANE-enabled TLS now, and now wait for a PFS solution, i.e., the protocol >> in the hand is better that a PFS in the bush, so to speak. > * With respect to definitions of OS/OE I not pushing for DANE > in preference to any other opportunistic approach. Perhaps > that's the source of confusion. I am asking that your > definitions not *exclude* opportunistic use of DANE, but > definitely you SHOULD NOT prescribe DANE. why? > * DANE neither demands nor precludes PFS, you don't need to > wait for anything. Postfix uses DANE with PFS, PKIX with > PFS, opportunistic unauthenticated TLS with PFS, ... DANE certainly does not demand PFS, but only one of the three certs types defined in 6698 is supportive of PFS w/o authentication. But, as you noted, if one employs authenticated cipher suites plus DH (ECDH) one can still achieve PFS. > * PFS is orthogonal to all other aspects of the various protocols, > it just a set of key exchange mechanisms that happens to be > advantageous in the face of demands for disclosure of long-term keys. yes, PFS is just one aspect of a key management mechanism. It happens to be an aspect that was strongly endorsed at the workshop, which is why it is called out in the doc. >> I don't disagree >> with that observation. But, does that mean we need to make the definition >> as set of statement of the form: "you can do A, or B, and if you do A, >> then you may or may not do C, but if you do B, then ..." That seems >> confusing, at least to me. > To be honest, I no longer recall at this point which parts of the > definitions in the most recent version of the I-D seemed to exclude > DANE, and if I misread the defintions, and none do, great! Then I suggest you read the next rev when it appears. But, frankly, I see no need to accommodate DANE (RFC 6698) under the OS umbrella, and I have heard no good explanation for why it ought to be included. > However, if the definitions are in fact restrictive to the point > of excluding opportunistic DANE from the umbrella defintion of > opportunistic security, then that is my objection. I don't believe > that you should be defining a single protocol. Rather this I-D > should be defining a new approach to securing many protocols in > which the security bar is not fixed at a high minimum that leaves > most traffic completely unprotected. I am not defining a single protocol. But I also see no reason to include DANE as an OS protocol. You have not provided a simple, compelling argument for inclusion. Please do so. > Opportunistic use of DANE is one mechanism to allow the bar to > float between cleartext and DNSSEC authenticated that fits within > the overall philosophy of "opportunistic security". Oh, have you been alluding (but not stating explicitly) to I-Ds that propose new ways to make use of DANE, as opposed to the extant RFC? That was not clear to me from any of your messages. My comments about whether DANE needs to be included under the OS definition have been based on 6698. > >> I don't think my message said that. It said that a protocol characterized as >> OS makes use of PFS. If one tries to execute an OS protocol, and a peer does >> not support it, and if we stick with the criteria developed in the workshop, >> then one would fallback to plaintext. You seem to be saying that it would be >> preferable to not require PFS if that means falling back to plaintext, > Absolutely, and I think I would get majority support for this view. that was not the view of the workshop breakout session participants, but perhaps that's because the focus was on maximizing use of encryption, with minimal added connection setup delay. > >> when one could use DANE-enabled TLS instead. > No, when one could use other key exchange mechanism, including RSA > key exchange. Even with RSA key exchange one is free to ignore > the server's certificate leaving the server unauthenticated. DANE > is irrelevant here. Implementations may choose to ignore a server cert, but it's not the general intent of TLS, certainly if a human user is involved. >> I don't disagree with that order of preference; the question is whether >> this should be called OS. > With "opportunistic DANE TLS" (for example), DANE authentication > is mandated when TLSA records are published, but in their absence > the policy degrades to "opportunistic TLS", which in the absence > of TLS support (e.g. with SMTP no STARTTLS) degrades to cleartext. > OK, now I see what you're focusing on. It was not at all clear in your previous messages, which referred to DANE, which I interpreted as 6698. (BTW, your I-D refers to CAs as "certificate authorities." They're "certification authorities.") Steve From nobody Tue Apr 8 12:23: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 BA9451A0704 for ; Tue, 8 Apr 2014 12:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 mGRWj9d1IUd9 for ; Tue, 8 Apr 2014 12:23:49 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 53AD71A0702 for ; Tue, 8 Apr 2014 12:23:49 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:41288 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WXbcb-000Bap-1o for saag@ietf.org; Tue, 08 Apr 2014 15:23:49 -0400 Message-ID: <53444CC4.50708@bbn.com> Date: Tue, 08 Apr 2014 15:23:48 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <60BA03D4-5C92-4583-884D-38BCCBEBA7A6@vpnc.org> <5342B386.3080301@bbn.com> <5342E5DC.4030102@cs.tcd.ie> <20140407181340.GA12559@mournblade.imrryr.org> In-Reply-To: <20140407181340.GA12559@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/WhuJWfOmpeSkRmU5GuSxwNFyNkM Subject: Re: [saag] new terminology ID posted 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, 08 Apr 2014 19:23:55 -0000 Viktor, > On Mon, Apr 07, 2014 at 06:52:28PM +0100, Stephen Farrell wrote: > >> I think PFS is a fine thing for OE/OS, and would like to see >> it as at least the common case that we strongly encourage. I >> guess we'll all easily agree on that. > Yes, strongly encourage. > >> I'm not sure whether or not we ought go as far as to say that >> use of RSA key transport means that a scheme does not conform >> to our OS/OE terminology. > More to the point, when encountering a server that *only* supports > RSA key transport, should an OS/OE client avoid using TLS, and send > in cleartext? Clearly not! That is not the question in the table. The question I'm addressing is for NEW protocols/mechanisms being developed as part of the IETF war on PM. TLS typically is used with RSA key transport. The proposed OS criteria says that OS is NOT a substitute for existing security protocols, especially ones that provide authenticated, encrypted communication. >> I could personally go either way on this, or put another way, >> I'd be fine myself with if we have a rough consensus either way >> on the topic, and yes, there are pros and cons. > There really are no "pros and cons" here. Opportunistic security > clients MUST be willing to accept RSA key transport when that's > all that is available, cleartext is never a better option. However, > servers that want to claim support for OS/OE (the marketing term), > SHOULD support PFS. I guess we should start with the question of how one defines an OS client. Because OS is not intended to be a substitute for TLS (for example), when invoked via HTTPS (or redirect to HTTPS), use of key transport in that context is fine; it's not OS. > The PFS red-herring is quite orthogonal to the opportunistic > component of client policy. That is, PFS is motherhood and apple > pie goodness across the board from opportunistic unauthenticated > encryption to pre-shared peer fingerprint authentication. PFS is a beneficial side effect of ephemeral key agreement. Ephemeral key agreement is a good starting point for OS because it impose NO requirements on the initiator or target of a session to have done anything other than run software that supports that capability. Perhaps it would be better to make that a more explicit element of the OS criteria, separate from PFS. >> So colour me uncertain on this one. > I think you're letting yourself off the hook too easily. Or in > any case I am not letting you of the hook that easily. Elementary > logic leads one quickly to conclude that PFS *cannot* be a requirement. > Otherwise we end up in mimecast.com silly-land where, for example, > cleartext is used in place of TLS because certificate verification > fails or TLS did not use PFS, ... > Elementary logic, absent unstated assumptions, does not lead one to the conclusion you stated, as per my response to your prior message that used the same text. Steve From nobody Tue Apr 8 12:27: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 84AB51A0425 for ; Tue, 8 Apr 2014 12:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 qu9tcbtRtnJ9 for ; Tue, 8 Apr 2014 12:27:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 479DC1A01BA for ; Tue, 8 Apr 2014 12:27:15 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:53226 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WXbg2-0002VQ-Om; Tue, 08 Apr 2014 15:27:22 -0400 Message-ID: <53444D91.6080609@bbn.com> Date: Tue, 08 Apr 2014 15:27:13 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Paul Hoffman References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <60BA03D4-5C92-4583-884D-38BCCBEBA7A6@vpnc.org> <5342B386.3080301@bbn.com> <5342EF69.7000306@bbn.com> <20140407195128.GD12559@mournblade.imrryr.org> <534408E3.8000307@bbn.com> <88B535DD-6A40-4263-8136-B3E68C3DF871@vpnc.org> In-Reply-To: <88B535DD-6A40-4263-8136-B3E68C3DF871@vpnc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Y-eHsEw1J-4BFKUXIQx9ujIjwR0 Cc: saag@ietf.org Subject: Re: [saag] new terminology ID posted 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, 08 Apr 2014 19:27:16 -0000 Paul, > Multiple people have asked for this document to be more inclusive of DANE. So far, only you have stated an opinion in the negative. You stated early on that your reason was due to requirements from the STRINT workshop and asked for support from people at that workshop. That support has not come, and I showed a message from a participant that indicated the opposite. no, you didn't. if you read (and understood) my reply, you would see that Stephen's comment do not contradict what I said. Try again. > Can you say how much more support from this list will be needed in order for you (as author) to make the document more inclusive? I see a lot of comments from you and Viktor, two ardent DANE supporters who seem to be concerned that if DANE isn't labelled as OS, it will somehow be ignored. I see a separate set of comments from Nico, focusing on a different set of issues. That's a useful, not DANE-centric, discussion in which I am participating. I saw one comment from Stephen Farrell, who indicated indicated that he was not sure whether PFS was a strict requirement. I'm willing to wait a few days to let others who participated in the workshop have a chance to comment. Steve From nobody Tue Apr 8 12:58: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 EB8DE1A0711 for ; Tue, 8 Apr 2014 12:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.855 X-Spam-Level: X-Spam-Status: No, score=0.855 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] 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 0GPC-UCM0avb for ; Tue, 8 Apr 2014 12:58:37 -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 3CD201A0256 for ; Tue, 8 Apr 2014 12:58:37 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 3EDF42007F125 for ; Tue, 8 Apr 2014 12:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=Hcl6pGac3pxtoF29g6kMKEjTnZM=; b=isjJl/4sa5x ANvUfaY+LkcbD+Sb1lQBZAyZMVg0yeiGBC7IG/F62CB25jw9AmabP6+eTfK2dtfp AJM9uJ4Qf3a7DIaiQUBOf3z2in+DGY+jrx0zQGvJL+liY2tTk+jw7dMvOViN2zcy XgkVmt6xeVGu7FSKVDaK7LbAAJBM/dVo= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (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 E794B2007F124 for ; Tue, 8 Apr 2014 12:58:36 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so1494861wgg.30 for ; Tue, 08 Apr 2014 12:58:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.181.5.6 with SMTP id ci6mr6107106wid.39.1396987115584; Tue, 08 Apr 2014 12:58:35 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Tue, 8 Apr 2014 12:58:35 -0700 (PDT) Date: Tue, 8 Apr 2014 14:58:35 -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/5RGLWIce_QWwQdhcouYQL2ih1p8 Cc: "saag@ietf.org" Subject: [saag] OS is generic (Re: new terminology ID posted) 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, 08 Apr 2014 19:58:41 -0000 On Tue, Apr 8, 2014 at 2:22 PM, Stephen Kent wrote: >> On Mon, Apr 07, 2014 at 02:33:23PM -0400, Stephen Kent wrote: >> Of course, I am not suggesting that "opportunistic DANE TLS" is >> the one only true "opportunistic security". I am merely suggesting >> that DANE TLS is (for now pending wider DNSSEC deployment) a small >> legitimate corner case that should not be *excluded* from the wide >> umbrella term of "opportunistic security". > > why should it not be excluded as we create definitions for a NEW set > of security protocols? The notion of opportunistic security that I thought we were working on was intended to be *generic*, with application to existing protocols done separately. You are now saying that your proposal for "opportunistic security" should be applied only to "NEW security protocols" (quoting you almost verbatim). Is that right?? If that's right, can you please make a detailed argument not only as to why we must wipe the slate clean, but how we'll manage to deploy the new security protocols on a large scale? And while you're at it, please justify the notion that we must not apply the new OS concept to existing security protocols -- that makes absolutely no sense to me unless the situation with current protocols is so bad that nothing short of starting from scratch could help. Before you start, I have to tell you that a) I reject this idea that OS should apply only to NEW security protocols because I believe we need a generic concept of opportunistic security b) I find the proposal that we must start with a blank slate very difficult to take seriously. Nico -- From nobody Tue Apr 8 14:18: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 A12671A06E5 for ; Tue, 8 Apr 2014 14:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 x8dhFBUw_G6g for ; Tue, 8 Apr 2014 14:18:22 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8530E1A02A2 for ; Tue, 8 Apr 2014 14:18:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 37E4ABE61; Tue, 8 Apr 2014 22:18: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 vG71eDWBpK6s; Tue, 8 Apr 2014 22:18:20 +0100 (IST) Received: from [10.87.48.4] (unknown [86.45.52.44]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 231A8BDCA; Tue, 8 Apr 2014 22:18:20 +0100 (IST) Message-ID: <5344679B.6050803@cs.tcd.ie> Date: Tue, 08 Apr 2014 22:18:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nico Williams , Stephen Kent References: 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/kwb0Yif_ljrK9ar0_SZrnjPn9Fs Cc: "saag@ietf.org" Subject: Re: [saag] OS is generic (Re: new terminology ID posted) 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, 08 Apr 2014 21:18:29 -0000 On 04/08/2014 08:58 PM, Nico Williams wrote: > The notion of opportunistic security that I thought we were working on > was intended to be *generic*, with application to existing protocols > done separately. FWIW, the above is what I think we're doing. I don't see that new/old is of much relevance really. S. From nobody Tue Apr 8 14:23: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 767B71A02C8 for ; Tue, 8 Apr 2014 14:23: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 BYMImTkkqQDF for ; Tue, 8 Apr 2014 14:23:06 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 133B11A02A2 for ; Tue, 8 Apr 2014 14:23:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D339F2AABD5; Tue, 8 Apr 2014 21:23:04 +0000 (UTC) Date: Tue, 8 Apr 2014 21:23:04 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140408212304.GO12559@mournblade.imrryr.org> References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <5342B454.1050607@bbn.com> <20140407150834.GW12559@mournblade.imrryr.org> <5342EF73.5070903@bbn.com> <20140407203658.GE12559@mournblade.imrryr.org> <53444C89.4040502@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53444C89.4040502@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/z91LaM4__uQx9QkylKI_YK8EkY8 Subject: Re: [saag] new terminology ID posted 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, 08 Apr 2014 21:23:09 -0000 On Tue, Apr 08, 2014 at 03:22:49PM -0400, Stephen Kent wrote: > I am not defining a single protocol. But I also see no reason to > include DANE as an OS protocol. You have not provided a simple, > compelling argument for inclusion. Please do so. I am not asking you to classify RFC 6698 DANE as OS. Rather, I'm asking you leave room for opportunistic variants of RFC 6698 such as: http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane Opportunistic DANE TLS is a protocol in which (for now SMTP) clients employ as strong as possible security with each (SMTP) server. This subsumes cleartext for servers that neither publish TLSA records nor offer STARTTLS (or some MITM downgraded their EHLO response). It also subsumes opportunitic unauthenticated TLS when no TLSA records are found, but STARTTLS is available. It also subsumes mandatory unauthenticated TLS when TLSA records exist, but none are usable, ... > >Opportunistic use of DANE is one mechanism to allow the bar to > >float between cleartext and DNSSEC authenticated that fits within > >the overall philosophy of "opportunistic security". > > Oh, have you been alluding (but not stating explicitly) to I-Ds that > propose new ways to make use of DANE, as opposed to the extant RFC? Yes. > That was not clear to me from any of your messages. My comments about > whether DANE needs to be included under the OS definition have been > based on 6698. RFC 6698 is NOT "opportunistic DANE TLS". > >To be honest, I no longer recall at this point which parts of the > >definitions in the most recent version of the I-D seemed to exclude > >DANE, and if I misread the defintions, and none do, great! > > Then I suggest you read the next rev when it appears. But, frankly, > I see no need to accommodate DANE (RFC 6698) under the OS umbrella, > and I have heard no good explanation for why it ought to be included. Because DANE is not just RFC 6698. The DANE SMTP draft defines "opportunistic DANE TLS", which should be included, and I expect will be excluded, once confusion and the needless objections cease. > >With "opportunistic DANE TLS" (for example), DANE authentication > >is mandated when TLSA records are published, but in their absence > >the policy degrades to "opportunistic TLS", which in the absence > >of TLS support (e.g. with SMTP no STARTTLS) degrades to cleartext. > > OK, now I see what you're focusing on. It was not at all clear in your > previous messages, which referred to DANE, which I interpreted as 6698. > (BTW, your I-D refers to CAs as "certificate authorities." > They're "certification authorities.") Thanks for the feedback, I will make appropriate changes this evening. > DANE certainly does not demand PFS, but only one of the three > certs types defined in 6698 is supportive of PFS w/o authentication. This is false. If you have questions about DANE, feel free to ask, but making clearly erroneous statements does not help move this issue forward. None of the 4 certificate usages in DANE are in any way correlated with use or non-use of PFS. > But, as you noted, if one employs authenticated cipher suites plus > DH (ECDH) one can still achieve PFS. Across all TLSA record types, the TLSA record does not select the TLS key exchange mechanism. It can be PFS or RSA key transport if the keys happen to be RSA keys, but even RSA keys work with PFS. > Implementations may choose to ignore a server cert, but it's not > the general intent of TLS, certainly if a human user is involved. The primary use-case for opportunistic DANE TLS is not HTTPS. It is a reasonable protocol wherever one would otherwise typically have no security or best unauthenticated security, and where there both some tolerance for latency and some desire for authentication when possible. For SMTP it fits like a glove, especially because PKIX is profoundly unusable with SMTP. Similar considerations lead to an essentially opportunistic use of DANE TLS in XMPP (they've just not applied the term yet). -- Viktor. From nobody Tue Apr 8 17:49: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 AE3A91A074B; Tue, 8 Apr 2014 17:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_42=0.6, 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 zdF6atps0HeQ; Tue, 8 Apr 2014 17:49:31 -0700 (PDT) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4F91A0192; Tue, 8 Apr 2014 17:49:30 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id mz13so1640496bkb.3 for ; Tue, 08 Apr 2014 17:49:30 -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=8LOIVsN/+D8j127nMPTBFGSuEqyGAQR8QAnOM8hR4L4=; b=VzFIw3k4QV0jNUPQGDIdTT9XID7V8cAmjWku1vUXm7xxBpLTYdYGKxCyKXiRNbahe4 5gks2Sw8l6VMZco/gNlGKmgOVCExfG7VdEtuYBWadTCJG1yDK2/ZxAOAsIiSD/gRO2Rq 8Xmaaui1U5yodRgQdjGXLpGb4+XrAYclP+2ZUjl5TVpZ7ie9JS9bCmzDBEM00Z/jGP0g FjSMC4NQUyXTorWKOnQLG6BGcV/Dd08yoC3moC0WuG22UWP3FoR9d5fENqO7PE4qCsnv ehmZOmL65JCuHjFGWcouTfaYpcSJldpKShKTOb+9Z6hq2PS7+RaejSfCnD3axARLhBi9 I5kA== MIME-Version: 1.0 X-Received: by 10.112.150.233 with SMTP id ul9mr4854444lbb.2.1397004570250; Tue, 08 Apr 2014 17:49:30 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Tue, 8 Apr 2014 17:49:30 -0700 (PDT) In-Reply-To: References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188BB@USMBX1.msg.corp.akamai.com> Date: Tue, 8 Apr 2014 20:49:30 -0400 Message-ID: From: Phillip Hallam-Baker To: Dmitry Belyavsky Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Jj-C5L9uEVt5U9PHzwrlRgCanAY Cc: "trans@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [Trans] draft-iab-crypto-alg-agility-00 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, 09 Apr 2014 00:49:33 -0000 Since TRANS is joined to X.509 at the hip, how about we just shovel all the metadata describing the configuration of the notary into the certificate that signs the notary log outputs periodically? I am assuming here that the signing hierarchy for the log has an offline key that periodically signs the online key. The cert for the online key can specify the notary algorithm by OID (its ASN.1 after all) and any other parameters that might be useful. Probably want to allow for different accumulation strategies in case we ever decide a binary tree isn't the only choice. Might have some other options. Might want to be able to specify the CPS/CP equivalents for the notary, etc. On Tue, Apr 8, 2014 at 10:28 AM, Dmitry Belyavsky wrote: > Hello Ben, > > > On Tue, Apr 8, 2014 at 6:21 PM, Ben Laurie wrote: >> >> On 8 April 2014 15:18, Salz, Rich wrote: >> >> > I do not understand why metadata is more secure then the data itself. >> > >> >> It is created by a different authority. >> > >> > ? Is this in the part of the RFC that is still TBD? >> >> The RFC describes how logs work and how clients work. It does not >> describe how clients decide what logs they are prepared to accept. I >> am not sure it should. >> >> But whoever does also decides whether the algorithms in use by the >> logs are acceptable and tells the client what those algorithms are >> (along with other things, like the log's key, base URL and MMD). >> > I think that the client should be able to find out the algorithm used by log > because it cant'be changed during the log lifetime. And if the RFC specifies > the URIs for certificate submit, it seems to me that it's reasonable to > specify the URI for finding out the algorithm. But I prefer to leave out of > band of the protocol only the data that can't be passed using it. > > Thank you! > > -- > SY, Dmitry Belyavsky > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Website: http://hallambaker.com/ From nobody Wed Apr 9 06:13: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 5EE401A02B8 for ; Wed, 9 Apr 2014 06:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 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, J_CHICKENPOX_42=0.6, RP_MATCHES_RCVD=-0.272, 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 yfLJff4kDaBC for ; Wed, 9 Apr 2014 06:13:09 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id A6A971A01C1 for ; Wed, 9 Apr 2014 06:13:09 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id pa12so2058490veb.14 for ; Wed, 09 Apr 2014 06:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ol2/cMDcbtzX2AY07wYah3anWfsPclipdO56r6VP3jU=; b=jd/0YV7oV0x0Yp8HUEhmqIFMKMhAWSF9/xVFqiFh6g09GVvCzG0BzJNjQMVJRuDM8b 7pdAQZw0LW5VyEKDeBxkheSRwJVuRHnT7bLI14WB85W1wwy7JNUICFBExCGxZUz5Isyz XuJUmOsGxRVj7ga01WoLbX2TKw2JIrfPQCMVQnTMkW9/e5Oh3SRYfx1EwA8ohKNG1NCn Bitl4l9LeKT7tAZjqXXp56FFdC9DmPPi+zZmVs9nqZyPh3uRGczs+m+PTtkTcmiMOD7a I/1Hssu+S/gWjqQGlOEl32pb908EIjT2Dsloe/AbgKenaUc5a0Gnzl4CoyVQOHIULjkH os6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ol2/cMDcbtzX2AY07wYah3anWfsPclipdO56r6VP3jU=; b=iIdg/9GtGv6wzcoDUwqUlJ2MN/RIFoR0PuuVyvLdsMdERRn2gUtqBNJo05u+xJEcvq 94r2WnH//ISJgtcyAXHZx4c830+heh1jSN6ndlAubWoB3LvgPMCmV1EU6WWuRjgiszQ3 IdelXTacg9gzpt2f/hSBZmUgs8QZrKqIRfn3xrlujrWRwpxNxNDbpdvu7AKhWC+bJ5to IeDd99n4TIWXCpj2DCrrS9xbRaTeJYTL+Olx3Odru7d3bBzp1eDkejbIFLjqbx9wAuqq OImFCcyJTjz60OsnQ28ESbSGNwJwO8WNptFsFqifr3dAgQ1M5+fpt+G93tjTBz6xA3eo gimg== X-Gm-Message-State: ALoCoQmr876kMBMRGkBOgvU66i/FP/0If1QJIzbCddtHUF36sOPHkPTzlstD0D69wdYe6HBAXy6Toxm6ub9NerE0fzIU2Mm82NtSrRdPC5wRk6ndolvTKky6IhWw0FlbhGnKipjajcKGMCbHQQ5eKbLS3T1v+VvHeJTQgXF07TLF0G1KAJQaHs1o2sQBVdcjOWZwARLVMjvs MIME-Version: 1.0 X-Received: by 10.52.249.105 with SMTP id yt9mr450422vdc.34.1397049188968; Wed, 09 Apr 2014 06:13:08 -0700 (PDT) Received: by 10.52.119.179 with HTTP; Wed, 9 Apr 2014 06:13:08 -0700 (PDT) In-Reply-To: References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188BB@USMBX1.msg.corp.akamai.com> Date: Wed, 9 Apr 2014 14:13:08 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/TonVaduqubyEfjbTP_zxHLcUi7A Cc: "trans@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [Trans] draft-iab-crypto-alg-agility-00 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, 09 Apr 2014 13:13:13 -0000 On 9 April 2014 01:49, Phillip Hallam-Baker wrote: > Since TRANS is joined to X.509 at the hip, how about we just shovel > all the metadata describing the configuration of the notary into the > certificate that signs the notary log outputs periodically? I guess if you are a CA everything looks like a certificate. Currently, logs do not use certificates to manage their own keys. I guess they could. But I thought you preferred JSON for new stuff? > I am assuming here that the signing hierarchy for the log has an > offline key that periodically signs the online key. Again, currently, no. Seems to me that you can introduce a lot of complication this way not needed for the only known client use case (deployment in Chrome). Not against specifying it, to be clear, but unsure it should live in the same doc. Or hold it up. > The cert for the > online key can specify the notary algorithm by OID (its ASN.1 after > all) and any other parameters that might be useful. Probably want to > allow for different accumulation strategies in case we ever decide a > binary tree isn't the only choice. Might have some other options. > Might want to be able to specify the CPS/CP equivalents for the > notary, etc. > > > > On Tue, Apr 8, 2014 at 10:28 AM, Dmitry Belyavsky wrote: >> Hello Ben, >> >> >> On Tue, Apr 8, 2014 at 6:21 PM, Ben Laurie wrote: >>> >>> On 8 April 2014 15:18, Salz, Rich wrote: >>> >> > I do not understand why metadata is more secure then the data itself. >>> > >>> >> It is created by a different authority. >>> > >>> > ? Is this in the part of the RFC that is still TBD? >>> >>> The RFC describes how logs work and how clients work. It does not >>> describe how clients decide what logs they are prepared to accept. I >>> am not sure it should. >>> >>> But whoever does also decides whether the algorithms in use by the >>> logs are acceptable and tells the client what those algorithms are >>> (along with other things, like the log's key, base URL and MMD). >>> >> I think that the client should be able to find out the algorithm used by log >> because it cant'be changed during the log lifetime. And if the RFC specifies >> the URIs for certificate submit, it seems to me that it's reasonable to >> specify the URI for finding out the algorithm. But I prefer to leave out of >> band of the protocol only the data that can't be passed using it. >> >> Thank you! >> >> -- >> SY, Dmitry Belyavsky >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> > > > > -- > Website: http://hallambaker.com/ -- Certificate Transparency is hiring! Let me know if you're interested. From nobody Thu Apr 10 17:55: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 247FB1A03A7; Thu, 10 Apr 2014 17:55:16 -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 SkwAU1FyMcZ3; Thu, 10 Apr 2014 17:55:08 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 10A911A03A1; Thu, 10 Apr 2014 17:55:06 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id q8so2939680lbi.14 for ; Thu, 10 Apr 2014 17:55:05 -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=AKmOZQDPIFme3IxhVEhUPT8JOKQREuw4RSbU4ocv1q8=; b=jtSv0+Oqt9sM+gwBiF84azkZr2s0PQLQAxXr72OkO3Mkm530TPYbBYp1BxKWolpeUP RPoW9STdjPZkouwVMClwvXbxZSBSNuh+/PADDmgvpjQd3i6iXwsAI0GjCXId2BSjkVHm m6Nl7WtnCQG8zISpdMp8a+WlaTp1/F2R0UrI2m5s3YNkQrREYM/K6U23VNgYRnR4B4mm 9GF9Dr/VrkQbysWMPAmTM0HSi5WTjlakAGbyC6PfFy8O1qsuKgLxsN/lRH22ce4o4ymQ i+anLIaDi/Vh4Nqm/UnhZS0o0lCYbmmW8VRG+TQpWnwsjiktnI3i7Z9qAcJj6ZnswZ2g p3gA== MIME-Version: 1.0 X-Received: by 10.112.201.1 with SMTP id jw1mr4805lbc.47.1397177705193; Thu, 10 Apr 2014 17:55:05 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Thu, 10 Apr 2014 17:55:04 -0700 (PDT) In-Reply-To: References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188BB@USMBX1.msg.corp.akamai.com> Date: Thu, 10 Apr 2014 20:55:04 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/dCBuea_H-IpFex1_PIjuE65CQfM Cc: "trans@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [Trans] draft-iab-crypto-alg-agility-00 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, 11 Apr 2014 00:55:18 -0000 On Wed, Apr 9, 2014 at 9:13 AM, Ben Laurie wrote: > On 9 April 2014 01:49, Phillip Hallam-Baker wrote: >> Since TRANS is joined to X.509 at the hip, how about we just shovel >> all the metadata describing the configuration of the notary into the >> certificate that signs the notary log outputs periodically? > > I guess if you are a CA everything looks like a certificate. > Currently, logs do not use certificates to manage their own keys. I > guess they could. But I thought you preferred JSON for new stuff? I do, but I also prefer to avoid long discussions that I don't think I am going to win. As a general matter, most mechanisms that manage keys are likely to generate X.509v3 certificates or CRSs as a by product. Even some of the DNSSEC stuff generates them. >> I am assuming here that the signing hierarchy for the log has an >> offline key that periodically signs the online key. > > Again, currently, no. Seems to me that you can introduce a lot of > complication this way not needed for the only known client use case > (deployment in Chrome). Not against specifying it, to be clear, but > unsure it should live in the same doc. Or hold it up. I tend to think that anyone who would check cert status against TRANS is already doing X.509v3 and bar -- Website: http://hallambaker.com/ From nobody Fri Apr 11 05:21: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 05E431A0689 for ; Fri, 11 Apr 2014 05:21:16 -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 BHLuThNypZVx for ; Fri, 11 Apr 2014 05:21:11 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0291A0235 for ; Fri, 11 Apr 2014 05:21:11 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id b8so3457891lan.12 for ; Fri, 11 Apr 2014 05:21:09 -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=PcIXNGxw97/Mnu+PbI7XMZ6zPAm4ChM4trHJluvKxu4=; b=FEH4nn1w87TLrDWAjyw+ZmbHg6PUzYxa/WI2EXb00jJ4aMXZUnfhkhKESLRw0l3eoq /YlBRdBjN8blxibGHBhyDeDuvxHWyxfuvI97lYx/VskrlsMLAiE78OP1GLO1iVWvPsZQ JfFngawRkzuRjlRfouwmt0CnEzYFpTTXBafIIauvyXZDYA/+x+REAnH4aRLYkvMKWAA/ cxYectVtep1meQrrcdmqj+KwrWIZAEGZ9HRU1DR9Vz4TDeJpE7oVgmGjft4KidS3aiPM dO+s/lTp9ZgYoAcbauhekm2vRQQZMUtorcySNqAxQ3dQNqHs7p1yZ0wqpAvGz2kakObb m+Rw== MIME-Version: 1.0 X-Received: by 10.153.11.163 with SMTP id ej3mr16486019lad.17.1397218869183; Fri, 11 Apr 2014 05:21:09 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Fri, 11 Apr 2014 05:21:09 -0700 (PDT) Date: Fri, 11 Apr 2014 08:21:09 -0400 Message-ID: From: Phillip Hallam-Baker To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/qjsw3Xlpq2_H9MtVFjgBFyg7eBA Subject: [saag] The real Heartbleed problem 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, 11 Apr 2014 12:21:16 -0000 Right now we have two billion users being told to 'change their passwords' and it will do them absolutely no good because virtually none of the servers they are contacting with their new password will have been updated. The fundamental problem here is that we are using disclosure of bearer tokens as authentication. Passwords and cookies are both terrible ways to authenticate users. There are two parts to this problem, one of them is to get a password validation mechanism into HTML that does not disclose the password to the other side. The other is how to gradually end use of cookies for authentication. The way to do that is to offer an extension to cookies that allows a server to offer a challenge-response option to the client. If the client supports this option it will only present a proof of knowledge of the authentication secret and not the authentication secret itself. Combined with appropriate defenses against replay attacks, and TLS channel binding this can be made a very solid approach. But we are not going to get good security if people are relying on transport layer encryption to secure passwords. https://datatracker.ietf.org/doc/draft-hallambaker-httpsession/ -- Website: http://hallambaker.com/ From nobody Fri Apr 11 16:32: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 1C8241A0392 for ; Fri, 11 Apr 2014 16:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.002 X-Spam-Level: * X-Spam-Status: No, score=1.002 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_SORBS_WEB=0.77, 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 n4ALjY8_f2y1 for ; Fri, 11 Apr 2014 16:32:48 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id E13EA1A031C for ; Fri, 11 Apr 2014 16:32:47 -0700 (PDT) Received: (qmail 2428 invoked by uid 0); 11 Apr 2014 23:31:46 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 11 Apr 2014 23:31:46 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id onXi1n00B2UhLwi01nXlSL; Fri, 11 Apr 2014 17:31:46 -0600 X-Authority-Analysis: v=2.1 cv=Z7h/QhhA c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=4eyjf-e663kA:10 a=5UR0B8QLj74A:10 a=3NT3xRclEPMA:10 a=8nJEP1OIZ-IA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=vS7MmSmxvPQA:10 a=SSmOFEACAAAA:8 a=6rXeCiQDAAAA:8 a=EtqJSZqBLC4nNmsnK9kA:9 a=wPNLvfGTeEIA:10 a=24ooLvx-mQYA:10 a=caEdRzTV6MIA:10 a=69XIa8IdTDMA:10 a=-Fbca3v37V8A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=zT4ZoVywBwpjN9QH7O12ufX3Qvn9j/I/K8lEtecrtrg=; b=1awEmXgMlYe7LJVTm8kBBWvQb4+NGdwZzbyytq25QXrrnF8jN760KLz1kMQ5MBHQ1EP5NN5SSUv6Dfv/ypnwHSY1GYVG4rhzNwsy3RgZ9JlO6MxIepgvn0QzY/hKsRtS; Received: from [216.113.168.128] (port=44756 helo=[10.244.137.220]) by box514.bluehost.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WYkv8-0006BI-2J for saag@ietf.org; Fri, 11 Apr 2014 17:31:42 -0600 Message-ID: <53487B5D.8030705@KingsMountain.com> Date: Fri, 11 Apr 2014 16:31:41 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: IETF Security Area Advisory Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4A_bvB7D25E6cqh5zDjCR729ZYo Subject: [saag] fwd: Last Call for Web Crypto API (W3C) 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, 11 Apr 2014 23:32:49 -0000 comments on the below can be sent to (one likely needs to subscribe in order you post) Subject: Last Call for Web Crypto API From: GALINDO Virginie Date: Tue, 25 Mar 2014 16:36:39 +0100 To: "chairs@w3.org" Cc: "public-webcrypto@w3.org" Dear all, The Web Crypto Working Group has published a Last Call working draft of the Web Crypto API specification today, 25th March 2014 [1] and requests review comments from the following groups : Web Applications WG, HTML WG, Web App Sec and TAG. We are also interested in comments from others, obviously. The draft is available here : http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/ The working group believes that the current document answers the requirements expressed as primary features in the Web Crypto WG charter [2]. No formal objection has been raised and no patent disclosure has been made [3]. As a reminder this specification abstract is : This specification describes a JavaScript API for performing basic cryptographic operations in web applications, such as hashing, signature generation and verification, and encryption and decryption. Additionally, it describes an API for applications to generate and/or manage the keying material necessary to perform these operations. Uses for this API range from user or service authentication, document or code signing, and the confidentiality and integrity of communications. We are currently debating the best way to manage JWK keys and expecting specific comments on that from you and developers community. 3 issues are still open, but might not impact our fulfill requirements of the charter, see http://www.w3.org/2012/webcrypto/track/issues/open. The Last Call period ends 20 of May 2014 (8 weeks) - please send comments to the Web Crypto WG public mailing list public-webcrypto-comments@w3.org with "[last call feedback]" at the start of the Subject line. Thanks, Virginie Galindo Chair of the Web Crypto WG Gemalto [1] Minutes of the call where Last Call was decided http://www.w3.org/2014/03/10-crypto-minutes.html [2] W3C Web Crypto WG charter http://www.w3.org/2011/11/webcryptography-charter.html [3] http://www.w3.org/2004/01/pp-impl/54174/status From nobody Mon Apr 14 06:57: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 828811A043C for ; Mon, 14 Apr 2014 06:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 FLGNsiQBxT90 for ; Mon, 14 Apr 2014 06:57:28 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF1E1A02F6 for ; Mon, 14 Apr 2014 06:57:28 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38175 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WZhO1-0007bR-CM for saag@ietf.org; Mon, 14 Apr 2014 09:57:25 -0400 Message-ID: <534BE945.5070306@bbn.com> Date: Mon, 14 Apr 2014 09:57:25 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: 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/EW3OgK4lrFr3H2_2jyN9nHYHxBU Subject: Re: [saag] The floor on OS (Re: new terminology ID posted) 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, 14 Apr 2014 13:57:32 -0000 Nico, > On Mon, Apr 7, 2014 at 2:09 PM, Nico Williams wrote: >> On Mon, Apr 7, 2014 at 9:14 AM, Stephen Kent wrote: >>> I was not asking for a consensus call, yet. And, even if I were, the >>> issue is not whether DANE-enabled TLS is good or bad (I think it';s >>> very good) but whether it will be included in a definition of OS. >> OK, so let's define OS. My definition: >> >> You get the strongest security in the Internet threat model that >> can be obtained, and you get as strong a floor on security in the >> Internet threat model as that which you can securely discover, else >> the floor may be as low as protection only against passive attacks. you have my feedback on that definition in my previous reply. > It's hard to overstate the importance of having the floor strength be > variable _and_ that when the floor is strong you have no fallback on > weaker levels of security. So, new thread. another not easy to comprehend comment ... > Floors: > > - no security whatsoever (everything sent in cleartext); > > - unauthenticated key exchange (note that RSA key transport can do > this), which obtains protection against passive attackers; > > It goes without saying that keys are exchanged so they can be used > for authenticated encryption and possibly for channel binding (or > other MITM detection schemes), so I won't repeat this below. > > - unauthenticated key exchange w/ TOFU/LoF/TACK/pinning, which > obtains protection against passive attackers and forces MITMs to > remain in the middle for longer than they might be prepared, willing, > or able to; > > There is the risk that forcing a capable MITM to always be in the > middle causes further disclosures to them. But having fallen victim > to an MITM once this seems like a small additional risk. > > - authenticated key exchange. > > Authentication can be done in any number of ways, from DNSSEC-based to > PKI-based, to web of trust-based. If one does TOFU/LoF then on > subsequent exchanges we have a form of authenticated (pseudonymous) > key exchange. I have no objection to the ordered list of options you provide above. I don't agree that the term "pseudonymous" is appropriate above. In many (most?) TOFU/LoF contexts the asserted identity is not pseudonymous. > "Opportunistic" necessarily means that the floor that one gets might > be very low strength. But it must not mean that a fallback on > low-strength is always required. We'd be doing a great disservice to > the public if required fallback to the lowest floor in all > circumstances! I would not suggest fallback to the lowest floor as a goal, but rather recognize it as a possible outcome depending on the context. > We must allow for discovery of floor strength for specific peers. that's nice, but if discovery adds to RTTs, it's not a good prerequisite. I think > TOFU/LoF, TACK, pinning -- these are technologies for setting the > floor in the future to be no lower than today (modulo expiration, > ...). > > PKI (DNSSEC or x.509/PKIX) is a technology for discovering the lowest > floor in the present. > > DNSSEC/DANE in particular is a technology for out-of-band high floor > discovery, which therefore strongly indicates that fallback on lower > strength floors should be NOT permitted. > > DNSSEC is a PKI of sorts however, with all the problems that that > implies. This is a reason to expect some pushback on DNSSEC-based > solutions. If one does not trust the DNSSEC PKI then either one must > not use DANE or one must require the use of other technologies (e.g., > TOFU/LoF) in addition to DANE to add a measure of security. > > Allowing the floor to rise as possible -and to stay strong- is critical. > > Aside #1: Channel binding is no help if there's not a separate, > higher-layer authentication mechanism to take advantage of it. > > Aside #2: Any technology that requires persistent local storage (e.g., > TOFU/LoF, TACK/pinning) may fail to be usable on highly constrained > devices, but that's very much a side issue. Mobile devices today have > plenty of persistent storage. Embedded devices mostly don't really > need to speak to potentially any peer on the Internet, so PSK or > similar are generally good enough for them. > > Nico > -- > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Mon Apr 14 06:57: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 55B3B1A0476 for ; Mon, 14 Apr 2014 06:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 qJupzmAq254f for ; Mon, 14 Apr 2014 06:57:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 19DBF1A0466 for ; Mon, 14 Apr 2014 06:57:36 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49945 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WZhOH-0009wg-Rp; Mon, 14 Apr 2014 09:57:41 -0400 Message-ID: <534BE94C.2070606@bbn.com> Date: Mon, 14 Apr 2014 09:57:32 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nico Williams References: 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/CyW9AZB9XMowDcLcCxaKbbX-yKg Cc: "saag@ietf.org" Subject: Re: [saag] OS is generic (Re: new terminology ID posted) 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, 14 Apr 2014 13:57:37 -0000 Nico, Sorry if I was unclear. I didn't mean to suggest that changes to existing protocols ought not qualify for the OS term. I am not suggesting that only blank slate approaches should qualify as OS. I did mean to suggest that the term not be applied retroactively to existing protocols. For example, wow that I realize that Viktor was focusing on his draft for opportunistic use of DANE with TLS I agree that it should be considered as an OS candidate. Steve P.S. A 'generic" concept of OS seems orthogonal to the new vs. existing discussion. However, we do need to discuss whether we will adopt a very vague, goal-oriented definition for OS, or one with a specific set of characteristics. I plan to initiate a discussion on that today. From nobody Mon Apr 14 06:57: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 8A2E11A0489 for ; Mon, 14 Apr 2014 06:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 qHBt0Fh2_Ody for ; Mon, 14 Apr 2014 06:57:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6351A0466 for ; Mon, 14 Apr 2014 06:57:39 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38177 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WZhOC-0007bf-W2 for saag@ietf.org; Mon, 14 Apr 2014 09:57:37 -0400 Message-ID: <534BE950.3070809@bbn.com> Date: Mon, 14 Apr 2014 09:57:36 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <533AE246.9080806@bbn.com> <20140401163654.GD12559@mournblade.imrryr.org> <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <5342B454.1050607@bbn.com> <20140407150834.GW12559@mournblade.imrryr.org> <5342EF73.5070903@bbn.com> <20140407203658.GE12559@mournblade.imrryr.org> <53444C89.4040502@bbn.com> <20140408212304.GO12559@mournblade.imrryr.org> In-Reply-To: <20140408212304.GO12559@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/iPplNNLxcwqVTcksgBGYFiXpgUo Subject: Re: [saag] new terminology ID posted 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, 14 Apr 2014 13:57:41 -0000 Viktor, > ... > I am not asking you to classify RFC 6698 DANE as OS. Rather, I'm > asking you leave room for opportunistic variants of RFC 6698 such > as: > > http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane > > Opportunistic DANE TLS is a protocol in which (for now SMTP) clients > employ as strong as possible security with each (SMTP) server. > This subsumes cleartext for servers that neither publish TLSA > records nor offer STARTTLS (or some MITM downgraded their EHLO > response). It also subsumes opportunitic unauthenticated TLS when > no TLSA records are found, but STARTTLS is available. It also > subsumes mandatory unauthenticated TLS when TLSA records exist, > but none are usable, ... I understand, now. Sorry for the confusion. > >> But, as you noted, if one employs authenticated cipher suites plus >> DH (ECDH) one can still achieve PFS. > Across all TLSA record types, the TLSA record does not select the > TLS key exchange mechanism. It can be PFS or RSA key transport if > the keys happen to be RSA keys, but even RSA keys work with PFS. You are correct. But, I suspect that most folks reading 6698 interpret it relative to the most common practice for TLS, in which RSA is used for key transport. If one conveys an EE cert via a TLSA record, I think most folks would not expect that cert to be used for auth and NOT key transport, even though that use case is covered by TLS. Anyway, I was confused by which doc we were debating. My bad. And, you are correct that TLSA records do not, strictly speaking, dictate the cipher suite used with TLS, so PFS is not incompatible with use of DANE. Steve From nobody Mon Apr 14 06:57: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 C23221A02F7 for ; Mon, 14 Apr 2014 06:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 9pc0pIfqyFcW for ; Mon, 14 Apr 2014 06:57:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id BC7D91A0466 for ; Mon, 14 Apr 2014 06:57:42 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38178 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WZhOG-0007bm-9D for saag@ietf.org; Mon, 14 Apr 2014 09:57:40 -0400 Message-ID: <534BE954.9040209@bbn.com> Date: Mon, 14 Apr 2014 09:57:40 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/9UP_6JcBjIZW4wis_fJx0WavuOM Subject: [saag] draft-kent-opportunistic-security-01.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, 14 Apr 2014 13:57:44 -0000 The newly posted version of my I-D reflects changes made in response to Tero's comments, but does not address the more recent set of comments about how proscriptive the definition of OS should be. Steve From nobody Mon Apr 14 08: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 976571A02CF for ; Mon, 14 Apr 2014 08:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 NlMpGAHfMXNT for ; Mon, 14 Apr 2014 08:40:14 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id DA3441A04E8 for ; Mon, 14 Apr 2014 08:40:13 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 054D22AAF85; Mon, 14 Apr 2014 15:40:09 +0000 (UTC) Date: Mon, 14 Apr 2014 15:40:09 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140414154009.GG18879@mournblade.imrryr.org> References: <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <5342B454.1050607@bbn.com> <20140407150834.GW12559@mournblade.imrryr.org> <5342EF73.5070903@bbn.com> <20140407203658.GE12559@mournblade.imrryr.org> <53444C89.4040502@bbn.com> <20140408212304.GO12559@mournblade.imrryr.org> <534BE950.3070809@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534BE950.3070809@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HtHVKTLSPx0jbfw3p9nlugwg5Gk Subject: Re: [saag] new terminology ID posted 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, 14 Apr 2014 15:40:18 -0000 On Mon, Apr 14, 2014 at 09:57:36AM -0400, Stephen Kent wrote: > >Opportunistic DANE TLS is a protocol in which (for now SMTP) clients > >employ as strong as possible security with each (SMTP) server. > >This subsumes cleartext for servers that neither publish TLSA > >records nor offer STARTTLS (or some MITM downgraded their EHLO > >response). It also subsumes opportunistic unauthenticated TLS when > >no TLSA records are found, but STARTTLS is available. It also > >subsumes mandatory unauthenticated TLS when TLSA records exist, > >but none are usable, ... > > I understand, now. Sorry for the confusion. Thanks. Much appreciated, glad to get this part out of the way. > >Across all TLSA record types, the TLSA record does not select the > >TLS key exchange mechanism. It can be PFS or RSA key transport if > >the keys happen to be RSA keys, but even RSA keys work with PFS. > > You are correct. But, I suspect that most folks reading 6698 interpret > it relative to the most common practice for TLS, in which RSA is used > for key transport. I am not sure whether it is still correct to say that we expect RSA key transport for RSA keys. PFS with RSA keys is increasingly more common. Here is a frequency count of ciphers from a maillog file: ------------------------------------------------------------------------- count OpenSSL cipher name and bits PFS or RSA key transport? ------------------------------------------------------------------------- 7399 AECDH-AES256-SHA (256 bits) PFS 5548 ECDHE-RSA-AES256-SHA (256 bits) PFS 1410 ADH-CAMELLIA256-SHA (256 bits) PFS 1173 ECDHE-RSA-RC4-SHA (128 bits) PFS 991 DHE-RSA-AES256-SHA (256 bits) PFS 354 ADH-AES256-SHA (256 bits) PFS 229 AES128-SHA (128 bits) RSA 209 AES256-SHA (256 bits) RSA 73 ECDHE-RSA-AES128-SHA (128 bits) PFS 39 DHE-RSA-AES128-SHA (128 bits) PFS 32 RC4-SHA (128 bits) RSA 22 DHE-RSA-CAMELLIA256-SHA (256 bits) PFS 7 RC4-MD5 (128 bits) RSA 1 EDH-RSA-DES-CBC3-SHA (168 bits) PFS ------------------------------------------------------------------------- TOTAL: ------------------------------------------------------------------------- 17010 PFS 477 RSA So for my domain's SMTP server, which has an RSA key, the current mail log file had only ~500 non-PFS connections out of ~17500 total. So RSA key transport is rather the exception on this SMTP server, despite its RSA key. I expect that other PFS-capable MTAs observe similar usage patterns. Perhaps with HTTPS RSA key transport is still used more frequently, but this is changing I believe: http://www.netcraft.com/internet-data-mining/ssl-survey/ Perfect Forward Secrecy (PFS) provides a defence against the compromise of the private key corresponding to an SSL certificate. If an SSL web server uses a PFS cipher suite, the secret keys used to encrypt historical TLS sessions are not revealed even if the long-term private key is compromised. In the news in 2013, usage of PFS in August 2013 was not particularly widespread: around one third of SSL sites negotiated a cipher suite with the PFS property and a further 28% of SSL servers are capable of PFS, but actively avoid using PFS cipher suites. That was in August, the picture is probably already quite different, though I don't know whether PFS as yet accounts for more than 50% (by whatever metric is employed). -- Viktor. From nobody Mon Apr 14 12:20: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 793B11A06A3 for ; Mon, 14 Apr 2014 12:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 QHT9RLcH0Kb3 for ; Mon, 14 Apr 2014 12:19:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7991A02E9 for ; Mon, 14 Apr 2014 12:19:59 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38660 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WZmQ8-000EsP-42 for saag@ietf.org; Mon, 14 Apr 2014 15:19:56 -0400 Message-ID: <534C34DB.8020604@bbn.com> Date: Mon, 14 Apr 2014 15:19:55 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag Content-Type: multipart/alternative; boundary="------------090505060507000809020108" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/GoRfSFKEYu-ZOf3p_ouwB54rRRQ Subject: [saag] OS features/requirements analysis 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, 14 Apr 2014 19:20:05 -0000 This is a multi-part message in MIME format. --------------090505060507000809020108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I reported that a breakout session at the STRINT workshop identified several features that should be part of opportunistic security. It has been suggested that at least one of these, PFS, ought not be mandatory. I suggest we explicitly review all of the proposed features for OS and decide which are mandatory, which are optional, and which have no place in a definition for OS. Here is the list I recall from the workshop, with a rationale for each feature: 1.OS is invisible to users, and, more broadly, to applications that initiate sessions. Rationale: Lack of visibility is considered critical, so that users do not become confused by the variability in the set of security services they are being afforded. An application that has not mandated explicit use of security protocol benefits from opportunistic security, but OUGHT NOT [RFC6919] make decisions on how to behave based on the success or failure of OS mechanisms. 2.Opportunistic security is not intended to be a substitute for authenticated, integrity-protected encryption when that set of security services can be provided to a user. Rationale: This is linked to #1 above. If a user can establish a server-authenticated TLS session with a financial institution today, the user should continue to do so.This requires that users (applications) MUST still be able to explicitly invoke security protocols, and suggests that OS is not explicitly invoked. 3.Opportunistic security SHOULD (?) make use of key agreement (vs. key transport) and employ perfect forward secrecy (PFS). Rationale: Key agreement (e.g., Diffie-Hellman or ECDH) is preferred over key transport because it can be effected without adding round trips to a protocol. Key agreement also is preferred because it readily supports PFS, if ephemeral keys are employed. In turn, PFS is desired because it affords protection against a range of attacks that go beyond simple, passive wiretapping.The recently noted "heartbleed" attack is capable of extracting keys from a server or client using TLS. If no long term private/secret keys are employed by OS, then an attack of this sort is limited in its impact. 4.Crypto-based authentication is a desired, but not mandatory, feature. Rationale: Authentication of the encrypted channel is desirable because it offers protection against a range of active attacks, including MiTM, that could cause a user to communicate with a party impersonating the intended communication target. Some security protocols mandate two-way crypto-based authentication, by default, e.g., IKE. TLS [RFC5246] and SSH [RFC4253] typically make use of 1-way (server-based) crypto-based authentication, although they also support client-based channel authentication. (Both Web PKI certificates and DANE TLSA records [RFC6698] are viewed as acceptable forms of cryptographic-based authentication.) Because the success or failure of opportunistic security is not to be signaled to the initiator of a session, the user will not know whether the target of the session has been authenticated. 5.Detection of a man-in-the-middle (MiTM) attacks is a desired, but not mandatory, feature. Rationale: If crypto-based authentication is successful, it provides detection of a MiTM attack (subject to the veracity of the credentials employed.) However, even if such authentication cannot be achieved, it may still be possible to detect a MiTM.MiTM detection is considered a lower priority than authentication, and is to be pursued only if the former security service is not available (or fails). Again, if a MiTM is detected, this event is NOT signaled to the user/application. 6.In some contexts, human-perceptible delays in session/connection establishment might discourage use of OS.In such contexts,authentication and MiTM detection SHOULD take place after an encrypted channel has been established.This ordering implies that some data may be transmitted prior to authentication or detection of a MiTM.In a context where delays imposed by performing authentication are not considered onerous, authentication MAY be attempted prior to enabling transmission.In such contexts all application traffic will be afforded authentication (and, typically, integrity) if available. Rationale: The first sentence provides the rationale, i.e., we don't want delays imposed by authentication (or MiTM detection) to deter use of OS. 7. An attempt to create an opportunistically securemay fail, resulting in plaintext communication. Rationale: OS usually will require changes to existing protocols, or development of new protocols. Thus an attempt to establish an OS-based session, may fail, because the target of the session does not support OS. Thus, until OS is universally adopted, an attempt to execute opportunistic security may result in plaintext communication.Since an attempt to use opportunistic security is not communicated to users or applications, falling back to the status quo, i.e., plaintext communication, is a reasonable strategy. --------------090505060507000809020108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

I reported that a breakout session at the STRINT workshop identified several features that should be part of opportunistic security. It has been suggested that at least one of these, PFS, ought not be mandatory. I suggest we explicitly review all of the proposed features for OS and decide which are mandatory, which are optional, and which have no place in a definition for OS.

 

Here is the list I recall from the workshop, with a rationale for each feature:

 

 

1.     OS is invisible to users, and, more broadly, to applications that

       initiate sessions. 

 

Rationale: Lack of visibility is considered critical, so that users do not become confused by the variability in the set of security services they are being afforded. An application that has not mandated explicit use of security protocol benefits from opportunistic security, but OUGHT NOT [RFC6919] make decisions on how to behave based on the success or failure of OS mechanisms.

 

2.  Opportunistic security is not intended to be a substitute for

    authenticated, integrity-protected encryption when that set of

    security services can be provided to a user. 

 

Rationale: This is linked to #1 above. If a user can establish a server-authenticated TLS session with a financial institution today, the user should continue to do so.  This requires that users (applications) MUST still be able to explicitly invoke security protocols, and suggests that OS is not explicitly invoked.

 

 

3.  Opportunistic security SHOULD (?) make use of key agreement (vs. key transport) and employ perfect forward secrecy (PFS).

 

Rationale: Key agreement (e.g., Diffie-Hellman or ECDH) is preferred over key transport because it can be effected without adding round trips to a protocol. Key agreement also is preferred because it readily supports PFS, if ephemeral keys are employed. In turn, PFS is desired because it affords protection against a range of attacks that go beyond simple, passive wiretapping.  The recently noted “heartbleed” attack is capable of extracting keys from a server or client using TLS. If no long term private/secret keys are employed by OS, then an attack of this sort is limited in its impact.

 

 

4.  Crypto-based authentication is a desired, but not mandatory,

    feature.

 

Rationale: Authentication of the encrypted channel is desirable because it offers protection against a range of active attacks, including MiTM, that could cause a user to communicate with a party impersonating the intended communication target. Some security protocols mandate two-way crypto-based authentication, by default, e.g., IKE. TLS [RFC5246] and SSH [RFC4253] typically make use of 1-way (server-based) crypto-based authentication, although they also support client-based channel authentication. (Both Web PKI certificates and DANE TLSA records [RFC6698] are viewed as acceptable forms of cryptographic-based authentication.) Because the  success or failure of opportunistic security is not to be signaled to the initiator of a session, the user will not know whether the target of the session has been authenticated. 

 

5.  Detection of a man-in-the-middle (MiTM) attacks is a desired, but not mandatory, feature. 

 

Rationale: If crypto-based authentication is successful, it provides detection of a MiTM attack (subject to the veracity of the credentials employed.) However, even if such authentication cannot be achieved, it may still be possible to detect a MiTM.  MiTM detection is considered a lower priority than authentication, and is to be pursued only if the former security service is not available (or fails). Again, if a MiTM is detected, this event is NOT signaled to the user/application.

 

6.  In some contexts, human-perceptible delays in session/connection

establishment might discourage use of OS.  In such contexts,      authentication and MiTM detection SHOULD take place after an encrypted channel has been established.  This ordering implies that some data may be transmitted prior to authentication or detection of a MiTM.  In a context where delays imposed by performing authentication are not considered onerous, authentication MAY be attempted prior to enabling transmission.  In such contexts all application traffic will be afforded authentication (and, typically, integrity) if available.

 

Rationale: The first sentence provides the rationale, i.e., we don’t want delays imposed by authentication (or MiTM detection) to deter use of OS.

 

 

7. An attempt to create an opportunistically secure  may fail, resulting in plaintext communication.

 

Rationale: OS usually will require changes to existing protocols, or development of new protocols. Thus an attempt to establish an OS-based session, may fail, because the target of the session does not support OS.

Thus, until OS is universally adopted, an attempt to execute opportunistic

security may result in plaintext communication.  Since an attempt to use opportunistic security is not communicated to users or applications, falling back to the status quo, i.e., plaintext communication, is a reasonable strategy.

 

--------------090505060507000809020108-- From nobody Mon Apr 14 12:36: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 D9F901A0700 for ; Mon, 14 Apr 2014 12:36:53 -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_44=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 TfCGLdXOsPbT for ; Mon, 14 Apr 2014 12:36:52 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9D63F1A0666 for ; Mon, 14 Apr 2014 12:36:52 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 092A82AAF85; Mon, 14 Apr 2014 19:36:49 +0000 (UTC) Date: Mon, 14 Apr 2014 19:36:48 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140414193648.GK18879@mournblade.imrryr.org> References: <534C34DB.8020604@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534C34DB.8020604@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/g6MNdq9_CJmvoiZLl_SUpUSNyXM Subject: Re: [saag] OS features/requirements analysis 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, 14 Apr 2014 19:36:54 -0000 On Mon, Apr 14, 2014 at 03:19:55PM -0400, Stephen Kent wrote: > I reported that a breakout session at the STRINT workshop identified several > features that should be part of opportunistic security. It has been > suggested that at least one of these, PFS, ought not be mandatory. I suggest > we explicitly review all of the proposed features for OS and decide which > are mandatory, which are optional, and which have no place in a definition > for OS. My take is that we need a more precise definition of "mandatory". - Mandatory to implement? - Mandatory to prefer? - Mandatory to use (negotiate)? At least with PFS, one might reasonably argue for the first two, but requiring PFS use seems rather contrary to the "opportunistic" mind-set of doing the best you can. If the peer only offers RSA key transport, then that's what you go with. The peer's configuration is then not marketable as fully "OS" enabled. > 3. Opportunistic security SHOULD (?) make use of key agreement (vs. key > transport) and employ perfect forward secrecy (PFS). Here, I would strongly suggest that being "opportunistic" the SHOULD only covers "implementation" and "preference" for PFS, but does not imply any mandate to use PFS (or else refuse to encrypt? Really???). > 5.Detection of a man-in-the-middle (MiTM) attacks is a desired, but not > mandatory, feature. > > Rationale: If crypto-based authentication is successful, it provides > detection of a MiTM attack (subject to the veracity of the credentials > employed.) However, even if such authentication cannot be achieved, it may > still be possible to detect a MiTM.MiTM detection is considered a lower > priority than authentication, and is to be pursued only if the former > security service is not available (or fails). Again, if a MiTM is detected, > this event is NOT signaled to the user/application. The above is a bit too restrictive for "opportunistic DANE TLS", where one strives for downgrade resistance when possible, and may well signal authentication failure to the user/application. Of course the application needs to elect this mode of operation (opportunistic with DANE). -- Viktor. From nobody Tue Apr 15 07:12: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 9FCCD1A01D4 for ; Tue, 15 Apr 2014 07:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.173 X-Spam-Level: X-Spam-Status: No, score=-1.173 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 jFWSHt7bQ1eB for ; Tue, 15 Apr 2014 07:12:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id F23651A01F4 for ; Tue, 15 Apr 2014 07:12:45 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58488 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Wa46M-0000Aw-Pw for saag@ietf.org; Tue, 15 Apr 2014 10:12:42 -0400 Message-ID: <534D3E5A.4090608@bbn.com> Date: Tue, 15 Apr 2014 10:12:42 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <534C34DB.8020604@bbn.com> <20140414193648.GK18879@mournblade.imrryr.org> In-Reply-To: <20140414193648.GK18879@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/s6_ksTp9YMRaTXi4TAPL1T8XD4Q Subject: Re: [saag] OS features/requirements analysis 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, 15 Apr 2014 14:12:48 -0000 Viktor, On 4/14/14 3:36 PM, Viktor Dukhovni wrote: > ... > My take is that we need a more precise definition of "mandatory". > > - Mandatory to implement? > - Mandatory to prefer? > - Mandatory to use (negotiate)? Good question in the current environment. I'm old school IETF, so mandatory means mandatory to implement. Preferences and decisions to use are local matters. > At least with PFS, one might reasonably argue for the first two, > but requiring PFS use seems rather contrary to the "opportunistic" > mind-set of doing the best you can. If the peer only offers RSA > key transport, then that's what you go with. The peer's configuration > is then not marketable as fully "OS" enabled. > >> 3. Opportunistic security SHOULD (?) make use of key agreement (vs. key >> transport) and employ perfect forward secrecy (PFS). > Here, I would strongly suggest that being "opportunistic" the SHOULD > only covers "implementation" and "preference" for PFS, but does > not imply any mandate to use PFS (or else refuse to encrypt? Really???). Again, implementation. >> 5.Detection of a man-in-the-middle (MiTM) attacks is a desired, but not >> mandatory, feature. >> >> Rationale: If crypto-based authentication is successful, it provides >> detection of a MiTM attack (subject to the veracity of the credentials >> employed.) However, even if such authentication cannot be achieved, it may >> still be possible to detect a MiTM.MiTM detection is considered a lower >> priority than authentication, and is to be pursued only if the former >> security service is not available (or fails). Again, if a MiTM is detected, >> this event is NOT signaled to the user/application. > The above is a bit too restrictive for "opportunistic DANE TLS", > where one strives for downgrade resistance when possible, and may > well signal authentication failure to the user/application. Of > course the application needs to elect this mode of operation > (opportunistic with DANE). I think this needs to be discussed in a general context, not just for the cited example. A lot of folks seemed to feel strongly that the success or failure of opportunistic security ought bot be made visible to users/apps. Maybe they were thinking more about users than apps, and thus this feature should be tempered with that in mind. There was also a brief discussion of whether a server should be notified when a failure (authentication or MiTM detection) occurs, vs. silent acceptance on behalf of a client. Steve From nobody Tue Apr 15 07:33: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 B3B9E1A0640 for ; Tue, 15 Apr 2014 07:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 mqhxU5FlGy_D for ; Tue, 15 Apr 2014 07:33:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 25F7D1A0430 for ; Tue, 15 Apr 2014 07:33:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DE81D2AABDF; Tue, 15 Apr 2014 14:33:45 +0000 (UTC) Date: Tue, 15 Apr 2014 14:33:45 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140415143345.GN18879@mournblade.imrryr.org> References: <534C34DB.8020604@bbn.com> <20140414193648.GK18879@mournblade.imrryr.org> <534D3E5A.4090608@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534D3E5A.4090608@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/5Dt3-UJb3kn-dbkD3jOl1VKOZFk Subject: Re: [saag] OS features/requirements analysis 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, 15 Apr 2014 14:33:50 -0000 On Tue, Apr 15, 2014 at 10:12:42AM -0400, Stephen Kent wrote: > >My take is that we need a more precise definition of "mandatory". > > > > - Mandatory to implement? > > - Mandatory to prefer? > > - Mandatory to use (negotiate)? > > Good question in the current environment. > I'm old school IETF, so mandatory means mandatory to implement. > Preferences and decisions to use are local matters. Thanks for the clarification. In that case, at least for TLS, the issue is largely moot. All actively maintained TLS toolkits *implement* PFS key exchange. In the case of OpenSSL, for example, the default cipher list ordering prefers ephemeral ECDH and prime DH to RSA key transport (even when the server key is an RSA key). So in that light, there is no friction between a PFS requirement for OS and opportunistic uses of TLS. To get RSA key transport, a server administrator has to intervene with a non-default cipher list setting and to impose server-side cipher preference over the default choice of the client's most preferred cipher-suite that is also supported by the server. In some cases clients offer cipher lists that suppress PFS or prefer RSA key transport. -- Viktor. From nobody Tue Apr 15 07:36: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 20EA31A06A0 for ; Tue, 15 Apr 2014 07:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 hoX8EJVq9X0N for ; Tue, 15 Apr 2014 07:35:57 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id A03011A0640 for ; Tue, 15 Apr 2014 07:35:57 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58541 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Wa4So-0000iT-Lh for saag@ietf.org; Tue, 15 Apr 2014 10:35:54 -0400 Message-ID: <534D43CA.2000804@bbn.com> Date: Tue, 15 Apr 2014 10:35:54 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <533B0993.80001@bbn.com> <20140405212023.GF2727@localhost> <20140406033929.GQ12559@mournblade.imrryr.org> <5342B454.1050607@bbn.com> <20140407150834.GW12559@mournblade.imrryr.org> <5342EF73.5070903@bbn.com> <20140407203658.GE12559@mournblade.imrryr.org> <53444C89.4040502@bbn.com> <20140408212304.GO12559@mournblade.imrryr.org> <534BE950.3070809@bbn.com> <20140414154009.GG18879@mournblade.imrryr.org> In-Reply-To: <20140414154009.GG18879@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/R1RhUZx0z29Bd8IHcJb_3Qf92dQ Subject: Re: [saag] new terminology ID posted 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, 15 Apr 2014 14:35:59 -0000 Viktor, Thanks for the reply. > ... >>> Across all TLSA record types, the TLSA record does not select the >>> TLS key exchange mechanism. It can be PFS or RSA key transport if >>> the keys happen to be RSA keys, but even RSA keys work with PFS. >> You are correct. But, I suspect that most folks reading 6698 interpret >> it relative to the most common practice for TLS, in which RSA is used >> for key transport. > I am not sure whether it is still correct to say that we expect > RSA key transport for RSA keys. PFS using RSA keys is a poor choice wrt performance, i.e., it is much more costly (CPU cycles) to generate an ephemeral RSA key pair than to generate an ephemeral D-H key pair. Why would folks choose that option? (Or, are you saying that people are using RSA-signed certs but then using ephemeral D-H? That's a totally different matter, but understandable because certs signed using RSA are so common anyway.) As you noted, the situation may be different for HTTPS vs. use of TLS in other contexts, but I'm still surprised. But, it's great to have some real numbers! Steve From nobody Tue Apr 15 07:45: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 B59641A049A for ; Tue, 15 Apr 2014 07:45:13 -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 nkI34rvYbXSx for ; Tue, 15 Apr 2014 07:45:12 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id E48461A0454 for ; Tue, 15 Apr 2014 07:45:11 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2B2972AABDF; Tue, 15 Apr 2014 14:45:08 +0000 (UTC) Date: Tue, 15 Apr 2014 14:45:08 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140415144507.GO18879@mournblade.imrryr.org> References: <20140406033929.GQ12559@mournblade.imrryr.org> <5342B454.1050607@bbn.com> <20140407150834.GW12559@mournblade.imrryr.org> <5342EF73.5070903@bbn.com> <20140407203658.GE12559@mournblade.imrryr.org> <53444C89.4040502@bbn.com> <20140408212304.GO12559@mournblade.imrryr.org> <534BE950.3070809@bbn.com> <20140414154009.GG18879@mournblade.imrryr.org> <534D43CA.2000804@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534D43CA.2000804@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/QAawlBJXNI_rIG-WEaFswJBIqFo Subject: Re: [saag] new terminology ID posted 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, 15 Apr 2014 14:45:13 -0000 On Tue, Apr 15, 2014 at 10:35:54AM -0400, Stephen Kent wrote: > >I am not sure whether it is still correct to say that we expect > >RSA key transport for RSA keys. > > PFS using RSA keys is a poor choice wrt performance, i.e., it is much > more costly (CPU cycles) to generate an ephemeral RSA key pair than > to generate an ephemeral D-H key pair. Why would folks choose that option? In TLS that's not how PFS works with RSA keys. > (Or, are you saying that people are using RSA-signed certs but then > using ephemeral D-H? That's a totally different matter, but understandable > because certs signed using RSA are so common anyway.) It goes beyond what "people are using"! Key agreement via ephemeral RSA keys is ONLY defined in the TLS RFCs with long-obsolete export cipher-suites (use RSA 1024 signing keys to sign ephemeral 512-bit export RSA keys). In TLS, the ONLY way to do RSA key transport with non-export cipher-suites is to use ECDHE or DHE signed with the RSA key. So PFS in TLS basically means ephemeral ECDH or DH. -- Viktor. From nobody Tue Apr 15 22:06: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 A5ABD1A001C for ; Tue, 15 Apr 2014 22:06:47 -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 C2jMJufG-0zy for ; Tue, 15 Apr 2014 22:06:41 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id CE8731A002F for ; Tue, 15 Apr 2014 22:06:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 508C72AAD62; Wed, 16 Apr 2014 05:06:36 +0000 (UTC) Date: Wed, 16 Apr 2014 05:06:36 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140416050636.GV18879@mournblade.imrryr.org> References: <534C34DB.8020604@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534C34DB.8020604@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/1qCNcJmPDmwGaZ9hHDrZINqaEEs Subject: Re: [saag] OS features/requirements analysis 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, 16 Apr 2014 05:06:48 -0000 On Mon, Apr 14, 2014 at 03:19:55PM -0400, Stephen Kent wrote: > Here is the list I recall from the workshop, with a rationale for each > feature: Question, is the STRINT workshop (or specifically the break-out session) a normative or informational source for this discussion? In other words, apart from using STRINT material as a potential source of good ideas, are we bound to adhere to its recommendations? > 1. OS is invisible to users, and, more broadly, to applications that > initiate sessions. Perhaps "invisible" is too strong a constraint. Minimally-intrusive may come closer to the mark. If we don't set the ceiling at protection against passive eavesdropping and allow OS mechanisms to discover stronger security policy via DANE or similar protocols, then: - When no stronger than default out of band policy is discovered, failure to encrypt or authenticate does not interrupt the application's or user's work-flow. - However, when stronger policy is discovered, failure to achieve the discovered policy level may indeed be treated in the same way as failure to achieve a-priori (non-opportunistic) strong policy. - We should perhaps not pre-judge what may or may not be confusing to users in terms of signalling the security level. This should be left to application designers. Applications may want to use passive signalling to indicate cleartext vs. unauthenticated encryption vs. authenticated encryption via some discovered policy. Such signalling via a passive UI element if designed appropriately should not be excluded by the definition of OS. The web browser is not the only possible application, it is simply the one of the most complex, and its security user-interface design is neither universal nor yet perfected. We should not assume an unauthenticated ceiling for OS. Some application protocols will admit opportunistic security policies with a broader range than merely: * cleartext, or else, when possible * unauthenticated encryption to thwart passive eavesdropping > 2.Opportunistic security is not intended to be a substitute for > authenticated, integrity-protected encryption when that set of > security services can be provided to a user. Absolutely, for example, Postfix after DANE still has PKIX support and also a new "dane-only" policy which requires DNSSEC validated TLSA RRs for destinations subject to that policy. http://www.postfix.org/TLS_README.html#client_tls_levels And per the previous comment, nor is OS necessarily unauthenticated, or vulnerable to downgrade and MiTM attacks. The key feature of OS is a spectrum of possible outcomes ranging potentially from cleartext (if the protocol or application must inter-operate with legacy cleartext-only peers) to fully authenticated encrypted sessions, with the outcome dependent on the peer's advertised capabilities. OS is adaptive, and does the best it can with each peer. This "best available" policy might be negotiated via a downgrade vulnerable protocol, (e.g. SMTP STARTTLS) or via a downgrade-resistant protocol (e.g. DANE TLSA via DNSSEC). Downgrade resistant negotiation may fail in the face of active attacks, and the application should then not simply ignore the problem, appropriate exception handling needs to be performed in that case (defer the mail, log warnings recording possible MiTM and send anyway, interact with a user via noisy dialogues, ...). In other words, just because STRINT participants did not envision downgrade-resistant opportunistic authenticated encryption, does not mean that the OS definition should exclude such protocols. Perhaps more strongly OS protocols SHOULD strive for higher security, when reasonably compatible with the application protocol. Don't *just* resist passive eavesdropping, let's deploy flexible security protocols that interoperate at multiple security levels. Initially things like the DANE for SMTP protocol will still be rare, but if we can get traction with DNSSEC and DANE, perhaps some day we can have opportunistic security that is in some ways stronger than current mandatory security mechanisms. > 3.Opportunistic security SHOULD (?) make use of key agreement (vs. key > transport) and employ perfect forward secrecy (PFS). To be less ambiguous, as discussed, we should say "implement and prefer" or some such. Actual "use" may be gated on peer capabilities, ... > 4.Crypto-based authentication is a desired, but not mandatory, > feature. May be mandatory when discovered, but exception mechanisms (log warning, prompt user, ...) may be available in some applications, just as they are for existing mandatory security policies. > 5.Detection of a man-in-the-middle (MiTM) attacks is a desired, but not > mandatory, feature. See above. > 7. An attempt to create an opportunistically secure may fail, resulting in > plaintext communication. If that's the floor for the protocol in question. If some future protocol is defined only over TLS or similar, then cleartext might be excluded, and the range may be from "unauthenticated" to "authenticated", but always encrypted. > Thus, until OS is universally adopted, an attempt to execute opportunistic > security may result in plaintext communication.Since an attempt to use > opportunistic security is not communicated to users or applications, falling > back to the status quo, i.e., plaintext communication, is a reasonable > strategy. Indeed, but "status-quo" (or more to the point least secure comms mechanism for protocol in question) is not necessarily unencrypted. I think think brings us back to Nico's suggestion to take a stable at a higher level definition of OS, not in terms of a list of properties, but in terms of a philosophy: - Universal interoperability, able to connect to all peers, even those configured for minimal to no security. Unintrusive security that broadly works, when the peer is not outright misconfigured. - Opportunistic use of available security mechanisms. Encrypt when possible, authenticate when possible, downgrade-resistant when possible, ... I tend to phrase this in the more cryptic form of "no floor, no ceiling", but that is too opaque without a detailed explanation. Nico's definition for reference/comparison: You get the strongest security in the Internet threat model that can be obtained, and you get as strong a floor on security in the Internet threat model as that which you can securely discover, else the floor may be as low as protection only against passive attacks. We're saying the same thing I think. His is more succinct than this message, I hope I've been able to clarify rather than merely repeat the idea. -- Viktor. From nobody Wed Apr 16 03:41: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 AD7F81A010B for ; Wed, 16 Apr 2014 03:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 3S_TizOVn38n for ; Wed, 16 Apr 2014 03:41:06 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E2A071A0022 for ; Wed, 16 Apr 2014 03:41:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 71C89BE56 for ; Wed, 16 Apr 2014 11:40:59 +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 HHTXRSzGdJre for ; Wed, 16 Apr 2014 11:40:59 +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 502DFBE3E for ; Wed, 16 Apr 2014 11:40:59 +0100 (IST) Message-ID: <534E5E3C.4070608@cs.tcd.ie> Date: Wed, 16 Apr 2014 11:41:00 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <534C34DB.8020604@bbn.com> <20140416050636.GV18879@mournblade.imrryr.org> In-Reply-To: <20140416050636.GV18879@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/O5eH7GLhBWKCp1h5_Ky3kS6lx8s Subject: Re: [saag] OS features/requirements analysis 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, 16 Apr 2014 10:41:07 -0000 Hiya, On 04/16/2014 06:06 AM, Viktor Dukhovni wrote: > Question, is the STRINT workshop (or specifically the break-out > session) a normative or informational source for this discussion? Informative. > In other words, apart from using STRINT material as a potential > source of good ideas, are we bound to adhere to its recommendations? Not at all. It was a workshop. Source-of-good-ideas seems about right to me, though of course there were 100 of the usual suspects there so it was not a random source of good ideas. That could be good or bad I guess:-) But mostly good in this case I think. S. PS: Should have a -00 draft of the workshop report out later this week or over the weekend. From nobody Wed Apr 16 05:59: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 E519D1A0171 for ; Wed, 16 Apr 2014 05:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 8pxqtH8QF47A for ; Wed, 16 Apr 2014 05:59:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6FB1A0170 for ; Wed, 16 Apr 2014 05:59:23 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:36388 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WaPR2-000Ows-TV for saag@ietf.org; Wed, 16 Apr 2014 08:59:29 -0400 Message-ID: <534E7EA7.1050807@bbn.com> Date: Wed, 16 Apr 2014 08:59:19 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140406033929.GQ12559@mournblade.imrryr.org> <5342B454.1050607@bbn.com> <20140407150834.GW12559@mournblade.imrryr.org> <5342EF73.5070903@bbn.com> <20140407203658.GE12559@mournblade.imrryr.org> <53444C89.4040502@bbn.com> <20140408212304.GO12559@mournblade.imrryr.org> <534BE950.3070809@bbn.com> <20140414154009.GG18879@mournblade.imrryr.org> <534D43CA.2000804@bbn.com> <20140415144507.GO18879@mournblade.imrryr.org> In-Reply-To: <20140415144507.GO18879@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/jCZfxzSmgacylak7UH7zZg_bbwY Subject: Re: [saag] new terminology ID posted 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, 16 Apr 2014 12:59:25 -0000 Viktor, > On Tue, Apr 15, 2014 at 10:35:54AM -0400, Stephen Kent wrote: > >>> I am not sure whether it is still correct to say that we expect >>> RSA key transport for RSA keys. >> PFS using RSA keys is a poor choice wrt performance, i.e., it is much >> more costly (CPU cycles) to generate an ephemeral RSA key pair than >> to generate an ephemeral D-H key pair. Why would folks choose that option? > In TLS that's not how PFS works with RSA keys. I didn't think so, but I was confused by the terms you used. >> (Or, are you saying that people are using RSA-signed certs but then >> using ephemeral D-H? That's a totally different matter, but understandable >> because certs signed using RSA are so common anyway.) > It goes beyond what "people are using"! Key agreement via ephemeral > RSA keys is ONLY defined in the TLS RFCs with long-obsolete export > cipher-suites (use RSA 1024 signing keys to sign ephemeral 512-bit > export RSA keys). I didn't look back to those older, "exportable" cipher suites. Thanks for the reminder. > In TLS, the ONLY way to do RSA key transport > with non-export cipher-suites is to use ECDHE or DHE signed with > the RSA key. So PFS in TLS basically means ephemeral ECDH or DH. Agreed. Sorry I became confused by the terminology issue. Steve From nobody Thu Apr 17 07:17: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 20D811A02E7 for ; Thu, 17 Apr 2014 07:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 f0qA8cwD0YbE for ; Thu, 17 Apr 2014 07:17:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 76D501A02F9 for ; Thu, 17 Apr 2014 07:17:05 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:46390 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Wan7m-0007A5-Dk for saag@ietf.org; Thu, 17 Apr 2014 10:17:10 -0400 Message-ID: <534FE258.6040406@bbn.com> Date: Thu, 17 Apr 2014 10:16:56 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <534C34DB.8020604@bbn.com> <20140416050636.GV18879@mournblade.imrryr.org> In-Reply-To: <20140416050636.GV18879@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/2QhahFh8CMIL-d-D711y3iFYVa8 Subject: Re: [saag] OS features/requirements analysis 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, 17 Apr 2014 14:17:13 -0000 Viktor, >> Here is the list I recall from the workshop, with a rationale for each >> feature: > Question, is the STRINT workshop (or specifically the break-out > session) a normative or informational source for this discussion? It's informative. The workshop was not an IETF meeting, although it was sponsored by ISOC, W3C, etc. Stephen noted that there were about 100 attendees. That's true, but I don't think that's as important as the fact that the folks who developed this set of "features" included the current Sec ADs, chair of UTA, a former Sec AD, the chair of the IETF, and a few others. The workshop as a whole didn't generate or even approve of this list; it was a breakout session with the attendees noted above (and several others) that generated it. But, that set of attendees is very knowledgeable and thus the conclusions merit serious consideration. Also I just wanted to note that this set of features was not something that I invented :-). > In other words, apart from using STRINT material as a potential > source of good ideas, are we bound to adhere to its recommendations? the former. >> 1. OS is invisible to users, and, more broadly, to applications that >> initiate sessions. > Perhaps "invisible" is too strong a constraint. Minimally-intrusive > may come closer to the mark. If we don't set the ceiling at > protection against passive eavesdropping and allow OS mechanisms > to discover stronger security policy via DANE or similar protocols, > then: > > - When no stronger than default out of band policy is discovered, > failure to encrypt or authenticate does not interrupt the > application's or user's work-flow. certainly. > - However, when stronger policy is discovered, failure to > achieve the discovered policy level may indeed be treated in the > same way as failure to achieve a-priori (non-opportunistic) strong > policy. what's a policy here? Is the policy an advertised set of security capabilities, as suggested later, communicated via the DNS? > - We should perhaps not pre-judge what may or may not be confusing > to users in terms of signalling the security level. This should > be left to application designers. Applications may want to use > passive signalling to indicate cleartext vs. unauthenticated > encryption vs. authenticated encryption via some discovered policy. > Such signalling via a passive UI element if designed appropriately > should not be excluded by the definition of OS. Most app designers (present company excluded, of course) have a poor history of managing UIs wrt security, so I am not enthusiastic about the last bullet above. Also, what is "passive signalling?" > The web browser is not the only possible application, it is simply > the one of the most complex, and its security user-interface design > is neither universal nor yet perfected. agreed. > We should not assume an unauthenticated ceiling for OS. Some application > protocols will admit opportunistic security policies with a broader range > than merely: > > * cleartext, or else, when possible > * unauthenticated encryption to thwart passive eavesdropping The primary rationale provided for OS is the second bullet above. Thus having OS focus on that seems reasonable. >> 2.Opportunistic security is not intended to be a substitute for >> authenticated, integrity-protected encryption when that set of >> security services can be provided to a user. > Absolutely, for example, Postfix after DANE still has PKIX support > and also a new "dane-only" policy which requires DNSSEC validated > TLSA RRs for destinations subject to that policy. > > http://www.postfix.org/TLS_README.html#client_tls_levels > > And per the previous comment, nor is OS necessarily unauthenticated, > or vulnerable to downgrade and MiTM attacks. The key feature of > OS is a spectrum of possible outcomes ranging potentially from > cleartext (if the protocol or application must inter-operate with > legacy cleartext-only peers) to fully authenticated encrypted sessions, > with the outcome dependent on the peer's advertised capabilities. You stated an assumption at the end which is not consistent with what I have heard many folks assume, i.e., that the target of a session advertises it's security capabilities. I don't disagree that one could choose to operate this way, but it has not been an agreed-upon part of the opportunistic * discussions in general. I suspect the reason is that the more prerequisites we impose on OS, the longer it will take to deploy. > OS is adaptive, and does the best it can with each peer. This > "best available" policy might be negotiated via a downgrade vulnerable > protocol, (e.g. SMTP STARTTLS) or via a downgrade-resistant protocol > (e.g. DANE TLSA via DNSSEC). Downgrade resistant negotiation may > fail in the face of active attacks, and the application should then > not simply ignore the problem, appropriate exception handling needs > to be performed in that case (defer the mail, log warnings recording > possible MiTM and send anyway, interact with a user via noisy > dialogues, ...). If we defer an action because we have detected an active attack, a user is inconvenienced. If users are inconvenienced, they may decide that a service they didn't ask for is an annoyance, and thus they might demand that it be disabled. This potential outcome runs counter to the primary goal of increasing use of encryption. So, I think many folks have emphasized the need for an OS design that is not intrusive, i.e., essentially painless. > In other words, just because STRINT participants did not envision > downgrade-resistant opportunistic authenticated encryption, does > not mean that the OS definition should exclude such protocols. > Perhaps more strongly OS protocols SHOULD strive for higher security, > when reasonably compatible with the application protocol. A less pejorative explanation is that the participants felt that maximizing deployment of encryption was the most important goal :-). > Don't *just* resist passive eavesdropping, let's deploy flexible > security protocols that interoperate at multiple security levels. > Initially things like the DANE for SMTP protocol will still be > rare, but if we can get traction with DNSSEC and DANE, perhaps some > day we can have opportunistic security that is in some ways stronger > than current mandatory security mechanisms. Stronger? TLS, DTLS, and IPsec are very strong protocols. There are all capable of supporting PFS, and can use a variety of strong authentication mechanisms. Providing very widely deployed resistance to passive wiretapping seems to be the primary goal of OS. If authentication can be achieved, without imposing unacceptable delays, then it is a great extra feature. That's how I have heard many folks characterize OS goals. >> 3.Opportunistic security SHOULD (?) make use of key agreement (vs. key >> transport) and employ perfect forward secrecy (PFS). > To be less ambiguous, as discussed, we should say "implement and > prefer" or some such. Actual "use" may be gated on peer capabilities, > ... SHOULD captures the community-based flexibility to which you refer. If we want to say it is preferred, we just need to say that. I'll make that change in the next rev. >> 4.Crypto-based authentication is a desired, but not mandatory, >> feature. > May be mandatory when discovered, but exception mechanisms (log > warning, prompt user, ...) may be available in some applications, > just as they are for existing mandatory security policies. Again, what is meant by "discovered"? If an app performs authentication, instead of a security protocol, that is a separate topic. Maybe I am misunderstanding your intent here. > >> 5.Detection of a man-in-the-middle (MiTM) attacks is a desired, but not >> mandatory, feature. > See above. > >> 7. An attempt to create an opportunistically secure may fail, resulting in >> plaintext communication. > If that's the floor for the protocol in question. If some future protocol > is defined only over TLS or similar, then cleartext might be excluded, > and the range may be from "unauthenticated" to "authenticated", but always > encrypted. If a protocol is defined to operate only over TLS, then it gets whatever set of TLS features are offered/negotiated. TLS is a security protocol, and I though the term "OS" is supposed to refer to secruity protocols. So, an app running over TLS would not be an example of OS. > >> Thus, until OS is universally adopted, an attempt to execute opportunistic >> security may result in plaintext communication.Since an attempt to use >> opportunistic security is not communicated to users or applications, falling >> back to the status quo, i.e., plaintext communication, is a reasonable >> strategy. > Indeed, but "status-quo" (or more to the point least secure comms mechanism > for protocol in question) is not necessarily unencrypted. the status quo that motivates OS is unencrypted. > I think think brings us back to Nico's suggestion to take a stable > at a higher level definition of OS, not in terms of a list of > properties, but in terms of a philosophy: > > - Universal interoperability, able to connect to all peers, even those > configured for minimal to no security. Yes, universal interoperability is a good feature to add, explicitly. I'll add it. > Unintrusive security that > broadly works, when the peer is not outright misconfigured. "broadly works" isn't very clear., at least to me. Since a peer may not support OS, how is misconfigured different from not supported? > > - Opportunistic use of available security mechanisms. Encrypt when > possible, authenticate when possible, downgrade-resistant when > possible, ... encrypt when possible is the fundamental requirement, so it seems redundant here. I think there is too much focus on "available security mechanisms" in the text above. > I tend to phrase this in the more cryptic form of "no floor, no ceiling", > but that is too opaque without a detailed explanation. yes, way too opaque. > Nico's definition for reference/comparison: > > You get the strongest security in the Internet threat model > that can be obtained, and you get as strong a floor on security > in the Internet threat model as that which you can securely > discover, else the floor may be as low as protection only > against passive attacks. > > We're saying the same thing I think. His is more succinct than > this message, I hope I've been able to clarify rather than merely > repeat the idea. Sorry, but as I mentioned in my reply to Nico, the long sentence above is not at all clear. Succinctness is a virtue only if clarity survives. Steve From nobody Thu Apr 17 07:36: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 7C3341A016F for ; Thu, 17 Apr 2014 07:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 7sljvQMBROOS for ; Thu, 17 Apr 2014 07:36:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB6E1A016D for ; Thu, 17 Apr 2014 07:36:34 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:56110 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WanQd-0007Kh-C0 for saag@ietf.org; Thu, 17 Apr 2014 10:36:39 -0400 Message-ID: <534FE6EE.3000908@bbn.com> Date: Thu, 17 Apr 2014 10:36:30 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 CC: "saag@ietf.org" References: 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/0QPwIb7yL4cwno-rzWD3N1AqpgA Subject: Re: [saag] The floor on OS (Re: new terminology ID posted) 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, 17 Apr 2014 14:36:42 -0000 Nico, > ... > It's hard to overstate the importance of having the floor strength be > variable _and_ that when the floor is strong you have no fallback on > weaker levels of security. So, new thread. > > Floors: > > - no security whatsoever (everything sent in cleartext); > > - unauthenticated key exchange (note that RSA key transport can do > this), which obtains protection against passive attackers; yes, RSA key transport can do this, if the keys are sent w/o binding to identities. But D-H seems preferable, especially if we want to promote PFS. > It goes without saying that keys are exchanged so they can be used > for authenticated encryption and possibly for channel binding (or > other MITM detection schemes), so I won't repeat this below. OK. > - unauthenticated key exchange w/ TOFU/LoF/TACK/pinning, which > obtains protection against passive attackers and forces MITMs to > remain in the middle for longer than they might be prepared, willing, > or able to; agreed, but TOFU/LoF/pinning all pose problems when key change is needed, and often they assume a human user in the loop. thus they may not be viewed as fundamental aspects of all OS proposals, of even universally applicable next steps in an incremental list,, such as the one you have constructed here. > > There is the risk that forcing a capable MITM to always be in the > middle causes further disclosures to them. But having fallen victim > to an MITM once this seems like a small additional risk. can't parse these two sentences. > > - authenticated key exchange. > > Authentication can be done in any number of ways, from DNSSEC-based to > PKI-based, to web of trust-based. If one does TOFU/LoF then on > subsequent exchanges we have a form of authenticated (pseudonymous) > key exchange. I would not mix Web PKI and DNSSEC (DANE?) based mechanisms too freely with TOFU/LoF. Pinning is an appropriate mechanism to detect a change in credentials that may indicate a security problem when using the 3 sources of authenticated keys you noted. > "Opportunistic" necessarily means that the floor that one gets might > be very low strength. But it must not mean that a fallback on > low-strength is always required. We'd be doing a great disservice to > the public if required fallback to the lowest floor in all > circumstances! Agreed. not in all circumstances, but in some, if we believe universal interoperability also is a requirement. > We must allow for discovery of floor strength for specific peers. "must" is a bit strong here. if what you mean is that IF one can discover the security capabilities for a given peer, and IF one remembers what has been discovered, and IF a peer never regresses, then we can prevent future downgrade attacks while using OS. it what what you mean by must? > TOFU/LoF, TACK, pinning -- these are technologies for setting the > floor in the future to be no lower than today (modulo expiration, > ...). agreed, but expiration and key compromise are nasty details that we cannot ignore. > PKI (DNSSEC or x.509/PKIX) is a technology for discovering the lowest > floor in the present. Not sure what you mean here. the Web PKI in the HTTPS environment is based on credentials passed for every session. So, what you knew yesterday and what you learn today may differ. DANE may operate the same way, unless clients maintain state for previously discovered TLSA records. We can explore the notion of clients maintaining state for certs and TLSA records, but do we believe we should mandate this now? > DNSSEC/DANE in particular is a technology for out-of-band high floor > discovery, which therefore strongly indicates that fallback on lower > strength floors should be NOT permitted. agreed. > DNSSEC is a PKI of sorts however, with all the problems that that > implies. This is a reason to expect some pushback on DNSSEC-based > solutions. If one does not trust the DNSSEC PKI then either one must > not use DANE or one must require the use of other technologies (e.g., > TOFU/LoF) in addition to DANE to add a measure of security. yes, DANE is PKI-like, and with any PKI if you don't trust he CAs, life is very messy. So, is your bottom line that OS can offer better than plaintext fallback under certain circumstances, like the ones discussed above? if so, we have no disagreement. but, we also have to recognize that any universal statement about OS must encompass the situation in which not every peer supports OS, and thus the floor if plaintext, unauthenticated communication. So is this just a matter of communicating both notions ion our definition of OS? Steve From nobody Thu Apr 17 09:07: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 3C9C01A01C4 for ; Thu, 17 Apr 2014 09:07: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 nBeTjxuKrEEh for ; Thu, 17 Apr 2014 09:07:22 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4832E1A01CD for ; Thu, 17 Apr 2014 09:07:22 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4F9962AAB4E; Thu, 17 Apr 2014 16:07:17 +0000 (UTC) Date: Thu, 17 Apr 2014 16:07:17 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140417160717.GF18879@mournblade.imrryr.org> References: <534C34DB.8020604@bbn.com> <20140416050636.GV18879@mournblade.imrryr.org> <534FE258.6040406@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <534FE258.6040406@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/7xATNPfsfBPedo92ZMbfGsi8Fag Subject: Re: [saag] OS features/requirements analysis 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, 17 Apr 2014 16:07:25 -0000 On Thu, Apr 17, 2014 at 10:16:56AM -0400, Stephen Kent wrote: [ First quoted block moved to the top for emphasis. This is absurd. If arguments along these lines continue, I will be forced to withdraw my "go for it" vote, and will suggest that others do likewise, on the basis that the current author/editor is doggedly obstructing progress. ] > If a protocol is defined to operate only over TLS, then it gets whatever > set of TLS features are offered/negotiated. TLS is a security protocol, > and I though the term "OS" is supposed to refer to security protocols. So, > an app running over TLS would not be an example of OS. Of course "opportunistic security" applies with TLS. Authentication is optional in TLS, even when certificates are exchanged, either or both parties can simply ignore them or use any of a number of non-PKIX mechanisms to validate them. If we exclude TLS, we push out adoption of "OS" to some nebulous future when all applications have migrated to new channel security protocols. > > - However, when stronger policy is discovered, failure to > > achieve the discovered policy level may indeed be treated in the > > same way as failure to achieve a-priori (non-opportunistic) strong > > policy. > > what's a policy here? Is the policy an advertised set of security > capabilities, as suggested later, communicated via the DNS? Yes, that's what I mean, perhaps some word other than "policy" would be better, but I've been going with "policy" for the purpose of this discussion. > > - We should perhaps not pre-judge what may or may not be confusing > > to users in terms of signalling the security level. This should > > be left to application designers. Applications may want to use > > passive signalling to indicate cleartext vs. unauthenticated > > encryption vs. authenticated encryption via some discovered policy. > > Such signalling via a passive UI element if designed appropriately > > should not be excluded by the definition of OS. > > Most app designers (present company excluded, of course) have a poor history > of managing UIs wrt security, so I am not enthusiastic about the last bullet > above. Sure, but well thought out UIs should not be discouraged from communicating more a more nuanced security status unambiguously to an appropriate set of users. > Also, what is "passive signalling?" Anything along the lines of a colour element or a "lock icon" that is unobtrusive, unlike a dialogue box that demands attention and interaction. > >We should not assume an unauthenticated ceiling for OS. Some application > >protocols will admit opportunistic security policies with a broader range > >than merely: > > > > * cleartext, or else, when possible > > * unauthenticated encryption to thwart passive eavesdropping > > The primary rationale provided for OS is the second bullet above. > Thus having OS focus on that seems reasonable. The "focus" must not be too narrow. OS needs to *at least* deal with pervasive monitoring, but a broader definition that covers that use case and more is even better. The core philosophy I'm proposing for OS is to maximize interoperable security. OS clients will interoperate with all peers, absent active attacks, peer misconfiguration or peer implementation bugs. The minimal profile, is just unauthenticated encryption with fallback to cleartext when that is the default peer capability. With opportunistic DANE TLS (or other dynamically discovered capabilities (peer policies)) the connection may be authenticated, and fallback may be avoided to thwart active downgrade attacks. In other words, while STRINT focused squarely on addressing pervasive passive monitoring, the definition of "opportunistic security" should be broader, and should cover opportunistic protocols with higher ceilings. > You stated an assumption at the end which is not consistent with what > I have heard many folks assume, i.e., that the target of a session > advertises it's security capabilities. * Not an assumption, a use-case. Some opportunistic security protocols will have more information to work with than others. * For fallback to be possible, some kind of 'advertisement' is inevitable. It could be "STARTTLS". It could be a SRV RRset. It could be listening on a well known port where one expects a secured variant of the same service... > I don't disagree that one could > choose to operate this way, but it has not been an agreed-upon part of the > opportunistic * discussions in general. I suspect the reason is that the > more prerequisites we impose on OS, the longer it will take to deploy. I repeat: I am NOT suggesting OS *requirements*. I am suggesting that "opportunistic security" is an "umbrella term", which will cover a range of technologies with some core similarities in their approach to security. The term "opportunistic security" does NOT describe a single protocol. I am merely insisting that the term be defined broadly enough to make space for a range of protocols, some of which will have additional properties that are NOT required for OS, but are in fact compatible with the umbrella term. Where an OS protocol with a higher ceiling is a good fit for a particular application protocol, I'd like to encourage the adoption protocols that don't set the ceiling too low. However, such efforts must not derail broad adoption of best effort to at least thwart passive eavesdropping. Thus for SMTP opportunistic DANE TLS operates at multiple levels: - Cleartext for peers with no TLSA RRs and no "STARTTLS". - Unauthenticated encryption for peers with "STARTTLS" only. Many implementations fall back to cleartext when the TLS handshake fails with such a peer. - Mandatory unauthenticated encryption for peers with a TLSA RRset, where the advertised parameters are not usable for authentication, but the mere presence of the TLSA RRset commits the peer to implement TLS. - Mandatory authenticated encryption for peers with a usable TLSA RRset. This mode of operation maximizes security against both passive and active attacks. We don't fail to encrypt, just because authentication is not possible, but we also don't fail to authenticate when possible, just because authentication is not possible with many/most peers and by default we try to at least encrypt. The above is definitely "opportunistic security" and while the model goes beyond the STRINT focus on dealing with pervasive passive monitoring, it is not at odds with the goals of STRINT and more importantly it meets a reasonable more expansive definition of the umbrella term "opportunistic security", which needs to be broader than just a response to passive monitoring. > If we defer an action because we have detected an active attack, a > user is inconvenienced. Because the user explicitly enabled a security mechanism that detects active attacks. In Postfix the "dane" security level is NOT forced on MTA administrators, they need to turn it on and can set it either as a default level for all destinations, or the security level for some subset of destinations. > If users are inconvenienced, they may decide > that a service they didn't ask for is an annoyance, and thus they > might demand that it be disabled. I did not say that the user "did not ask for" the hardened variant of opportunistic security, that's your assumption. > This potential outcome runs counter to the primary goal of increasing > use of encryption. If only that were the problem! What is the point of encryption that one knows is actually subverted by a man in the middle attack? The primary goal is to frustrate passive eavesdropping, and certainly if a candidate protocol is subject to lots of authentication failure false positives (sans active attack), then it may discourage use, to the detriment of the primary goal. However, if a candidate protocol delivers robust unauthenticated encryption, and a sufficiently low FP rate, and one can configure fallback policies for authentication failure which, for example, lead to unauthenticated encryption with a warning when authentication that should have worked fails, then it is reasonable to try to reach a higher ceiling. > So, I think many > folks have emphasized the need for an OS design that is not intrusive, > i.e., essentially painless. The many folks in question, have not considered all possible use-cases, for opportunistic security. They are still thinking primarily of their grand-parents using a browser, and in that case, perhaps for now only the least ambitious approaches are viable. However, you're not writing a design-spec for a browser security policy. You're writing a definition of "opportunistic security", which MUST be able to go beyond grandpa's browser use-case. I expect you'll find that "folks" on this forum will broadly support the idea that "opportunistic security" is an "umbrella term" and not just a counter-measure to a single problem. > >In other words, just because STRINT participants did not envision > >downgrade-resistant opportunistic authenticated encryption, does > >not mean that the OS definition should exclude such protocols. > >Perhaps more strongly OS protocols SHOULD strive for higher security, > >when reasonably compatible with the application protocol. > > A less pejorative explanation is that the participants felt that maximizing > deployment of encryption was the most important goal :-). This is a spurious argument, because you're still arguing against including higher ceilings as required features of OS, while all I am asking for is *not excluding* higher ceilings from the definition of a term that subsumes multiple protocols, some of which might well be as unambitious in their security ceiling as you suggest. > >Don't *just* resist passive eavesdropping, let's deploy flexible > >security protocols that interoperate at multiple security levels. > >Initially things like the DANE for SMTP protocol will still be > >rare, but if we can get traction with DNSSEC and DANE, perhaps some > >day we can have opportunistic security that is in some ways stronger > >than current mandatory security mechanisms. > > Stronger? In some ways, specifically the difference between PKIX and DNSSEC with respect to who can issue certificates for which domains. Anyway, this is not the point. > Providing very widely deployed resistance to passive wiretapping > seems to be the primary goal of OS. NO! The term "opportunistic security" MUST be an "umbrella term" for a collection of protocols, all of which share the trait of not throwing out the baby with the bath-water when their security ceiling cannot be reached. They adaptively operate at multiple security levels, opportunistically achieving the highest level applicable for a given peer. > If authentication can be achieved, without > imposing unacceptable delays, then it is a great extra feature. That's how I > have heard many folks characterize OS goals. Please adopt a more flexible definition of "OS" or allow others to do so. "OS" is a not a single protocol for a single application. "OS" is a set of principles for a new adaptive approach to security, which strives to maximize the security level achieved without excluding the majority of peer systems for lack of a maximally secure channel. > >May be mandatory when discovered, but exception mechanisms (log > >warning, prompt user, ...) may be available in some applications, > >just as they are for existing mandatory security policies. > > Again, what is meant by "discovered"? If an app performs authentication, > instead of a security protocol, that is a separate topic. Maybe I am > misunderstanding your intent here. Discovered, means dynamically determined via interaction with external information sources. Thus with "opportunistic DANE TLS", authentication applies some destination domains and not others, and may apply to a domain at one time (when TLSA records are published) and not at another time (when they are not yet or no longer published). Opportunistic here means that authentication applies when the relevant capabilities are discovered. > >Indeed, but "status-quo" (or more to the point least secure comms mechanism > >for protocol in question) is not necessarily unencrypted. > > the status quo that motivates OS is unencrypted. Primary motivating cases are a good thing to have, but one then needs to be willing to remove blinders and leave room for additional relevant use-cases. > "broadly works" isn't very clear., at least to me. Since a peer > may not support OS, how is misconfigured different from not supported? Since "OS" is not an application protocol, it makes little sense to speak of peers not supporting it. Peers speak valid variants of the application protocol, some more secure than others. Misconfigured means unable to speak the application protocol correctly, which includes, as a special case, unable to deliver on the advertised security parameters. Opportunistic security works with properly configured peers at multiple security levels absent MiTM attacks. > >Nico's definition for reference/comparison: > > > > You get the strongest security in the Internet threat model > > that can be obtained, and you get as strong a floor on security > > in the Internet threat model as that which you can securely > > discover, else the floor may be as low as protection only > > against passive attacks. > > > >We're saying the same thing I think. His is more succinct than > >this message, I hope I've been able to clarify rather than merely > >repeat the idea. > > Sorry, but as I mentioned in my reply to Nico, the long sentence above is > not at all clear. Succinctness is a virtue only if clarity survives. Please suggest a less succinct, more clear formulation. -- Viktor. From nobody Fri Apr 18 17:12: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 F03D91A0572 for ; Fri, 18 Apr 2014 17:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 YbRAu1EYBCRi for ; Fri, 18 Apr 2014 17:11:58 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7871A0549 for ; Fri, 18 Apr 2014 17:11:58 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:48465 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WbIt0-000IPb-DW for saag@ietf.org; Fri, 18 Apr 2014 20:12:02 -0400 Message-ID: <5351BF48.5080503@bbn.com> Date: Fri, 18 Apr 2014 20:11:52 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag Content-Type: multipart/alternative; boundary="------------010802060807030107080408" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/htxqYTvlrdZnP4SW2267FvYocoY Subject: Re: [saag] OS features/requirements analysis 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, 19 Apr 2014 00:12:02 -0000 This is a multi-part message in MIME format. --------------010802060807030107080408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I completed a point-by-point response to Viktor's message, but the result is very long and probably not something most folks want to read. So, I'm posting a reply that tries to focus the discussion, and provides only summary responses to Viktor. If we're to make progress, a good approach is to review the criteria/features and rationales I offered and respond to each one. The response could be OK for both, a proposed rewording of the criteria/feature, possibly with comments re the rational, or a NO, with a thorough explanation of why the cited rationale is off base. Viktor's message repeatedly said my characterization of OS was too narrow, but failed to cite specific issues. He also repeatedly cited just one example of what OS "MUST" encompass, which just happens to be his I-D in DANE. To me, this approach makes his view of OS seem to be narrow. I think OS should encompass a range of protocols, including TLS 1.3 (based on the goals set forth by EKR), maybe TCPcrypt (still in WG charter stage), a variant of IPsec (maybe what Paul or Yoav are proposing), etc. Despite assertions to the contrary, I have never suggested that OS should be defined in a way such that only one protocol meets the criteria. I do believe that we can craft a good, broad definition of OS, but I reject the notion that OS needs to be so broad that nothing is excluded. Such a definition seems worthless to me, unless we're looking to create a "brand." I do believe Viktor has identified a couple points where there is real disagreement, and thus the IETF, startinfg with SAAG, has to decide what it wants. The STRINT workshop breakout session participants were convinced that a human user should not (MUST NOT?) be informed about the invocation of OS, nor its failure to achieve its basic goal (an encrypted session) or the optional goals of an authenticated session or MiTM exclusion. This is a legitimate tipic for discussion. Maybe that statement should be tempered to refer to human users (vs. apps w.o such users) or maybe it should be stated as a SHOULD, vs. a MUST. But Viktor is, IMHO, out of line, when he insists that a specific set of OS features MUST be included/excluded. (A lot of security experts and IETF leaders participated in the breakout session and Viktor has no standing to dismiss their views peremptorily.) There were several inconsistent aspects of Viktor's comments that merit responses. For example, he agreed that OS is not an app protocol, but then questioned how a peer might not support it. Need we discuss the many examples of peer not supporting the same version of TLS as an obvious counterexample? His characterization of "mis-configuration" (in response to my question) was: Misconfigured means unable to speak the application protocol correctly, which includes, as a special case, unable to deliver on the advertised security parameters. If security parameters are mandatory to implement, then an instance of a protocol that does not support the parameters is non-compliant, not mis-configured. If security parameters are not MTI, then it's also not a config error, it's an incompatibility due to one entity requesting an optional feature that is not supported by the other. I mention this because it shows that terms being bandied by Viktor about are not well defined and represent a very narrow perspective. Viktor also explained what he meant by "discovered", in response to my question: Discovered, means dynamically determined via interaction with external information sources. This does not indicate which of the words used are central to the definition. Is "dynamic" a critical feature, is the use of an "external" source important, ...? Opportunistic here means that authentication applies when the relevant capabilities are discovered. What if a protocol works by sending credentials over an encrypted channel to effect authentication, as TLS 1.3 may do? That doesn't appear to be discovery based on Viktor's definition, yet it seems very reasonable to me. I mention these examples because Viktor seems to revert to his one favorite example, his DANE-enabled TLS for SMTP I-D, and thus his explanations of ambiguous terms appear to be very narrow. This is in contrast to his complaint that my criteria are too narrow, without citing specific text to support this assertion. The anti-PM statement that Stephen Farrell created, and that will soon become an RFC, seems to identify the primary goal of our efforts as developing protocols that remove impediments to very widespread use of encryption, with or without authentication. So, Viktor and I disagree on whether this provides us with a primary focus for the OS definition, based on the IESG-approved doc. I suggest Stephen needs to weigh in on this issue. In his messages on Wednesday and Thursday, Viktor attributes specific mindsets to STRINT attendees, and uses his perceptions to justify dismissing the consensus of the breakout session in question. This is the highest form of hubris. Nobody should presume to know what others are thinking when they reach a conclusion, and for someone who didn't even attend the workshop to do so is absurd (and insulting). I suggest that Viktor, and others, address the suggested OS criteria/features and rationales as a constructive way to progress this work. I ask that both Sec ADs, and others who participated in the breakout session, comment on the criteria and rationale, both in terms of whether I accurately conveyed the sense of the session, and whether they still support the criteria. I'm off on vacation now. When I return, I'll make changes to the OS I-D based on directions I receive from the Sec ADs, since they are the nominal chairs of SAAG. Steve --------------010802060807030107080408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I completed a point-by-point response to Viktor's message, but the result is very
long and probably not something most folks want to read. So, I'm posting a reply that
tries to focus the discussion, and provides only summary responses to Viktor.

If we're to make progress, a good approach is to review the criteria/features and
rationales I offered and respond to each one. The response could be OK for both,
a proposed rewording of the criteria/feature, possibly with comments re the rational,
or a NO, with a thorough explanation of why the cited rationale is off base.

Viktor's message repeatedly said my characterization of OS was too narrow, but failed to
cite specific issues. He also repeatedly cited just one example of what OS "MUST"
encompass, which just happens to be his I-D in DANE. To me, this approach makes his view
of OS seem to be narrow.

I think OS should encompass a range of protocols, including TLS 1.3 (based on the goals
set forth by EKR), maybe TCPcrypt (still in WG charter stage), a variant of IPsec (maybe
what Paul or Yoav are proposing), etc. Despite assertions to the contrary, I have never
suggested that OS should be defined in a way such that only one protocol meets the criteria.

I do believe that we can craft a good, broad definition of OS, but I reject the notion
that OS needs to be so broad that nothing is excluded. Such a definition seems worthless
to me, unless we're looking to create a "brand."

I do believe Viktor has identified a couple points where there is real disagreement, and
thus the IETF, startinfg with SAAG,  has to decide what it wants. The STRINT workshop
breakout session participants were convinced that a human user should not (MUST NOT?)
be informed about the invocation of OS, nor its failure to achieve its basic goal
(an encrypted session) or the optional goals of an authenticated session or MiTM exclusion.
This is a legitimate tipic for  discussion. Maybe that statement should be tempered to
refer to human users (vs. apps w.o such users) or maybe it should be stated as a SHOULD,
vs. a MUST. But Viktor is, IMHO, out of line, when he insists that a specific set of
OS features MUST be included/excluded. (A lot of security experts and IETF leaders
participated in the breakout session and Viktor has no standing to dismiss their
views peremptorily.)

There were several inconsistent aspects of Viktor's comments that merit responses.
For example, he agreed that OS is not an app protocol, but then questioned how a
peer might not support it. Need we discuss the many examples of peer not supporting
the same version of TLS as an obvious counterexample? His characterization of
"mis-configuration" (in response to my question) was:
Misconfigured means unable to speak the application protocol
correctly, which includes, as a special case, unable to deliver on
the advertised security parameters.
If security parameters are mandatory to implement, then an instance of a protocol
that does not support the parameters is non-compliant, not mis-configured. If security
parameters are not MTI, then it's also not a config error, it's an incompatibility due
to one entity requesting an optional feature that is not supported by the other. I
mention this because it shows that terms being bandied by Viktor about are not well
defined and represent a very narrow perspective.

Viktor also explained what he meant by "discovered", in response to my question:
Discovered, means dynamically determined via interaction with
external information sources.
This does not indicate which of the words used are central to the definition.
Is "dynamic" a critical feature, is the use of an "external" source important, ...?
Opportunistic here means that authentication applies when the
relevant capabilities are discovered.
What if a protocol works by sending credentials over an encrypted channel
to effect authentication, as TLS 1.3 may do?  That doesn't appear to be
discovery based on Viktor's definition, yet it seems very reasonable to me.

I mention these examples because Viktor seems to revert to his one favorite example,
his DANE-enabled TLS for SMTP I-D, and thus his explanations of ambiguous
terms appear to be very narrow. This is in  contrast to his complaint that my
criteria are too narrow, without citing specific text to support this assertion.

The anti-PM statement that Stephen Farrell created, and that will soon become an RFC,
seems to identify the primary goal of our efforts as developing protocols that remove
impediments to very widespread use of encryption, with or without authentication. So,
Viktor and I disagree on whether this provides us with a primary focus for the OS
definition, based on the IESG-approved doc. I suggest Stephen needs to weigh in on this
issue.

In his messages on Wednesday and Thursday, Viktor attributes specific mindsets to
STRINT attendees, and uses his perceptions to justify dismissing the consensus of
the breakout session in question. This is the highest form of hubris. Nobody should
presume to know what others are thinking when they reach a conclusion, and for someone
who didn't even attend the workshop to do so is absurd (and insulting).

I suggest that Viktor, and others, address the suggested OS criteria/features and
rationales as a constructive way to progress this work.

I ask that both Sec ADs, and others who participated in the breakout session, comment
on the criteria and rationale, both in terms of whether I accurately conveyed the
sense of the session, and whether they still support the criteria.

I'm off on vacation now. When I return, I'll make changes to the OS I-D based on
directions I receive from the Sec ADs, since they are the nominal chairs of SAAG.

Steve



--------------010802060807030107080408-- From nobody Fri Apr 18 20:03: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 664F71A021E for ; Fri, 18 Apr 2014 20:02:59 -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 4WCmoWsUkLiU for ; Fri, 18 Apr 2014 20:02:56 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 320961A0016 for ; Fri, 18 Apr 2014 20:02:55 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 582612AA9F7; Sat, 19 Apr 2014 03:02:51 +0000 (UTC) Date: Sat, 19 Apr 2014 03:02:51 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140419030251.GI18879@mournblade.imrryr.org> References: <5351BF48.5080503@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5351BF48.5080503@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_uy4i821gGsm67TKT3cruKrJsjE Subject: Re: [saag] OS features/requirements analysis 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: Sat, 19 Apr 2014 03:02:59 -0000 On Fri, Apr 18, 2014 at 08:11:52PM -0400, Stephen Kent wrote: > If we're to make progress, a good approach is to review the > criteria/features and rationales I offered and respond to each one. > The response could be OK for both, a proposed rewording of the > criteria/feature, possibly with comments re the rationale, > or a NO, with a thorough explanation of why the cited rationale is off base. That's fine, but this leaves no room for higher level structural feedback, such as an over-arching definition of O/S as an approach to communications security in terms of the overall approach rather than specific behavioural features. Such an over-arching definition would then make it possible to evaluate the specific proposed behaviours in light of a unifying set of principles. The key proposal that you seem to be resisting is that "opportunistic security" is a broader term, that should cover more than just the core STRINT response to pervasive monitoring. My I-D is just one example of the need for a more expansive term. > Viktor's message repeatedly said my characterization of OS was too narrow, > but failed to cite specific issues. The current language presumes that opportunistic security is necessarily a silent best-effort upgrade from cleartext, and that all failures to do better are silently ignored, and any success to do better is not signaled to the user as better security than cleartext. The requirement to fail silently was highlighted as a problem a number of times. Likewise the requirement to not perform real-time MiTM detection, and so on. > He also repeatedly cited just one example of what OS "MUST" > encompass, which just happens to be his I-D in DANE. To me, this approach > makes his view of OS seem to be narrow. Sorry, arguing for an increased scope of the definition, is not a "narrow" view no matter how one might try to spin it. > I think OS should encompass a range of protocols, including TLS 1.3 (based > on the goals set forth by EKR), maybe TCPcrypt (still in WG charter stage), > a variant of IPsec (maybe what Paul or Yoav are proposing), etc. Indeed, but the specific protocols are not the point. The point is opportunistic behaviour: - Interoperate with the broad base of installed peers, at whatever least common denominator security level is applicable. (The universal interoperability approach). That is don't set the bar too high. - That said, raise the bar as high as possible on a case by case basis, based on the capabilities of the peer. Sometimes that includes mandatory authentication, if suitable parameters are securely published (and thus discovered) for the peer. - Encrypt whenever possible, authenticate when a downgrade-resistant mechanism is enabled by the application that makes it possible to know when and how to do so. And in fact nothing about TLS 1.[0123] is fundamentally "opportunistic security" or not, just like nother AES-256-CBC nor SHA2-256 are neither "opportunistic" nor not "opportunistic security". It is how applications *use* TLS that makes the application behaviour meet a definition of "opportunistic security". > I do believe that we can craft a good, broad definition of OS, but I reject > the notion > that OS needs to be so broad that nothing is excluded. Do not exclude opportunistic security protocols, such as "opportunistic DANE TLS", which meets the above reasonable high level criteria for what it means to be "opportunistic security". Once the big picture is in place, the specific behaviours you list can be tweaked to refine flesh out the various specific properties one might want from opportunistic protocols. > Such a definition seems worthless to me, unless we're looking to create > a "brand." You've succeeded in knocking down a straw-man unrelated to the points raised in my objections. I agree that the straw-man is down. > > The STRINT workshop breakout session participants were convinced that a > human user should not (MUST NOT?) be informed about the invocation of OS, They were not asked to define "opportunistic security", which is not purely a response to pervasive monitoring. Rather "opportunistic security" is a way of building security into protocols that that emphasizes interoperability first, and as much security as reasonably possible second. This means broad deployment first and foremost, and gradual herd immunity as peer capabilities improve. > nor its failure to achieve its basic goal (an encrypted session) or the > optional goals of an authenticated session or MiTM exclusion. This is a > legitimate topic for discussion. Maybe that statement should be tempered > to refer to human users (vs. apps w.o such users) or maybe it should be > stated as a SHOULD, vs. a MUST. The question is I think moot. Why should "opportunistic security" dictate a user interface. That's for application developers to decide in the context of the principles "interoperate first" be "as secure as possible". If low security with some peers is normal, perhaps indeed nothing to make a fuss about. If on the other hand, with some peers more security is expected and not available, perhaps a user notice of some kind is right. Or when strong security is available, perhaps let the user know, ... Why should STRINT, you or I tell application's whose threat model we've not seen how to interact with a user? > But Viktor is, IMHO, out of line, when he > insists that a specific set of OS features MUST be included/excluded. Not MUST be included, rather must not be excluded! The definition need not specifically endorse or even mention opportunistic DANE TLS, but should not be so narrow as to exclude it. Again I contend (as you claim to agree) that we're defining an umbrella term for a set of current and future protocols that share a common core of principles. Let's clearly state those principles, list examples of properties that might be shared by protocols that share the principles, ... but not make the definition to narrow. > (A lot of security experts and IETF leaders participated in the breakout > session and Viktor has no standing to dismiss their views peremptorily.) Now that we're squarely ad-hominem: I have at least as much standing as anyone else, present at STRINT or not. I've been implementing and operating (as postmaster of a large site with many TLS peer relationships) opportunistic security for over a decade. The non-SMTP world is just starting to play catch-up. I've been shipping code that does opportunistic security for nearly a decade, and helped Microsoft design TLS support for Exchange in 2007. The evolution of opportunistic TLS in Postfix to add DANE support is just the most recent icing on the cake. I am not just an I-D author with a spec nobody will implement. The opportunistic DANE TLS protocol for SMTP is implemented in a shipping product and is planned to also be implemented in Exim, I and am working with the OpenSSL team to implement DANE support in the OpenSSL toolkit and expect to bring other MTAs on board over the next few years. The protocol is opportunistic security with scalable downgrade resistance, because lots of SMTP users want stronger than mere passive eavesdropping resistance, but have not had any good options to get there in a scalable way. How exactly is using DANE TLSA when available, and otherwise falling back to unauthenticated STARTTLS, and failing even that to cleartext, so that mail delivery proceeds at the best available security level, NOT "opportunistic security". Just because STRINT did not consider this type of protocol does not mean it magically goes away. I do know more about opportunistic security than most of the authors of papers submitted to STRINT, which in at least some cases read like opportunistic job security ("publish or perish"). I admit I was not at the break-out session, and I'll take your word as sufficient evidence that the discussion there was better grounded in deploying real world systems. Be that as it may, just because the break-out focused on one aspect of opportunistic security to address one problem does not mean that everything else is out of scope. -- Viktor. From nobody Tue Apr 22 01:33: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 3F2CC1A0162; Tue, 22 Apr 2014 01:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 fWZAlFAlX_85; Tue, 22 Apr 2014 01:33:20 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4FA1A0161; Tue, 22 Apr 2014 01:33:20 -0700 (PDT) Received: from [192.168.131.128] ([80.92.122.106]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M9wrU-1WnTRB1mcy-00B1PE; Tue, 22 Apr 2014 10:33:13 +0200 Message-ID: <535628D4.80308@gmx.net> Date: Tue, 22 Apr 2014 10:31:16 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "ace@ietf.org" References: <533EC002.2010506@gmx.net> In-Reply-To: <533EC002.2010506@gmx.net> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ODESLsjihpBW0sPFDqn81Bk8khScjJR8b" X-Provags-ID: V03:K0:ghTdU6B9infijOtmexpPNgP0e/39UQ1sB5P+R1Y+POH+x70/ZZ1 pyeokjoCoG1ioX208+Ims6rtJjedxmHBjkw0R+E4fs6TVWqOt0OlPW2WSWpf8syKO0rss05 OBaR7YbfFuusVXQ4C+lAATBYW5+ffMCfUPdPRefo4uUoKH4CmQoCuElrOIxEhF0G2XUg3JM XoA8W4PR+8HOD+dNSZ4Cg== Archived-At: http://mailarchive.ietf.org/arch/msg/saag/VpZU4uXrKoxWRsQwBmMNShKwQd8 Cc: saag@ietf.org Subject: [saag] Reminder: ABFAB Tutorial - April 22nd 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, 22 Apr 2014 08:33:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ODESLsjihpBW0sPFDqn81Bk8khScjJR8b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please join the ABFAB tutorial today. On 04/04/2014 04:21 PM, Hannes Tschofenig wrote: > Hi all, >=20 > at the ACE BOF we promised to also schedule a tutorial about ABFAB. We > have been working with Margaret, Sam, and Rhys on the details and they > kindly offered to give us an overview of ABFAB and how it applies to th= e > IoT space. >=20 > Date: Tuesday, April 22, 2014 > Time: 1:00 pm BST =3D 8am EDT =3D 8pm CST > http://www.timeanddate.com/worldclock/meetingdetails.html?year=3D2014&m= onth=3D4&day=3D22&hour=3D12&min=3D0&sec=3D0&p1=3D37&p2=3D136&p3=3D179&p4=3D= 33 >=20 > Webex: > https://ietf.webex.com/ietf/j.php?MTID=3Dmd4e56d458aa66a2bbdfd2e1463dbc= 977 >=20 > Meeting Number: 644 405 818 > Meeting Password: abfab >=20 > Audio: > +1-650-479-3208 > Access code:644 405 818 >=20 > Due to the IETF Webex configuration restrictions there are no other > dial-in codes available. >=20 > Ciao > Hannes & Kepeng >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 --ODESLsjihpBW0sPFDqn81Bk8khScjJR8b 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.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTVijUAAoJEGhJURNOOiAtCcQH/3yuNqsW1dr3xnWEOudnzCyO t1/51xMu9NFol/yT/l5uRA25ny1klxLWOUT101LlmruFDHrhYwWgke2xXCaC/L0M puuczxuBFV7orCYUDx2kOYXg5kcTnsTpU/CRsMCot+d6TskwPgGp64p4trhM7QO+ b8JaBzckTlem1BVJU3X4NFsDNKX4xCSPWp3kqrjMkbt1W7DcMyidTdSTqLwopEeS vIPMDFnAnf+PDiXFrfQY8kzprEcM8WQJ8Kiar4Vb9N0V4IRoqXitWoWx2dG+qWav acnEHkhmaYY665sUVOrB39g0YAc/+HkS0h1+CT2GIkKyLnqABSXI6PJmDbMHHks= =S5Hk -----END PGP SIGNATURE----- --ODESLsjihpBW0sPFDqn81Bk8khScjJR8b-- From nobody Fri Apr 25 10:41: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 22DF61A05CB for ; Fri, 25 Apr 2014 10:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 bhk99C85GOkG for ; Fri, 25 Apr 2014 10:41:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 59BF91A0386 for ; Fri, 25 Apr 2014 10:41:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A724CBE70; Fri, 25 Apr 2014 18:41: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 TQtxB7E2aeDx; Fri, 25 Apr 2014 18:41: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 85CC7BE57; Fri, 25 Apr 2014 18:41:29 +0100 (IST) Message-ID: <535A9E4B.3090209@cs.tcd.ie> Date: Fri, 25 Apr 2014 18:41:31 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stephen Kent References: <5351BF48.5080503@bbn.com> <20140419030251.GI18879@mournblade.imrryr.org> In-Reply-To: <20140419030251.GI18879@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/uxetTDiPXviqPqD4Ua-5Ab9Bv2k Cc: saag@ietf.org Subject: Re: [saag] OS features/requirements analysis 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, 25 Apr 2014 17:41:38 -0000 (Sorry that this mail was slow coming, I've been away/offline for a few days but I wanted to respond to one part of this exchange. I'll follow up later with what I think about the technical issues.) On 04/19/2014 04:02 AM, Viktor Dukhovni wrote: > On Fri, Apr 18, 2014 at 08:11:52PM -0400, Stephen Kent wrote: > >> (A lot of security experts and IETF leaders participated in the breakout >> session and Viktor has no standing to dismiss their views peremptorily.) > > Now that we're squarely ad-hominem: > > I have at least as much standing as anyone else, present at STRINT > or not. Steve - Viktor is entirely correct here and your statement about him not having "standing" is really out of order, as you should know well, having as much experience in the IETF as you do. >> I'm off on vacation now. When I return, I'll make changes >> to the OS I-D based on directions I receive from the Sec ADs, >> since they are the nominal chairs of SAAG. So I hope you had a good vacation, and will have the good grace to retract the "no standing" statement above on your return. And I don't want you to do edits based on AD "direction" nor based on any other argument-from-authority but rather based on the consensus of the list. That gets much harder to evaluate if people are put off contributing by the kind of personal attack above, so I really hope that you can see and acknowledge that you were out of line there and we can move on to getting the right text into the I-D and then get that to be an RFC. Thanks, Stephen. From nobody Sat Apr 26 17:18: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 A634D1A06F2 for ; Sat, 26 Apr 2014 17:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 PqkZF1eV4Nq2 for ; Sat, 26 Apr 2014 17:18:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 185301A06F6 for ; Sat, 26 Apr 2014 17:18:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 86F68BE79; Sun, 27 Apr 2014 01:18:18 +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 YG9oegqCSYfN; Sun, 27 Apr 2014 01:18:17 +0100 (IST) Received: from [10.87.48.3] (unknown [86.46.21.208]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 02276BE77; Sun, 27 Apr 2014 01:18:16 +0100 (IST) Message-ID: <535C4CC8.4040301@cs.tcd.ie> Date: Sun, 27 Apr 2014 01:18:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stephen Kent , saag References: <5351BF48.5080503@bbn.com> In-Reply-To: <5351BF48.5080503@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/pcRtx_GL9-JSwI-hP-XwatVeFpA Subject: Re: [saag] OS features/requirements analysis 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, 27 Apr 2014 00:18:32 -0000 Hi Steve, Just trying to give my answers to questions asked. I hope others do too. I'll send a separate message with my comments on the -01 draft and a bit of suggested text. On 19/04/14 01:11, Stephen Kent wrote: > I think OS should encompass a range of protocols, including TLS 1.3 > (based on the goals set forth by EKR), maybe TCPcrypt (still in WG > charter stage), a variant of IPsec (maybe what Paul or Yoav are > proposing), etc. Despite assertions to the contrary, I have never > suggested that OS should be defined in a way such that only one > protocol meets the criteria. Good. On that I think we're all agreed. > I do believe that we can craft a good, broad definition of OS, but I > reject the notion that OS needs to be so broad that nothing is > excluded. Such a definition seems worthless to me, unless we're > looking to create a "brand." That's fair. Of course it doesn't mean we won't all argue about the definition. Most people on here are clever enough to find a way to argue about such things for about as long as they want to continue arguing:-) > > I do believe Viktor has identified a couple points where there is > real disagreement, and thus the IETF, startinfg with SAAG, has to > decide what it wants. The STRINT workshop breakout session > participants were convinced that a human user should not (MUST NOT?) > be informed about the invocation of OS, nor its failure to achieve > its basic goal (an encrypted session) or the optional goals of an > authenticated session or MiTM exclusion. This is a legitimate tipic > for discussion. Maybe that statement should be tempered to refer to > human users (vs. apps w.o such users) or maybe it should be stated as > a SHOULD, vs. a MUST. I think that we should only refer to human users when we really have to, and should otherwise always talk about what BGP calls protocol speakers. (But not use BGP terminology.) As for the should vs must in the above, I think should is right - in general "OS should not result in user visible signals" seems about right. > Viktor also explained what he meant by "discovered", in response to > my question: > > Discovered, means dynamically determined via interaction with > external information sources. > > This does not indicate which of the words used are central to the > definition. Is "dynamic" a critical feature, is the use of an > "external" source important, ...? > > Opportunistic here means that authentication applies when the > relevant capabilities are discovered. Personally, I don't see any significant point in the above so I must be missing it. (Or maybe that part is just a result of you two arguing? Not sure.) FWIW, I don't think the terms dynamic or external or discover are needed in how we define OS. > The anti-PM statement that Stephen Farrell created, and that will > soon become an RFC, seems to identify the primary goal of our efforts > as developing protocols that remove impediments to very widespread > use of encryption, with or without authentication. So, Viktor and I > disagree on whether this provides us with a primary focus for the OS > definition, based on the IESG-approved doc. I suggest Stephen needs > to weigh in on this issue. Sure. That I can do. I think that PM is the main motivator for what's getting people moving. However in what we do we should be aiming for more than just countering PM. As the title of STRINT implied we want to strengthen the Internet. So I think of PM as the motivator, but OS as being more broadly applicable. I don't think the only goal of OS is to counter PM. Another one, for me, is to ease deployment of crypto so that it spreads easier/sooner/more. > I ask that both Sec ADs, and others who participated in the breakout > session, comment on the criteria and rationale, both in terms of > whether I accurately conveyed the sense of the session, and whether > they still support the criteria. I think your characterisation is quite accurate but I don't think that that session resulted in quite such certainty or as precise an agreement as you seem to imply. (Mind you I had to leave early so I might not be the best person to ask.) Cheers, S. From nobody Sat Apr 26 17:20: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 2C72C1A06FE for ; Sat, 26 Apr 2014 17:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.328 X-Spam-Level: * X-Spam-Status: No, score=1.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, MANGLED_YOUR=2.3, RP_MATCHES_RCVD=-0.272] 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 V7X-mg3LOfMw for ; Sat, 26 Apr 2014 17:20:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C6F161A06FA for ; Sat, 26 Apr 2014 17:20:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 38CEABE79; Sun, 27 Apr 2014 01:20: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 C8m-GpklQTft; Sun, 27 Apr 2014 01:20:44 +0100 (IST) Received: from [10.87.48.3] (unknown [86.46.21.208]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BC17ABE77; Sun, 27 Apr 2014 01:20:44 +0100 (IST) Message-ID: <535C4D5C.5070305@cs.tcd.ie> Date: Sun, 27 Apr 2014 01:20:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stephen Kent 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/1mcr9NzppAVccltjVe5dkvT2eeo Cc: "saag@ietf.org" Subject: [saag] comments on draft-kent-opportunistic-security-01 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, 27 Apr 2014 00:20:55 -0000 Hi Steve, Here are my comments on draft-kent-opportunistic-security-01. (With no hats etc.) I think there're a bunch of smallish fixes needed but we're closing in on getting there I hope. (I'll send some suggested text in a separate mail) Cheers, S. - Title: I'd suggest just "Opportunistic Security" - Abstract shouldn't have references - I'd not emphasise STRINT so much, its worth a mention and a reference in the intro but ins't really important in the abstract. - PM is not the only or main target for OS IMO. PM is what has motivated this and things like STRINT, but we want to strengthen the Internet's security mechanisms (and improve deployment) while addressing PM. So I don't think PM is the main reason for OS at all. - Intro, 1st sentence: I'd add at the end "which can also improve overall Internet security against other threats as per the goals of the STRINT workshop [STRINT]" which is probaby enough mention of STRINT really. - Intro, 2nd sentence: s/authentication/endpoint authentication/ might be better and s/the major/ a major/ - Intro, delete sentence with "flurry" - its not needed - Intro, para 2: suggest s/precise meaning/precise, albeit not widely used, meaning/ - Intro, para 2: suggest referring to STRINT not as a "basis" for this but as per the above, so maybe delete this last sentence. - Definition: OS "is a set of mechanisms" seems wrong. Rather OS is descriptive term that may or may not apply to a given protocol. - Definition: suggest removing "(for realtime communication)" could be confusing with WebRTC or RAI and would be odd to say realtime for e.g. MPLS. And who knows, we might find useful ways to apply this to store-and-forward as well. - Definintion: I think what we want to present here are a set of conditions the conjuntion o which is sufficient for something to properly use the term OS. The current list is close to that but not that. - Definition-1: "is invisible" is too much I think. It'd be silly if we had to pretend not to be encrypting for example, I think what needs to be stated is that we don't make the lock-icon mistake again really. - Definition-2: I like Nico's floor/ceiling way of describing this, suggest getting him to craft a bit of text for this aspect. - Definition-2 and general: we should only speak of a user when we really need to say that. So s/to a user// here. - Definition-2: I don't get the MUST here. The existence of OS doesn't cause anything else to not exist. - Definition-3: "will make use of" is IMO too strong, "strongly recommended" would be correct. - Definition-4: I'm not sure what this is saying. If what you want to say is that the server-auth model commonly used with TLS is "ok" then just saying that is probably better. (But I think Nico's floor/ceiling may be useful there.) - Definintion-5: the "only if" here is too much, I think you want to say that endpoint authenticaiton is preferable to just MITM detection. (But then points 2 and 4 do that already don't they?) - Definition-6: Suggest deleting "human-perceptible" as any delay can be considered a problem. I also think that point would be better separated from the delayed authenticaiton one. (And I think the last two sentences aren't really needed.) - Definition-7: I think what you'r saying here is that if you fall back to cleartext to get interop, then your protocol may still be properly terms OS. - Section 2: A minor point - describing TLS server auth as a prior unilateral arrangement is good. In fact TLS server auth is a tri-lateral arrangement between clients (e.g browsers) with trust anchors, CAs and servers. - Section 2: The last para doesn't really belong here and I think all that was already stated so I'd say delete that maybe. - Section 4, last para: The "then attempt to upgrade" part seems wrong - with OS we do stuff and might then upgrade if we can and if that makes sense for the protocol concerned. - Section 5: I'm not sure we need this really. I'd suggest deleting it. If we keep it, then its has to be clear what's copied from 4949 and what's modified (and how) and what's new. From nobody Sat Apr 26 17:23: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 B29431A0701 for ; Sat, 26 Apr 2014 17:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.272] 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 K48sDZXLTp7r for ; Sat, 26 Apr 2014 17:23: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 6DC5B1A0703 for ; Sat, 26 Apr 2014 17:23:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 04123BE7C; Sun, 27 Apr 2014 01:23: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 LNdKxd42KRCf; Sun, 27 Apr 2014 01:23:01 +0100 (IST) Received: from [10.87.48.3] (unknown [86.46.21.208]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 77ECEBE79; Sun, 27 Apr 2014 01:23:01 +0100 (IST) Message-ID: <535C4DE5.2080207@cs.tcd.ie> Date: Sun, 27 Apr 2014 01:23:01 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stephen Kent 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/vzRPOXbDkQp1BwAIrWiqbiwRMvs Cc: "saag@ietf.org" Subject: [saag] suggested text for opportunistic definition 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, 27 Apr 2014 00:23:12 -0000 Hi, I tried to see what the Steve's definition would look like if my comments were applied to it and came up with this. I tried to keep the numbering as close to the draft as I could to make it easier to compare. S. Opportunistic Security (OS) is a descriptive term for how security is handled in protocols that exhibit the following characteristics: 0. OS involves establishing and using shared secrets to provide confidentiality for communications between endpoints, even if there is no guarantee of the identities of the endpoints (so that one of them could be a Man-in-the-Middle). 1. OS is generally invisible to users, (no "lock icons") and, more broadly, to applications that initiate sessions. Lack of visibility is important, so that users or application administrators do not become confused by the variability in the set of security services they are being afforded. This allows applications to benefit from opportunistic security without user or administrator intervention. 2. Opportunistic security is not a substitute for endpoint authentication, when that security service can be provided. Authentication of endpoints makes various attacks much harder and continues to have significant value. In various protocols OS can be seen as establishing a "floor" for security where the "ceiling" is a higher security state, perhaps with all endpoints authenticated. The floor and ceiling states will vary by protocol. 3. OS security is strongly recommended to use Perfect Forward Secrecy for key agreement. 5. Detection of man-in-the-middle (MiTM) attacks is a desired, thought not mandatory, feature. If crypto-based authentication cannot be achieved, it may still be possible to detect a MiTM. MiTM detection is considered a lower priority than (crypto-based) authentication. 6. In some contexts, delays in session/connection establishment might discourage use of OS. In such contexts, authentication and MiTM detection might take place only after an encrypted session is established. This could imply that application data could be transmitted prior to authentication or steps that would result in detection of a MiTM. 7. Because OS entails a relatively new key management paradigm, it requires new capabilities by peers which may take some time to be deployed. Thus, until OS is universally adopted for deployments of a protocol, attempts to establish confidentiality may fail, and the session might fallback to plaintext communication. Since an attempt to use OS is not communicated to users or applications, falling back to the status quo, i.e., plaintext communication, can be a reasonable strategy. From nobody Sat Apr 26 21:37: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 287361A0716 for ; Sat, 26 Apr 2014 21:37:10 -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 kPcQb4hXH2ze for ; Sat, 26 Apr 2014 21:37:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C11811A0715 for ; Sat, 26 Apr 2014 21:37:07 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 430882AAA21; Sun, 27 Apr 2014 04:36:59 +0000 (UTC) Date: Sun, 27 Apr 2014 04:36:59 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140427043658.GF27883@mournblade.imrryr.org> References: <535C4DE5.2080207@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <535C4DE5.2080207@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/arivIKSoPm1EiY5W89sUNabJITU Subject: Re: [saag] suggested text for opportunistic definition 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, 27 Apr 2014 04:37:10 -0000 On Sun, Apr 27, 2014 at 01:23:01AM +0100, Stephen Farrell wrote: > I tried to see what the Steve's definition would look like if > my comments were applied to it and came up with this. I tried > to keep the numbering as close to the draft as I could to make > it easier to compare. The comments are improvements in the list of "features" of opportunistic security, but there is still a hole in the shape of a missing high level definition of what the term actually means, or more precisely what are the goals and motivations rather than features of opportunistic security. Here's a partial list: - A suitably phrased "universal interoperability" goal. In other words, opportunistic security's primary goal is to be able to connect to any reasonably configured peer. If a non-trivial fraction of peers are only capable of cleartext[1], then it is OK to fall back to cleartext when encryption is not possible with a given peer. If authentication is only possible for some peers, then it is OK to authenticate only those peers and not the rest. This interoperability must be possible without bilateral coordination, that is applications employing opportunistic security need to be deployable at Internet scale, with each peer independently configuring their end to meet their needs (within reason and the bounds of the application protocol) and opportunistic security not getting in the way of the peers communicating if neither end is misconfigured. - Subject to the "universal interoperability" goal, which sets the floor low enough to interoperate on a large scale opportunistic security strives to maximize security (reaches for a higher ceiling), given the capabilities of the peer (or peers). For many opportunistic protocols the maximal ceiling may be just unauthenticated encryption. For some, via DANE, TOFU, ... the ceiling will be higher with some peers, and opportunistic security may at times (in partial conflict with the prime directive above) refuse to connect with peers where higher security is expected. The conditions under which connections fail should generally be limited to operational errors at one or the other peer, so that well-maintained systems do not encounter problems in normal use of opportunistic encryption. Of course for systems with sufficiently recent software and configurations that don't explicitly disable security features, at least unauthenticated encryption MUST be possible. An opportunistic security protocol MUST interoperably reach at least this level of security between typical peer systems. Over time only legacy systems or a minority of systems where encryption is not an option should be communicating in cleartext. - No misrepresentation of the security level achieved, unauthenticated connections or authentication that is vulnerable to MiTM attacks is not represented as strong security. Where strong security is required, opportunistic security is not a substitute, though the underlying mechanisms may in some cases be very similar, e.g. both use TLS. - Almost all other aspects of opportunistic security are illustrative, and aspirational rather than essential to the definition. Thus for example PFS, or UI considerations may in some cases typically apply to opportunistic security protocols and may be generally desirable, but are still non-essential features. A list of such features (such as the updated feature list) is a reasonable set of considerations for designers opportunistic protocols, but is not really IMHO part of the definition of the term. So bottom-line I'd like to see a draft with a good definition, and only then a list of associated design considerations, that might even predominantly focus on the counter-PM use-case (if that's explicitly stated). The draft should not however attempt to define OS as only a counter-PM technology. Rather OS is a more pragmatic approach to baking security into Internet protocols, where deployable security that works for most is valued more highly than strongest available security that works only for some. -- Viktor. [1] I use cleartext to refer to content that is transmitted unencrypted, as opposed to plaintext which is the not yet encrypted or already decrypted form of content that is sent encrypted). From nobody Sun Apr 27 04:02: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 D82CE1A0684 for ; Sun, 27 Apr 2014 04:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.642 X-Spam-Level: X-Spam-Status: No, score=-0.642 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=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 2iFVgoGCgw1e for ; Sun, 27 Apr 2014 04:02:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8071A049C for ; Sun, 27 Apr 2014 04:02:17 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id BE17220028; Sun, 27 Apr 2014 07:03:13 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0EB5063ABD; Sun, 27 Apr 2014 07:02:14 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id F046163AB2; Sun, 27 Apr 2014 07:02:14 -0400 (EDT) From: Michael Richardson To: Stephen Farrell In-Reply-To: <535C4DE5.2080207@cs.tcd.ie> References: <535C4DE5.2080207@cs.tcd.ie> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/OPcNpKjz2ZScQWCGAihkuIEFs_w Cc: "saag@ietf.org" Subject: Re: [saag] suggested text for opportunistic definition 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, 27 Apr 2014 11:02:20 -0000 --=-=-= Stephen Farrell wrote: > 1. OS is generally invisible to users, (no "lock icons") and, more > broadly, to applications that initiate sessions. Lack of visibility is > important, so that users or application administrators do not become > confused by the variability in the set of security services they are > being afforded. This allows applications to benefit from opportunistic > security without user or administrator intervention. So you write "invisible to users", which I agree with strongly. Then you write "application administrators", and I'm not sure who those people are. Is it a distinct group from "system administrators"? What I am concerned about is that some might take this to mean that an administrator viewable audit log is undesireable; such a log is necessary in order for the admin to figure out: 1) why wasn't OS enabled for connection FOO? 2) was there a MITM on that connection last week? ( 3) given a Heartbleed-type bug, was I vulnerable? ) ... in my mind, received: by lines for SMTP is a good example of how to do this well. > 7. Because OS entails a relatively new key management paradigm, it > requires new capabilities by peers which may take some time to be > deployed. Thus, until OS is universally adopted for deployments of a > protocol, attempts to establish confidentiality may fail, and the > session might fallback to plaintext communication. Since an attempt to > use OS is not communicated to users or applications, falling back to > the status quo, i.e., plaintext communication, can be a reasonable > strategy. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBU1zjtoqHRg3pndX9AQKKMgQAtC13EBmYsEXePlcQOyEL7q88EdYTQZri EYpJT15Nbq+PhBQZCnCuGkFZBcZsfxmzWcnWAN0kv1Z7XEdaHxLkssR82Man41lS b0J3IOAlpowhtAiQqlP9DScZUwluiXo3oa9STAu04Ai6EY3qOwfcDQxz2gg2qH49 le+4kqS+CC8= =6C56 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Apr 27 05:37: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 E8B3B1A078F for ; Sun, 27 Apr 2014 05:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.651] 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 utQwwOr_UcjN for ; Sun, 27 Apr 2014 05:37:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE371A0790 for ; Sun, 27 Apr 2014 05:37:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 91E08BE83 for ; Sun, 27 Apr 2014 13:37:43 +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 7mGbcz4tTBHu for ; Sun, 27 Apr 2014 13:37:42 +0100 (IST) Received: from [10.87.48.3] (unknown [86.46.21.208]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E1FFDBE7D for ; Sun, 27 Apr 2014 13:37:41 +0100 (IST) Message-ID: <535CFA14.5020200@cs.tcd.ie> Date: Sun, 27 Apr 2014 13:37:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.org References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> In-Reply-To: <20140427043658.GF27883@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/ELe6K3baLu1WJeV635mxEkuDYmA Subject: Re: [saag] suggested text for opportunistic definition 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, 27 Apr 2014 12:37:49 -0000 Hiya, On 27/04/14 05:36, Viktor Dukhovni wrote: > On Sun, Apr 27, 2014 at 01:23:01AM +0100, Stephen Farrell wrote: > >> I tried to see what the Steve's definition would look like if >> my comments were applied to it and came up with this. I tried >> to keep the numbering as close to the draft as I could to make >> it easier to compare. > > The comments are improvements in the list of "features" of > opportunistic security, but there is still a hole in the shape of > a missing high level definition of what the term actually means, > or more precisely what are the goals and motivations rather than > features of opportunistic security. Here's a partial list: I pretty much agree with your list, but its not text that could be cut'n'pasted into a draft. I did try to capture the basic definition in my point#0: " 0. OS involves establishing and using shared secrets to provide confidentiality for communications between endpoints, even if there is no guarantee of the identities of the endpoints (so that one of them could be a Man-in-the-Middle)." Would it be possible/useful if you were to modify that to capture what you think needs capturing? (In as few words as possible:-) Or even maybe try suggest an alternative for the whole thing if you've energy. Cheers, S. > > - A suitably phrased "universal interoperability" goal. In > other words, opportunistic security's primary goal is to be > able to connect to any reasonably configured peer. If a > non-trivial fraction of peers are only capable of cleartext[1], > then it is OK to fall back to cleartext when encryption is not > possible with a given peer. If authentication is only possible > for some peers, then it is OK to authenticate only those peers > and not the rest. > > This interoperability must be possible without bilateral > coordination, that is applications employing opportunistic > security need to be deployable at Internet scale, with each > peer independently configuring their end to meet their needs > (within reason and the bounds of the application protocol) > and opportunistic security not getting in the way of the > peers communicating if neither end is misconfigured. > > - Subject to the "universal interoperability" goal, which sets > the floor low enough to interoperate on a large scale > opportunistic security strives to maximize security (reaches > for a higher ceiling), given the capabilities of the peer > (or peers). For many opportunistic protocols the maximal > ceiling may be just unauthenticated encryption. For some, > via DANE, TOFU, ... the ceiling will be higher with some > peers, and opportunistic security may at times (in partial > conflict with the prime directive above) refuse to > connect with peers where higher security is expected. The > conditions under which connections fail should generally > be limited to operational errors at one or the other peer, > so that well-maintained systems do not encounter problems > in normal use of opportunistic encryption. > > Of course for systems with sufficiently recent software and > configurations that don't explicitly disable security features, > at least unauthenticated encryption MUST be possible. An > opportunistic security protocol MUST interoperably reach at > least this level of security between typical peer systems. > Over time only legacy systems or a minority of systems where > encryption is not an option should be communicating in cleartext. > > - No misrepresentation of the security level achieved, > unauthenticated connections or authentication that is vulnerable > to MiTM attacks is not represented as strong security. Where strong > security is required, opportunistic security is not a substitute, > though the underlying mechanisms may in some cases be very similar, > e.g. both use TLS. > > - Almost all other aspects of opportunistic security are > illustrative, and aspirational rather than essential to the > definition. Thus for example PFS, or UI considerations may > in some cases typically apply to opportunistic security > protocols and may be generally desirable, but are still > non-essential features. A list of such features (such as > the updated feature list) is a reasonable set of considerations > for designers opportunistic protocols, but is not really IMHO > part of the definition of the term. > > So bottom-line I'd like to see a draft with a good definition, and > only then a list of associated design considerations, that might > even predominantly focus on the counter-PM use-case (if that's > explicitly stated). The draft should not however attempt to define > OS as only a counter-PM technology. > > Rather OS is a more pragmatic approach to baking security into > Internet protocols, where deployable security that works for most > is valued more highly than strongest available security that works > only for some. > From nobody Sun Apr 27 05:43: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 217F11A0797 for ; Sun, 27 Apr 2014 05:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.651] 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 CJhMFeAFfB6w for ; Sun, 27 Apr 2014 05:43:26 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BA7FE1A0790 for ; Sun, 27 Apr 2014 05:43:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DFAEBBE83; Sun, 27 Apr 2014 13:43:25 +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 KQhqthsAPXru; Sun, 27 Apr 2014 13:43:23 +0100 (IST) Received: from [10.87.48.3] (unknown [86.46.21.208]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9559DBE7D; Sun, 27 Apr 2014 13:43:23 +0100 (IST) Message-ID: <535CFB6B.8090706@cs.tcd.ie> Date: Sun, 27 Apr 2014 13:43:23 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Michael Richardson References: <535C4DE5.2080207@cs.tcd.ie> <24685.1398596534@sandelman.ca> In-Reply-To: <24685.1398596534@sandelman.ca> 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/A95y6KjbmY-dZXK5gYISQDrRDo8 Cc: "saag@ietf.org" Subject: Re: [saag] suggested text for opportunistic definition 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, 27 Apr 2014 12:43:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hiya, On 27/04/14 12:02, Michael Richardson wrote: > > Stephen Farrell wrote: >> 1. OS is generally invisible to users, (no "lock icons") and, >> more broadly, to applications that initiate sessions. Lack of >> visibility is important, so that users or application >> administrators do not become confused by the variability in the >> set of security services they are being afforded. This allows >> applications to benefit from opportunistic security without user >> or administrator intervention. > > So you write "invisible to users", which I agree with strongly. > Then you write "application administrators", and I'm not sure who > those people are. Is it a distinct group from "system > administrators"? Yep, I didn't write that very well I agree. > > What I am concerned about is that some might take this to mean > that an administrator viewable audit log is undesireable; such a > log is necessary in order for the admin to figure out: 1) why > wasn't OS enabled for connection FOO? 2) was there a MITM on that > connection last week? ( 3) given a Heartbleed-type bug, was I > vulnerable? ) > > ... in my mind, received: by lines for SMTP is a good example of > how to do this well. Agreed. The reason I (badly) tried to add that was that the point has been made that if an implementation does OS and makes turning that on a configuration option for an admin then that admin may well think "security, great, I'm done with OS." Viktor's text about not misrepresenting the security level seems better than what I wrote though. S. > >> 7. Because OS entails a relatively new key management paradigm, >> it requires new capabilities by peers which may take some time to >> be deployed. Thus, until OS is universally adopted for >> deployments of a protocol, attempts to establish confidentiality >> may fail, and the session might fallback to plaintext >> communication. Since an attempt to use OS is not communicated to >> users or applications, falling back to the status quo, i.e., >> plaintext communication, can be a reasonable strategy. > > -- Michael Richardson , Sandelman Software > Works -= IPv6 IoT consulting =- > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTXPtoAAoJEC88hzaAX42igYAIAIU+Rm/+dKH1dXQxW8Qba1Ki VEt1Op+Vs6bY86W49JO4tQFCTaI0MA5BKf8qGFMDXz4bSYs8kwRCcbAmtb6lB2TM JE4nVC0ckxAAayAF7XCyvWrmHo57olpesuFUlppezVJ18e6wwAUh4nmp/P+IJYpm yEnJPTE+tcUwblnFDhmaHw89dN/Fde5ffd0USHnbAju4qb7OURuR/p/9IQwugdoX QSk+LzhHK3o4nrNX7AIlA9dvOZwY4RfuGsRFQvdhKOsStaEjMDGK6qP7+FAwrXEc B8OVZbOD8GO4gmcRVbeALu30C8rLV/m9mu3+wOt0Nj6Ws+X7v2CjdlDfuUGNaL4= =mI7x -----END PGP SIGNATURE----- From nobody Tue Apr 29 16:55: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 2A3731A09B5 for ; Tue, 29 Apr 2014 16:55:16 -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 vJu18hGZTthy for ; Tue, 29 Apr 2014 16:55:15 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id D818B1A09A0 for ; Tue, 29 Apr 2014 16:55:14 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id E48FE6D5F9; Tue, 29 Apr 2014 19:55:11 -0400 (EDT) Message-ID: <53603BDD.2080109@iang.org> Date: Wed, 30 Apr 2014 00:55:09 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: saag@ietf.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/2TMTLNastLTmF5tSB0TaydDkQuA Subject: Re: [saag] Please review draft-iab-crypto-alg-agility-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: Tue, 29 Apr 2014 23:55:16 -0000 In general, I understand that many IETF algorithms make use of the practice of algorithm agility. And therefore there is a need to document and improve that situation overall. But *algorithm agility is a bad practice*. It should not be encouraged, IMHO. Hence the major criticism of the document is that it appears to promote a bad practice. Folows are some more detailed comments: Many IETF protocols may use of cryptographic algorithms to provide confidentiality, integrity, or non-repudiation. Non-repudiation is a dead concept from the 1990s. It's not actually possible to provide, and reference to it should be removed. I'm guessing "may" ==> "make" in that para, also in abstract. Also, this: For the mechanisms to work properly,communicating peers must support the same cryptographic algorithm or algorithms. Begs the question: this is talking about agility but agility isn't introduced in the preceding sentence. Some approaches carry one identifier for each algorithm that is used. Other approaches carry one identifier for a suite of algorithms. *Either approach is acceptable*; however, designers are encouraged to pick one of these approaches and use it consistently throughout the protocol. Well, disagreed! picking a suite of algorithms is vastly superior to allowing a caller to negotiate his own suite. Indeed, 2.4 argues that very case, it should end with "and therefore only selection of complete suites is safe and permitted in future designs." Remembering of course that this document is read by the protocol designer and not the protocol user... 2.3 makes a theoretical case that looks fine on paper, but it is falls in practice. If we look at the history of TLS, inordinate time has been spent in allowing fashion algorithms to be mixed and matched, but the claimed benefit of transition from weak to strong has never been realised. The headline example of this is BEAST, where a non-algorithm attack resulted in transition to a weaker, deprecated algorithm! History speaks, that benefit is not there, not available. Instead there is just a continuing drainage on time and effort for no benefit. As a data point, over on the ACH list, the team that creates the BetterCrypto document probably spends about half of its time on one thing alone: trying to figure out what is the better OpenSSL configuration string. This waste is repeated across the developer and sysadm world; it would all disappear if there was one, only one true cipher suite. 2.4, as mentioned above, should be seen as an argument to totally ban algorithm negotiation. 3.2 Migration mechanisms -- general comment: In contrast to the above arguments, if one avoids the siren of cipher suite negotiation and the icebergs of algorithm negotiation, there is a need to upgrade the entire protocol. If the work that has been spent in agility was instead spent in upgradeability, we would be better off, because this approach also picks up where the real bugs lie: in the protocol, which otherwise gets too little attention because (a) it is too hard to upgrade the protocol and (b) people are too busy arguing about vanity suites. 3.3 Does this sound like a case for them being separate protocols, with similar internals? 4. Also makes the case that this is a "good thing": The security of the Internet is improved when broken or weak cryptographic algorithms can be easily replaced with strong ones. It assumes it is practical, efficient and delivers benefits. None of these things are true. In practice, algorithm agility reduces the security of the Internet, the sooner we get rid of it and move to faster upgradeability, the better we'll be. iang From nobody Wed Apr 30 18:22: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 9334D1A8885 for ; Wed, 30 Apr 2014 18:22:29 -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 iPQw_-4MrCrW for ; Wed, 30 Apr 2014 18:22:24 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id AB1471A888F for ; Wed, 30 Apr 2014 18:22:24 -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 s411MMAA025671; Wed, 30 Apr 2014 18:22:22 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0a-0016f401.pphosted.com with ESMTP id 1kjrwt2vgf-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 30 Apr 2014 18:22:21 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Wed, 30 Apr 2014 18:22:21 -0700 From: Paul Lambert To: ianG , "saag@ietf.org" Date: Wed, 30 Apr 2014 18:22:19 -0700 Thread-Topic: [saag] Please review draft-iab-crypto-alg-agility-00.txt Thread-Index: Ac9kBnrxn/viHGGYS5OGSwNc2xjEvAAw+OZw Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D0197E34C186@SC-VEXCH2.marvell.com> References: <53603BDD.2080109@iang.org> In-Reply-To: <53603BDD.2080109@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.11.96, 1.0.14, 0.0.0000 definitions=2014-04-30_06:2014-04-30,2014-04-30,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-1405010021 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/hH70Uymu5BXzzKTfqiSVmBXegVE Subject: Re: [saag] Please review draft-iab-crypto-alg-agility-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: Thu, 01 May 2014 01:22:30 -0000 ]-----Original Message----- ]From: saag [mailto:saag-bounces@ietf.org] On Behalf Of ianG ] ]In general, I understand that many IETF algorithms make use of the ]practice of algorithm agility. And therefore there is a need to ]document and improve that situation overall. ] ]But *algorithm agility is a bad practice*. It should not be encouraged, ]IMHO. Hence the major criticism of the document is that it appears to ]promote a bad practice. +1 With a slight qualification. An ability to use a algorithm of your own choice is an important=20 requirement. This is not an "agility requirement", but a requirement to identify a desired cipher suite. Cipher suites should be able to be used to provide cryptographic separation of communications. While we are all wanting to ensure interoperability, we must not forget that NOT interoperating is a useful security feature. In this context, a negotiation would not be appropriate for such algorithm "diversity". If a specific usage desired a specific private algorithm it would not want to negotiate down to the default. Paul ] ] ] ]Folows are some more detailed comments: ] ] Many IETF protocols may use of cryptographic algorithms to provide ] confidentiality, integrity, or non-repudiation. ] ]Non-repudiation is a dead concept from the 1990s. It's not actually ]possible to provide, and reference to it should be removed. ] ]I'm guessing "may" =3D=3D> "make" in that para, also in abstract. ] ]Also, this: ] ] For the mechanisms ] to work properly,communicating peers must support the same ] cryptographic algorithm or algorithms. ] ]Begs the question: this is talking about agility but agility isn't ]introduced in the preceding sentence. ] ] ] ] Some approaches carry one identifier for each algorithm that is used. ] Other approaches carry one identifier for a suite of algorithms. ] *Either approach is acceptable*; however, designers are encouraged to ] pick one of these approaches and use it consistently throughout the ] protocol. ] ]Well, disagreed! picking a suite of algorithms is vastly superior to ]allowing a caller to negotiate his own suite. Indeed, 2.4 argues that ]very case, it should end with "and therefore only selection of complete ]suites is safe and permitted in future designs." Remembering of course ]that this document is read by the protocol designer and not the protocol ]user... ] ] ] ]2.3 makes a theoretical case that looks fine on paper, but it is falls ]in practice. If we look at the history of TLS, inordinate time has been ]spent in allowing fashion algorithms to be mixed and matched, but the ]claimed benefit of transition from weak to strong has never been ]realised. The headline example of this is BEAST, where a non-algorithm ]attack resulted in transition to a weaker, deprecated algorithm! ] ]History speaks, that benefit is not there, not available. Instead there ]is just a continuing drainage on time and effort for no benefit. As a ]data point, over on the ACH list, the team that creates the BetterCrypto ]document probably spends about half of its time on one thing alone: ]trying to figure out what is the better OpenSSL configuration string. ]This waste is repeated across the developer and sysadm world; it would ]all disappear if there was one, only one true cipher suite. ] ] ] ]2.4, as mentioned above, should be seen as an argument to totally ban ]algorithm negotiation. ] ] ] ]3.2 Migration mechanisms -- general comment: In contrast to the above ]arguments, if one avoids the siren of cipher suite negotiation and the ]icebergs of algorithm negotiation, there is a need to upgrade the entire ]protocol. If the work that has been spent in agility was instead spent ]in upgradeability, we would be better off, because this approach also ]picks up where the real bugs lie: in the protocol, which otherwise gets ]too little attention because (a) it is too hard to upgrade the protocol ]and (b) people are too busy arguing about vanity suites. ] ] ] ]3.3 Does this sound like a case for them being separate protocols, with ]similar internals? ] ] ] ] ]4. Also makes the case that this is a "good thing": ] ] The security of the Internet is improved when broken or ] weak cryptographic algorithms can be easily replaced with strong ] ones. ] ]It assumes it is practical, efficient and delivers benefits. None of ]these things are true. In practice, algorithm agility reduces the ]security of the Internet, the sooner we get rid of it and move to faster ]upgradeability, the better we'll be. ] ] ] ] ] ]iang ] ]_______________________________________________ ]saag mailing list ]saag@ietf.org ]https://www.ietf.org/mailman/listinfo/saag